O guia definitivo para bancos de dados NoSQL

Não há dúvida de que a maneira como os aplicativos da Web lidam com os dados mudou significativamente na última década. Mais dados estão sendo coletados e mais usuários estão acessando esses dados simultaneamente do que nunca. Isso significa que a escalabilidade e o desempenho são um desafio maior do que nunca para bancos de dados relacionais baseados em esquema e, portanto, podem ser mais difíceis de dimensionar.

A evolução do NoSQL

A questão da escalabilidade do SQL foi reconhecida por empresas da Web 2.0 com necessidades enormes e crescentes de dados e infraestrutura, como Google, Amazon e Facebook. Eles criaram suas próprias soluções para o problema – tecnologias como BigTable, DynamoDB e Cassandra.

Esse interesse crescente resultou em vários sistemas de gerenciamento de banco de dados NoSQL (DBMS's), com foco em desempenho, confiabilidade e consistência. Várias estruturas de indexação existentes foram reutilizadas e aprimoradas com o objetivo de aprimorar o desempenho de pesquisa e leitura.

Primeiro, havia tipos proprietários (código fechado) de bancos de dados NoSQL desenvolvidos por grandes empresas para atender às suas necessidades específicas, como o BigTable do Google, que se acredita ser o primeiro sistema NoSQL, e o DynamoDB da Amazon.

O sucesso desses sistemas proprietários iniciou o desenvolvimento de vários sistemas de banco de dados de código aberto e proprietários semelhantes, sendo os mais populares Hypertable, Cassandra, MongoDB, DynamoDB, HBase e Redis.

O que torna o NoSQL diferente?

Uma diferença fundamental entre os bancos de dados NoSQL e os bancos de dados relacionais tradicionais é o fato de que o NoSQL é uma forma de armazenamento não estruturado .

Isso significa que os bancos de dados NoSQL não possuem uma estrutura de tabela fixa como as encontradas em bancos de dados relacionais.

Vantagens e desvantagens dos bancos de dados NoSQL

Vantagens

Os bancos de dados NoSQL têm muitas vantagens em comparação com os bancos de dados relacionais tradicionais.

Uma grande diferença subjacente é que os bancos de dados NoSQL têm uma estrutura simples e flexível. Eles são livres de esquema.

Ao contrário dos bancos de dados relacionais, os bancos de dados NoSQL são baseados em pares chave-valor.

Alguns tipos de armazenamento de bancos de dados NoSQL incluem armazenamento de colunas, armazenamento de documentos, armazenamento de valores de chave, armazenamento de gráficos, armazenamento de objetos, armazenamento XML e outros modos de armazenamento de dados.

Normalmente, cada valor no banco de dados tem uma chave. Alguns armazenamentos de banco de dados NoSQL também permitem que os desenvolvedores armazenem objetos serializados no banco de dados, não apenas valores de string simples.

Os bancos de dados NoSQL de código aberto não exigem taxas de licenciamento caras e podem ser executados em hardware barato, tornando sua implantação econômica.

Além disso, ao trabalhar com bancos de dados NoSQL, sejam eles de código aberto ou proprietários, a expansão é mais fácil e barata do que quando se trabalha com bancos de dados relacionais. Isso ocorre porque é feito dimensionando horizontalmente e distribuindo a carga em todos os nós, em vez do tipo de dimensionamento vertical que geralmente é feito com sistemas de banco de dados relacionais, que substitui o host principal por um mais poderoso.

Desvantagens

É claro que os bancos de dados NoSQL não são perfeitos e nem sempre são a escolha certa.

Por um lado, a maioria dos bancos de dados NoSQL não oferece suporte a recursos de confiabilidade que são suportados nativamente por sistemas de banco de dados relacionais. Esses recursos de confiabilidade podem ser resumidos como atomicidade, consistência, isolamento e durabilidade. Isso também significa que os bancos de dados NoSQL, que não suportam esses recursos, trocam consistência por desempenho e escalabilidade.

Para oferecer suporte a recursos de confiabilidade e consistência, os desenvolvedores devem implementar seu próprio código proprietário, o que adiciona mais complexidade ao sistema.

Isso pode limitar o número de aplicativos que podem contar com bancos de dados NoSQL para transações seguras e confiáveis, como sistemas bancários.

Outras formas de complexidade encontradas na maioria dos bancos de dados NoSQL incluem incompatibilidade com consultas SQL. Isso significa que uma linguagem de consulta manual ou proprietária é necessária, adicionando ainda mais tempo e complexidade.

NoSQL vs. Bancos de Dados Relacionais

Esta tabela fornece uma breve comparação de recursos entre bancos de dados NoSQL e relacionais:

Deve-se notar que a tabela mostra uma comparação no nível do banco de dados, não os vários sistemas de gerenciamento de banco de dados que implementam os dois modelos. Esses sistemas fornecem suas próprias técnicas proprietárias para superar alguns dos problemas e deficiências em ambos os sistemas e, em alguns casos, melhorar significativamente o desempenho e a confiabilidade.

Tipos de armazenamento de dados NoSQL

Armazenamento de valor-chave

No tipo de armazenamento Key Value, uma tabela de hash é usada na qual uma chave exclusiva aponta para um item.

As chaves podem ser organizadas em grupos lógicos de chaves, exigindo apenas que as chaves sejam exclusivas dentro de seu próprio grupo. Isso permite chaves idênticas em diferentes grupos lógicos. A tabela a seguir mostra um exemplo de armazenamento de chave-valor, no qual a chave é o nome da cidade e o valor é o endereço da Ulster University nessa cidade.

Algumas implementações do armazenamento de valor de chave fornecem mecanismos de armazenamento em cache, que melhoram muito seu desempenho.

Tudo o que é necessário para lidar com os itens armazenados no banco de dados é a chave. Os dados são armazenados na forma de uma string, JSON ou BLOB (Binary Large OBject).

Uma das maiores falhas nessa forma de banco de dados é a falta de consistência no nível do banco de dados. Isso pode ser adicionado pelos desenvolvedores com seu próprio código, mas, como mencionado anteriormente, isso adiciona mais esforço, complexidade e tempo.

O banco de dados NoSQL mais famoso construído em um key value store é o DynamoDB da Amazon.

Armazenamento de documentos

Os armazenamentos de documentos são semelhantes aos armazenamentos de valor-chave, pois não têm esquema e são baseados em um modelo de valor-chave. Ambos, portanto, compartilham muitas das mesmas vantagens e desvantagens. Ambos carecem de consistência no nível do banco de dados, o que abre caminho para que os aplicativos forneçam mais recursos de confiabilidade e consistência.

No entanto, existem diferenças fundamentais entre os dois.

Nos Armazenamentos de Documentos, os valores (documentos) fornecem codificação para os dados armazenados. Essas codificações podem ser XML, JSON ou BSON (JSON codificado em binário).

Além disso, a consulta com base em dados pode ser feita.

O aplicativo de banco de dados mais popular que depende de um Document Store é o MongoDB.

Armazenamento de colunas

Em um banco de dados Column Store, os dados são armazenados em colunas, em vez de serem armazenados em linhas, como é feito na maioria dos sistemas de gerenciamento de banco de dados relacional.

Um Armazenamento de Colunas é composto por uma ou mais Famílias de Colunas que agrupam logicamente determinadas colunas no banco de dados. Uma chave é usada para identificar e apontar para várias colunas no banco de dados, com um atributo keyspace que define o escopo dessa chave. Cada coluna contém tuplas de nomes e valores, ordenados e separados por vírgulas.

Os Column Stores têm acesso rápido de leitura/gravação aos dados armazenados. Em um armazenamento de coluna, as linhas que correspondem a uma única coluna são armazenadas como uma única entrada de disco. Isso torna o acesso mais rápido durante as operações de leitura/gravação.

Os bancos de dados mais populares que usam o armazenamento de colunas incluem BigTable, HBase e Cassandra do Google.

Base do gráfico

Em um banco de dados NoSQL Graph Base, uma estrutura de gráfico direcionada é usada para representar os dados. O grafo é composto por arestas e nós.

Formalmente, um grafo é uma representação de um conjunto de objetos, onde alguns pares de objetos são conectados por links. Os objetos interconectados são representados por abstrações matemáticas, chamadas de vértices, e os links que conectam alguns pares de vértices são chamados de arestas. Um conjunto de vértices e as arestas que os conectam é um grafo.

Isso ilustra a estrutura de um banco de dados de base de grafos que usa arestas e nós para representar e armazenar dados. Esses nós são organizados por alguns relacionamentos entre si, que são representados por arestas entre os nós. Tanto os nós quanto os relacionamentos têm algumas propriedades definidas.

Os bancos de dados gráficos são mais usados ​​em aplicativos de redes sociais. Os bancos de dados gráficos permitem que os desenvolvedores se concentrem mais nas relações entre os objetos do que nos próprios objetos. Nesse contexto, eles de fato permitem um ambiente escalável e fácil de usar.

Atualmente, InfoGrid e InfiniteGraph são os bancos de dados gráficos mais populares.

Sistemas de gerenciamento de banco de dados NoSQL

Para uma breve comparação dos bancos de dados, a tabela a seguir fornece uma breve comparação entre os diferentes sistemas de gerenciamento de banco de dados NoSQL.

O MongoDB tem um armazenamento de esquema flexível, o que significa que os objetos armazenados não precisam necessariamente ter a mesma estrutura ou campos. O MongoDB também possui alguns recursos de otimização, que distribuem as coletas de dados, resultando em melhoria geral de desempenho e um sistema mais equilibrado.

Outros sistemas de banco de dados NoSQL, como o Apache CouchDB, também são banco de dados do tipo armazenamento de documentos e compartilham muitos recursos com o MongoDB, com a exceção de que o banco de dados pode ser acessado usando APIs RESTful.

REST é um estilo de arquitetura que consiste em um conjunto coordenado de restrições de arquitetura aplicadas a componentes, conectores e elementos de dados, dentro da World Wide Web. Ele se baseia em um protocolo de comunicação sem estado, cliente-servidor, que pode ser armazenado em cache (por exemplo, o protocolo HTTP).

Os aplicativos RESTful usam solicitações HTTP para postar, ler e excluir dados.

Quanto aos bancos de dados de base de coluna, o Hypertable é um banco de dados NoSQL escrito em C++ e é baseado no BigTable do Google.

O Hypertable suporta a distribuição de armazenamentos de dados entre nós para maximizar a escalabilidade, assim como MongoDB e CouchDB.

Um dos bancos de dados NoSQL mais utilizados é o Cassandra, desenvolvido pelo Facebook.

Cassandra é um banco de dados de armazenamento de colunas que inclui muitos recursos voltados para confiabilidade e tolerância a falhas.

Em vez de fornecer uma visão detalhada de cada SGBD NoSQL, Cassandra e MongoDB, dois dos sistemas de gerenciamento de banco de dados NoSQL mais usados, serão explorados nas próximas subseções.

Cassandra

Cassandra é um sistema de gerenciamento de banco de dados desenvolvido pelo Facebook.

O objetivo por trás do Cassandra era criar um DBMS que não tivesse um único ponto de falha e fornecesse a máxima disponibilidade.

Cassandra é principalmente um banco de dados de armazenamento de colunas. Alguns estudos se referiram ao Cassandra como um sistema híbrido, inspirado no BigTable do Google, que é um banco de dados de armazenamento de colunas, e no DynamoDB da Amazon, que é um banco de dados de chave-valor.

Isso é obtido fornecendo um sistema de valor-chave, mas as chaves no Cassandra apontam para um conjunto de famílias de colunas, com dependência do sistema de arquivos distribuído BigTable do Google e dos recursos de disponibilidade do Dynamo (tabela de hash distribuída).

O Cassandra foi projetado para armazenar grandes quantidades de dados distribuídos em diferentes nós. O Cassandra é um SGBD projetado para lidar com grandes quantidades de dados, espalhados por vários servidores, ao mesmo tempo em que fornece um serviço altamente disponível sem nenhum ponto de falha, essencial para um grande serviço como o Facebook.

As principais características do Cassandra incluem:

• Nenhum ponto único de falha. Para que isso seja alcançado, o Cassandra deve ser executado em um cluster de nós, em vez de em uma única máquina. Isso não significa que os dados em cada cluster sejam os mesmos, mas o software de gerenciamento é. Quando ocorre uma falha em um dos nós, os dados desse nó ficarão inacessíveis. No entanto, outros nós (e dados) ainda estarão acessíveis.
• Distributed Hashing é um esquema que fornece funcionalidade de tabela de hash de forma que a adição ou remoção de um slot não altere significativamente o mapeamento de chaves para slots. Isso fornece a capacidade de distribuir a carga para servidores ou nós de acordo com sua capacidade e, por sua vez, minimizar o tempo de inatividade.
• Interface de cliente relativamente fácil de usar . Cassandra usa Apache Thrift para sua interface de cliente. O Apache Thrift fornece um cliente RPC de vários idiomas, mas a maioria dos desenvolvedores prefere alternativas de código aberto construídas sobre o Apple Thrift, como o Hector.
• Outros recursos de disponibilidade. Um dos recursos do Cassandra é a replicação de dados. Basicamente, ele espelha dados para outros nós no cluster. A replicação pode ser aleatória ou específica para maximizar a proteção de dados colocando em um nó em um data center diferente, por exemplo. Outro recurso encontrado no Cassandra é a política de particionamento. A política de particionamento decide onde em qual nó colocar a chave. Isso também pode ser aleatório ou em ordem. Ao usar os dois tipos de políticas de particionamento, o Cassandra pode encontrar um equilíbrio entre balanceamento de carga e otimização de desempenho de consulta.
• Consistência. Recursos como replicação tornam a consistência um desafio. Isso se deve ao fato de que todos os nós devem estar atualizados a qualquer momento com os valores mais recentes ou no momento em que uma operação de leitura é acionada. Eventualmente, porém, o Cassandra tenta manter um equilíbrio entre as ações de replicação e as ações de leitura/gravação, fornecendo essa personalização ao desenvolvedor.
• Ações de leitura/gravação. O cliente envia uma solicitação para um único nó do Cassandra. O nó, de acordo com a política de replicação, armazena os dados no cluster. Cada nó primeiro executa a alteração de dados no log de confirmação e, em seguida, atualiza a estrutura da tabela com a alteração, ambas feitas de forma síncrona. A operação de leitura também é muito semelhante, uma solicitação de leitura é enviada para um único nó, e esse único nó é aquele que determina qual nó contém os dados, de acordo com a política de particionamento/posicionamento.

MongoDB

O MongoDB é um banco de dados orientado a documentos e livre de esquema escrito em C++. O banco de dados é baseado em armazenamento de documentos, o que significa que ele armazena valores (referidos como documentos) na forma de dados codificados.

A escolha do formato codificado no MongoDB é JSON. Isso é poderoso, porque mesmo que os dados estejam aninhados em documentos JSON, eles ainda serão consultáveis ​​e indexáveis ​​.

As subseções a seguir descrevem alguns dos principais recursos disponíveis no MongoDB.

Fragmentos

Sharding é o particionamento e distribuição de dados em várias máquinas (nós). Um shard é uma coleção de nós do MongoDB, em contraste com o Cassandra, onde os nós são distribuídos simetricamente. O uso de estilhaços também significa a capacidade de escalar horizontalmente em vários nós. Caso haja um aplicativo usando um único servidor de banco de dados, ele pode ser convertido em cluster sharded com poucas alterações no código do aplicativo original, devido à maneira como o sharding é feito pelo MongoDB. oftware é quase completamente desacoplado das APIs públicas expostas ao lado do cliente.

Linguagem de consulta Mongo

Conforme discutido anteriormente, o MongoDB usa uma API RESTful. Para recuperar determinados documentos de uma coleção de banco de dados, é criado um documento de consulta contendo os campos aos quais os documentos desejados devem corresponder.

Ações

No MongoDB, existe um grupo de servidores chamados roteadores. Cada um atua como um servidor para um ou mais clientes. Da mesma forma, o cluster contém um grupo de servidores chamados de servidores de configuração. Cada um contém uma cópia dos metadados indicando qual fragmento contém quais dados. As ações de leitura ou gravação são enviadas dos clientes para um dos servidores roteadores no cluster e são roteadas automaticamente por esse servidor para os shards apropriados que contêm os dados com a ajuda dos servidores de configuração.

Semelhante ao Cassandra, um shard no MongoDB possui um esquema de replicação de dados, que cria um conjunto de réplicas de cada shard que contém exatamente os mesmos dados. Existem dois tipos de esquemas de réplica no MongoDB: replicação mestre-escravo e replicação de conjunto de réplicas. O Replica-Set fornece mais automação e melhor tratamento de falhas, enquanto o Master-Slave às vezes requer a intervenção do administrador. Independentemente do esquema de replicação, a qualquer momento em um conjunto de réplicas, apenas um estilhaço atua como estilhaço primário, todos os outros estilhaços de réplica são estilhaços secundários. Todas as operações de gravação e leitura vão para o estilhaço primário e são distribuídas uniformemente (se necessário) para os outros estilhaços secundários no conjunto.

No gráfico abaixo, vemos a arquitetura do MongoDB explicada acima, mostrando os servidores roteadores em verde, os servidores de configuração em azul e os shards que contêm os nós do MongoDB.

Deve-se notar que o sharding (ou compartilhamento de dados entre shards) no MongoDB é totalmente automático, o que reduz a taxa de falhas e torna o MongoDB um sistema de gerenciamento de banco de dados altamente escalável.

Estruturas de indexação para bancos de dados NoSQL

Indexação é o processo de associar uma chave com a localização de um registro de dados correspondente em um SGBD. Existem muitas estruturas de dados de indexação usadas em bancos de dados NoSQL. As seções a seguir discutirão brevemente alguns dos métodos mais comuns; ou seja, indexação B-Tree, indexação T-Tree e indexação O2-Tree.

Indexação de Árvore B

B-Tree é uma das estruturas de índice mais comuns em SGBDs.

Em árvores B, os nós internos podem ter um número variável de nós filhos dentro de algum intervalo predefinido.

Uma grande diferença de outras estruturas de árvore, como o AVL, é que o B-Tree permite que os nós tenham um número variável de nós filhos, o que significa menos balanceamento de árvore, mas mais espaço desperdiçado.

A B+-Tree é uma das variantes mais populares das B-Trees. O B+-Tree é uma melhoria em relação ao B-Tree que requer que todas as chaves residam nas folhas.

Indexação T-Tree

A estrutura de dados do T-Trees foi projetada combinando recursos de AVL-Trees e B-Trees.

As AVL-Trees são um tipo de árvore de busca binária auto-balanceada, enquanto as B-Trees são desbalanceadas e cada nó pode ter um número diferente de filhos.

Em uma T-Tree, a estrutura é muito semelhante à da AVL-Tree e da B-Tree.

Cada nó armazena mais de uma tupla {key-value, pointer}. Além disso, a pesquisa binária é utilizada em combinação com os nós de múltiplas tuplas para produzir melhor armazenamento e desempenho.

Uma árvore T tem três tipos de nós: um nó T que tem um filho direito e esquerdo, um nó folha sem filhos e um nó meia folha com apenas um filho.

Acredita-se que as T-Trees tenham melhor desempenho geral do que as AVL-Trees.

Indexação da Árvore O2

O O2-Tree é basicamente uma melhoria em relação às árvores Red-Black, uma forma de árvore Binary-Search, na qual os nós folha contêm as tuplas {key value, pointer}.

O2-Tree foi proposto para melhorar o desempenho dos métodos de indexação atuais. Uma O2-Tree de ordem m (m ≥ 2), onde m é o grau mínimo da árvore, satisfaz as seguintes propriedades:

• Cada nó é vermelho ou preto. A raiz é preta.
• Cada nó folha é colorido em preto e consiste em um bloco ou página que contém pares “valor-chave, ponteiro de registro”.
• Se um nó é vermelho, então seus dois filhos são pretos.
• Para cada nó interno, todos os caminhos simples do nó para os nós-folha descendentes contêm o mesmo número de nós pretos. Cada nó interno contém um único valor de chave.
• Os nós-folha são blocos que possuem entre ⌈m/2⌉ e m pares “chave-valor, registro-apontador”.
• Se uma árvore tem um único nó, então deve ser uma folha, que é a raiz da árvore, e pode ter entre 1 a m itens de dados-chave.
• Os nós folha são vinculados duplamente nas direções para frente e para trás.

Aqui, vemos uma comparação direta de desempenho entre O2-Tree, T-Tree, B+-Tree, AVL-Tree e Red-Black Tree:

A ordem da T-Tree, B+-Tree e da O2-Tree usada foi m = 512.

O tempo é registrado para as operações de busca, inserção e exclusão com taxas de atualização variando entre 0%-100% para um índice de 50 milhões de registros, com as operações resultando na adição de mais 50 milhões de registros ao índice.

É claro que com uma taxa de atualização de 0-10%, o B-Tree e o T-Tree têm um desempenho melhor do que o O2-Tree. No entanto, com o aumento da taxa de atualização, o índice O2-Tree tem um desempenho significativamente melhor do que a maioria das outras estruturas de dados, com as estruturas B-Tree e Red-Black Tree sofrendo mais.

O caso do NoSQL?

Uma rápida introdução aos bancos de dados NoSQL, destacando as principais áreas em que os bancos de dados relacionais tradicionais ficam aquém, leva à primeira conclusão:

Embora os bancos de dados relacionais ofereçam consistência, eles não são otimizados para alto desempenho em aplicativos em que dados massivos são armazenados e processados ​​com frequência.

Os bancos de dados NoSQL ganharam muita popularidade devido ao alto desempenho, alta escalabilidade e facilidade de acesso; no entanto, eles ainda carecem de recursos que forneçam consistência e confiabilidade.

Felizmente, vários SGBDs NoSQL abordam esses desafios oferecendo novos recursos para aprimorar a escalabilidade e a confiabilidade.

Nem todos os sistemas de banco de dados NoSQL têm um desempenho melhor do que os bancos de dados relacionais.

MongoDB e Cassandra têm desempenho semelhante e, na maioria dos casos, melhor do que bancos de dados relacionais em operações de gravação e exclusão.

Não há correlação direta entre o tipo de armazenamento e o desempenho de um SGBD NoSQL. As implementações NoSQL sofrem alterações, portanto, o desempenho pode variar.

Portanto, as medições de desempenho entre tipos de banco de dados em diferentes estudos devem sempre ser atualizadas com as versões mais recentes do software de banco de dados para que esses números sejam precisos.

Embora eu não possa oferecer um veredicto definitivo sobre o desempenho, aqui estão alguns pontos a serem lembrados:

• A indexação tradicional B-Tree e T-Tree é comumente usada em bancos de dados tradicionais.
• Um estudo ofereceu melhorias e aprimoramentos combinando as características de várias estruturas de indexação para criar o O2-Tree.
• O O2-Tree superou outras estruturas na maioria dos testes, especialmente com grandes conjuntos de dados e altas taxas de atualização.
• A estrutura B-Tree apresentou o pior desempenho de todas as estruturas de indexação abordadas neste artigo.

Mais trabalho pode e deve ser feito para melhorar a consistência dos SGBDs NoSQL. A integração de ambos os sistemas, NoSQL e bancos de dados relacionais, é uma área a ser explorada.

Finalmente, é importante notar que o NoSQL é uma boa adição aos padrões de banco de dados existentes, mas com algumas ressalvas importantes. O NoSQL negocia recursos de confiabilidade e consistência para desempenho e escalabilidade absolutos. Isso o torna uma solução especializada, pois o número de aplicativos que podem contar com bancos de dados NoSQL permanece limitado.

O lado de cima? A especialização pode não oferecer muita flexibilidade, mas quando você deseja realizar um trabalho especializado da forma mais rápida e eficiente possível, não precisa de um canivete suíço. Você precisa do NoSQL.