Os Sistemas Relacionais de Gerenciamento de Banco de Dados(RBDMS) usando SQL têm sido usados para armazenar informações de aplicação por décadas. Servindo como a espinha dorsal das principais indústrias como 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 confiável e eficiente. Bancos de dados SQL modernos, incluindo MySQL e PostgreSQL continuam sendo alguns dos bancos de dados mais populares em uso hoje em dia. Mas quando o SQL não é suficiente?
O aumento das bancos de dados NoSQL(NotOnlySQL) a partir do final dos anos 2000 coincidiu com muitos outros avanços. Enquanto processadores multicore e virtualização estavam se tornando comuns, a nuvem estava decolando, e milhões de usuários ao redor do mundo estavam indo online pela primeira vez com smartphones. Tudo o que era necessário para crescer, e a maneira mais prática de atingir esta escala tão necessária é Escala horizontal. Muitas vezes vemos o SQL versus NoSQL super simplificado para "SQL pode escalar verticalmente e NoSQL pode escalar horizontalmente", mas isto é incompleto e incorreto.
Escala Horizontal
Quando falamos em escalar horizontalmente, queremos dizer crescer nosso ambiente adicionando mais nós ou máquinas. Enquanto os bancos de dados SQL podem escalar verticalmente com relativa facilidade, adicionando mais RAM e computando a um único nó, espalhar seu conjunto de dados por vários nós é mais desafiador. Isto pode ser feito através de uma técnica chamada sharding. Quando se trabalha com grandes conjuntos de dados e alto rendimento, a fragmentação ajuda a diminuir a carga em um único servidor e permite escalar através da adição ou remoção de servidores, dependendo da necessidade.
MySQL Sharding e Limitações
Os bancos de dados SQL podem ser escalados horizontalmente por estilhaçamento. O método e as características suportadas variarão significativamente entre bancos de dados, mas é preciso considerar as advertências. Vamos nos concentrar em um dos exemplos mais comuns - o MySQL usando o mecanismo de armazenamento NDB. O MySQL suporta clusters NDB que podem dividir uma única e grande tabela em várias tabelas menores. O processo de divisão de uma tabela é chamado de particionamento. Quando armazenadas em múltiplos servidores, estas tabelas menores compõem os fragmentos. Os bancos de dados em seu cluster armazenam cada um dos fragmentos. Juntas, as bases de dados no cluster constituem seu conjunto completo de dados.
O uso de sharding em bancos de dados SQL pode oferecer uma escala muito alta de tamanho de conjunto de dados, mas também pode tornar sua lógica de aplicação mais complexa. Você precisa configurar cuidadosamente como seus dados são particionados em vários fragmentos, porque esta decisão afeta o desempenho geral do banco de dados. Além da complexidade e da alta exigência de tempo, existem obstáculos técnicos a serem considerados. Para contrariar uma limitação comumente 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.
Digite NoSQL
Muitos tipos diferentes de bancos de dados NoSQL explodiram em uso desde seu início, no final dos anos 2000. Para este exemplo, vamos nos concentrar no mais popular banco de dados NoSQL, o MongoDB. O MongoDB (derivado da palavra "humongous") é orientado a documentos. Os dados são armazenados em documentos similares aos objetos JSON e cada documento contém pares de campos e valores. Isto é oposto aos bancos de dados SQL que utilizam tabelas e linhas para formatar os dados. Você pode ter lido que bancos de dados NoSQL como o MongoDB são tipicamente mais adequados para escalonamento horizontal, mas vamos mergulhar no porquê de ser este o caso.
Observe que MongoDB usa especificamente um formato chamado BSON, que é derivado do JSON, mas isto variará com cada banco de dados.
Esquemas e fragmentos
MongoDB é schemaless (ou sem esquema), o que significa que não requer uma estrutura organizacional definida no nível do banco de dados. O esquema é incorporado ao seu código no nível de aplicação e isto nos dá muita flexibilidade para mudar a estrutura mais tarde enquanto preservamos nossos dados. Embora não tenham a consistência rigidamente aplicada dos bancos de dados SQL compatíveis com ACID, o MongoDB e outros bancos de dados NoSQL primam pela disponibilidade e tolerância de partição.
Quando olhamos para bancos de dados SQL em escala horizontal, repassamos o processo de divisão de uma tabela em fragmentos. Embora possível, isso trouxe uma grande quantidade de limitações devido à estrutura rígida incorporada ao banco de dados. O MongoDB e outros bancos de dados NoSQL, por outro lado, foram projetados para acomodar fragmentos em um nível estrutural. Um fragmento é um subconjunto de dados e o MongoDB nos permite escalar horizontalmente, implantando fragmentos 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. Eles fornecem disponibilidade e redundância quando espalhados por grandes ambientes e não sã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. Os bancos de dados NoSQL freqüentemente usam significativamente mais armazenamento do que os bancos de dados SQL devido à quantidade de dados redundantes necessários para alcançar a disponibilidade em grandes implantações horizontais. As velocidades de gravação do NoSQL tendem a superar os bancos de dados SQL, mas as consultas são mais lentas. Na falta de uma estrutura definida, os bancos de dados NoSQL não são inerentemente compatíveis com ACID, o que os torna menos práticos para aplicações que lidam com grandes volumes de transações financeiras. Alternativamente, podemos configurar clusters NoSQL distribuídos em massa que mantêm o desempenho, tornando-os candidatos ideais para Grandes Dados e análises.
Então, quando o SQL não é suficiente? Como seria de esperar, a resposta não é simples, mas existem algumas diretrizes gerais que podemos levar em conta ao projetar nossas aplicações. O que nossa aplicação precisa fazer e de que tamanho ela precisa ser? A partir daí, podemos decidir nossa prioridade número um. Dizer "SQL escalas verticais e NoSQL escalas horizontais" não é verdade, mas podemos dizer "a maioria dos bancos de dados SQL foram projetados com a consistência em mente enquanto a maioria dos bancos de dados NoSQL foram projetados para acomodar escalas".
Haverá sempre contrapontos a essa diretriz geral. Você pode escalar o MySQL horizontalmente, e o MongoDB começou a suportar Transações ACID Multi-Documento. Quanto mais entendemos como estas bancos de dados são projetadas, mais fácil será escolher a melhor ferramenta para o trabalho.
Implantação de bancos de dados em Linode
Saiba mais sobre os bancos de dados gerenciados da Linode ou inscreva-se para receber atualizações sobre o mecanismo de banco de dados de sua preferência. 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 distribuições Linux, como Instalar o MongoDB no CentOS 7.
Comentários