Os Sistemas Relacionais de Gestão de Bases de Dados(RBDMS) que utilizam SQL têm sido utilizados para armazenar informação de aplicações durante décadas. Servindo como espinha dorsal das principais indústrias como a da saúde e finanças, o modelo relacional de organização de dados em tabelas com uma chave de identificação para cada linha provou ser fiável e eficiente. As bases de dados SQL modernas, incluindo MySQL e PostgreSQL continuam a ser algumas das bases de dados mais populares actualmente em uso. Mas quando é que SQL não é suficiente?
O aumento das bases de dados NoSQL(NotOnlySQL) a partir do final dos anos 2000 coincidiu com muitos outros avanços. Enquanto os processadores multinúcleos e a virtualização se estavam a tornar comuns, a nuvem estava a descolar, e milhões de utilizadores em todo o mundo estavam a entrar em linha pela primeira vez com smartphones. Tudo o que era necessário para crescer, e a forma mais prática de atingir esta escala tão necessária é escalada horizontal. Vemos frequentemente SQL versus NoSQL sobre-simplificado para "SQL pode escalar verticalmente e NoSQL pode escalar horizontalmente", mas isto é incompleto e incorrecto.
Escala Horizontal
Quando falamos de escalonamento horizontal, referimo-nos ao crescimento do nosso ambiente através da adição de mais nós ou máquinas. Enquanto as bases de dados SQL podem escalar verticalmente com relativa facilidade, adicionando mais RAM e calculando a um único nó, espalhar o seu conjunto de dados por vários nós é mais desafiante. Isto pode ser feito através de uma técnica chamada sharding. Quando se trabalha com grandes conjuntos de dados e elevado rendimento, o estilhaçamento ajuda a diminuir a carga num único servidor e permite escalonar através da adição ou remoção de servidores, dependendo da necessidade.
MySQL Sharding e Limitações
As bases de dados SQL podem ser escaladas horizontalmente por estilhaçamento. O método e as características suportadas variarão significativamente entre bases de dados, mas há que ter em conta as advertências. Vamos concentrar-nos num dos exemplos mais comuns - MySQL utilizando o motor de armazenamento NDB. O MySQL suporta clusters NDB que podem dividir uma única e grande tabela em várias tabelas mais pequenas. O processo de divisão de uma tabela é referido como partição. Quando armazenadas em múltiplos servidores, estas tabelas mais pequenas compõem os fragmentos. As bases de dados no seu cluster armazenam cada um dos fragmentos. Juntas, as bases de dados no cluster constituem o seu conjunto de dados completo.
A utilização de estilhaços em bases de dados SQL pode oferecer uma escala muito elevada de tamanho de conjunto de dados, mas também pode tornar a sua lógica de aplicação mais complexa. É necessário configurar cuidadosamente a forma como os seus dados são particionados em múltiplos fragmentos, porque esta decisão tem impacto no desempenho global da base de dados. Para além da complexidade e do elevado requisito de tempo, existem obstáculos técnicos a considerar. Para contrariar uma limitação comummente declarada, o MySQL pode ser configurado para realizar operações de junção em múltiplos fragmentos, mas com um custo para o desempenho em escalas maiores. Isto pode tornar as funções analíticas impraticáveis nestes ambientes.
Introduzir NoSQL
Muitos tipos diferentes de bases de dados NoSQL explodiram em uso desde a sua criação no final dos anos 2000. Para este exemplo, vamos concentrar-nos na mais popular base de dados NoSQL, a MongoDB. A MongoDB (derivada da palavra "humongous") é orientada para a documentação. Os dados são armazenados em documentos semelhantes a objectos JSON e cada documento contém pares de campos e valores. Isto é contrário às bases de dados SQL que utilizam tabelas e linhas para formatar os dados. Pode ter lido que as bases de dados NoSQL como o MongoDB são tipicamente mais adequadas para escalas horizontais, mas vamos mergulhar no porquê de ser este o caso.
Note-se que MongoDB utiliza especificamente um formato chamado BSON, que é derivado do JSON, mas isto variará com cada base de dados.
Esquemas e Fragmentos
MongoDB é schemaless (ou sem esquema), o que significa que não requer uma estrutura organizacional definida ao nível da base de dados. O esquema é antes incorporado no seu código ao nível da aplicação e isto dá-nos muita flexibilidade para alterar a estrutura mais tarde, preservando os nossos dados. Embora lhes falte a consistência rigidamente imposta das bases de dados SQL compatíveis com ACID, MongoDB e outras bases de dados NoSQL primam pela disponibilidade e tolerância de partição.
Quando olhámos para as bases de dados SQL de escala horizontal, revimos o processo de divisão de uma tabela em estilhaços. Embora possível, trouxe muitas limitações devido à estrutura rígida incorporada na base de dados. MongoDB e outras bases de dados NoSQL, por outro lado, foram concebidas para acomodar estilhaços a um nível estrutural. Um estilhaço é um subconjunto de dados e o MongoDB permite-nos escalar horizontalmente, implantando estilhaços como conjuntos de réplicas. Os conjuntos de réplicas são conjuntos de pelo menos três nós com cópias redundantes dos mesmos dados. Fornecem disponibilidade e redundância quando espalhados por grandes ambientes e não estão confinados por um esquema pré-determinado.
A partir disto, podemos ver imediatamente as concessões que as bases de dados NoSQL fazem para serem escaláveis. As bases de dados NoSQL utilizam frequentemente muito mais armazenamento do que as bases de dados SQL, devido à quantidade de dados redundantes necessários para alcançar a disponibilidade em grandes implantações horizontais. As velocidades de escrita NoSQL tendem a superar as bases de dados SQL, mas as consultas são mais lentas. Na ausência de uma estrutura definida, as bases de dados NoSQL não são inerentemente compatíveis com ACID, o que as torna menos práticas para aplicações que lidam com grandes volumes de transacções financeiras. Alternativamente, podemos configurar clusters NoSQL massivos distribuídos que mantêm o desempenho, tornando-os candidatos ideais para Grandes Dados e análises.
Então, quando é que SQL não é suficiente? Como seria de esperar, a resposta não é simples mas existem algumas directrizes gerais que podemos ter em conta ao conceber as nossas aplicações. O que é que a nossa aplicação precisa de fazer e qual o seu tamanho? A partir daí, podemos decidir a nossa prioridade número um. Dizer "SQL escalas verticais e NoSQL escalas horizontais" não é verdade, mas podemos dizer "a maioria das bases de dados SQL foram concebidas com a consistência em mente, enquanto a maioria das bases de dados NoSQL foram concebidas para acomodar escalas".
Haverá sempre contrapontos a essa diretriz geral. Pode escalar o MySQL horizontalmente, e o MongoDB começou a suportar Transacções ACID Multi-Documento. Quanto mais compreendermos como estas bases de dados são concebidas, mais fácil será escolher a melhor ferramenta para o trabalho.
Implantação de bases de dados em Linode
Saiba mais sobre o Linode Managed Databases ou inscreva-se para receber atualizações sobre seu mecanismo de banco de dados preferido. Você também pode implantar sistemas gerenciados de banco de dados como o MongoDB a partir do Linode Marketplace ou seguir nossos guias para instalar um banco de dados em uma variedade de distros Linux, como Instalando o MongoDB em CentOS 7.
Comentários