Em recentes debates sobre tecnologias emergentes – seja Rails, ou NoSQL – argumentos contra a escalabilidade e desempenho das mesmas são bastante frequentes. Se o mito do “Rails não escala” serve para nos ensinar algo, é que estes argumentos tendem a se tornar grandes discussões sem muito fundamento, e que a maioria das pessoas, além de não entender bem o conceito de escalabilidade e suas implicações, faz julgamentos sem sequer ter experimentado as soluções em questão, ou se baseiam em uma única experiência desafortunada.

Observado isso, vamos tentar entender melhor o que é – e o que não é – escalabilidade e desempenho. Infelizmente, não encontrei nenhuma boa definição dos termos em dicionários de português, então traduzirei uma definição em inglês, do Wiktionary:

* *Desempenho*
** O ato de desempenhar, executar uma ação, executar, alcançar, representar por meio de ação.
** O que é desempenhado ou obtido, uma coisa feita ou acompanhada, um feito, um êxito, especialmente, uma ação elaborada ou de caráter público.
** Um show ou concerto ao vivo.
** *Na ciência da computação: A quantidade de trabalho realizado por um sistema de computação em relação ao tempo e recursos utilizados. Melhor desempenho significa mais trabalho concluído em uma menor quantidade de tempo e/ou usando menos recursos.*

Nenhuma grande surpresa aqui. Simplificando, é algo rápido.

* *Escalar*
** Alterar o tamanho de algo enquanto mantendo sua proporção, em especial, alterar um processo de forma a produzir uma quantidade muito maior do seu produto final.
** Realizar uma escalada.
** *Na ciência da computação: tolerar significantes aumentos de volume de dados ou outros fatores limitadores em potencial.*

Isto sim pode ser uma surpresa. Escalabilidade não tem a ver com desempenho, tem a ver com proporções, graduações. É a medida na qual um sistema pode tolerar grandes aumentos no volume de dados processados e ainda assim manter proporção à quantidade de recursos utilizados.

Um sistema com desempenho horrível – digamos, que demora 40 segundos para processar um request – ainda pode escalar muito bem, se, quando adicionado mais um servidor, ele passe a responder dois requests em 40 segundos.

Mesmo sendo tão diferentes, os dois conceitos possuem uma relação no sentido que, se algo possui uma boa performance, você pode nunca precisar escalá-lo. Um bom exemplo é o Tokyo, um banco de dados key-value que possui um desempenho fantástico, realizando milhões de escritas por segundo. Ele escala muito mal, mas devido ao seu alto desempenho, você vai demorar muito, para realmente precisar se preocupar com isso.

Outro exemplo clássico é o Rails. Rails escala muitíssimo bem, mas não tem uma boa performance, o que faz com que você precise se preocupar em escalá-lo quase que imediatamente. A maioria dos desenvolvedores, saindo de soluções com alto desempenho – como o PHP – nunca precisaram se preocupar com escalabilidade, e esta súbita preocupação causou um choque. Assim nasceu o mito da não-escalabilidade do Rails, que na verdade não é sobre escalabilidade =).

Agora que este conceito está mais claro, podemos entender mais facilmente as descrições dos bancos de dados que estão por vir. Existe um banco em cada extremo da situação – alguns com ótima escalabilidade e péssimo desempenho, outros com o inverso, outros no meio do caminho, e alguns poucos satisfatórios em ambos os aspectos. Veremos em breve.