Características comuns de NoSQL - dummies

Os livros e blogs NoSQL oferecem opiniões diferentes sobre o que é um banco de dados NoSQL. Quatro recursos principais do NoSQL, mostrados na lista a seguir, aplicam-se à maioria dos bancos de dados NoSQL. A lista compara NoSQL com o SGBD relacional tradicional:

• Esquema agnóstico: Um esquema de banco de dados é a descrição de todas as estruturas de dados e dados possíveis em um banco de dados relacional. Com um banco de dados NoSQL, um esquema não é necessário, dando-lhe a liberdade de armazenar informações sem fazer projeto de esquema inicial.

• Não relacionamentos: As relações em um banco de dados estabelecem conexões entre as tabelas de dados. Por exemplo, uma lista de detalhes da transação pode ser conectada a uma lista separada de detalhes de entrega. Com um banco de dados NoSQL, esta informação é armazenada como um agregado - um único registro com tudo sobre a transação, incluindo o endereço de entrega.

• Hardware de mercadorias: Alguns bancos de dados são projetados para operar melhor (ou somente) com hardware especializado em armazenamento e processamento. Com um banco de dados NoSQL, podem ser usados ​​servidores baratos em prateleira. Adicionando mais desses servidores baratos, os bancos de dados NoSQL podem escalar para gerenciar mais dados.

• Altamente distribuível: Os bancos de dados distribuídos podem armazenar e processar um conjunto de informações em mais de um dispositivo. Com um banco de dados NoSQL, um conjunto de servidores pode ser usado para armazenar um único banco de dados grande.

Schema agnostic

Os bancos de dados NoSQL são agnósticos de esquema. Você não precisa fazer muito trabalho de design inicial antes de poder armazenar dados em bancos de dados NoSQL. Você pode começar a codificar e armazenar e recuperar dados sem saber como o banco de dados armazena e trabalha internamente. (Se e quando você precisar de funcionalidade avançada, você pode adicionar manualmente mais índices ou ajustar estruturas de armazenamento de dados.) O agnosticismo de esquema pode ser a diferença mais significativa entre o NoSQL e os bancos de dados relacionais.

O grande benefício para um banco de dados agnóstico de esquema é que o tempo de desenvolvimento é reduzido. Este benefício aumenta conforme você passa por vários lançamentos de desenvolvimento e precisa alterar as estruturas de dados internas no banco de dados.

Por exemplo, em um RDBMS tradicional, você passa por um processo de redesenhar o esquema. O esquema instrui o banco de dados sobre quais dados esperar. Altere os dados armazenados ou estruturas, e você deve reinstruir o banco de dados usando um esquema modificado. Se você fizesse uma mudança, você precisaria dedicar muito tempo a decidir como reconfigurar os dados existentes. Nos bancos de dados NoSQL, você simplesmente armazena uma estrutura de dados diferente. Não há necessidade de informar o banco de dados de antemão.

Talvez seja necessário modificar suas consultas de acordo, talvez adicione o índice específico (como um índice de intervalo inteiro para permitir menos e maior que as consultas específicas de tipo de dados), mas todo o processo é muito menos doloroso do que com um RDBMS.

RDBMS decolou por causa de sua flexibilidade e porque, ao usar o SQL, acelerou a alteração de uma consulta. Os bancos de dados NoSQL fornecem essa flexibilidade para alterar o esquema e a consulta, que é uma das principais razões pelas quais eles serão cada vez mais adotados ao longo do tempo.

Mesmo na consulta, talvez você não precise se preocupar demais com conhecer as mudanças de esquema - considere um índice em um número de conta de campo, onde número de conta pode ser localizado em qualquer lugar em um documento que esteja armazenado em um banco de dados NoSQL. Você pode alterar a estrutura e mudar a localização onde número de conta está armazenado, e se o elemento tiver o mesmo nome em outro lugar no documento, ainda está disponível para consulta sem alterações no mecanismo de consulta.

Observe que nem todos os bancos de dados NoSQL são totalmente agnósticos de esquema. Alguns, como o HBase, exigem que você pare o banco de dados para alterar as definições das colunas. Eles ainda são considerados bancos de dados NoSQL porque nem todos os campos definidos (colunas neste caso) devem ser conhecidos antecipadamente para cada registro - apenas as famílias das colunas.

RDBMS permite que os campos individuais nos registros sejam identificados como valores nulos . O problema com um RDBMS é que o tamanho e o desempenho dos dados armazenados são negativamente afetados quando o armazenamento é reservado para valores nulos, apenas no caso de o registro ter possivel em algum momento ter um valor nessa coluna. Em Cassandra, você simplesmente não fornece os dados dessa coluna, que resolve o problema.

Nonrelacional

Os sistemas de gerenciamento de banco de dados relacionais têm sido a maneira dominante de armazenar dados de aplicativos por mais de 20 anos. Uma grande quantidade de trabalho matemático foi feito para provar a teoria que os sustenta.

Este suporte descreve como as tabelas se relacionam umas com as outras. Uma única linha de Ordem pode estar relacionada a muitas linhas de endereço de entrega, mas cada linha de endereço de entrega também se relaciona com várias linhas de pedidos. Este é um muitos - a - muitas relações .

Os bancos de dados NoSQL não possuem este conceito de relações entre seus registros. Eles desnormalizam os dados em vez disso. Isso significa que em um banco de dados NoSQL teria uma estrutura de Pedido com o endereço de entrega embutido. Isso significa que o endereço de entrega é duplicado em cada linha de Ordem que o usa. Esta abordagem tem a vantagem de não exigir juntas complexas de tempo de consulta em várias estruturas de dados (tabelas).

Os bancos de dados NoSQL não armazenam informações sobre como registros individuais se relacionam com outros registros no banco de dados, o que pode soar como uma limitação. No entanto, os bancos de dados NoSQL são mais flexíveis em termos de estruturas de dados que você pode armazenar.

Considere um pedido de um revendedor online. A ordem pode incluir códigos de produtos, quantidades, preços de itens e descrições de itens, bem como informações sobre o pedido de pessoa, como endereço de entrega e informações de pagamento.

Ao invés de inserir dez linhas em uma variedade de tabelas em um banco de dados relacional, você pode armazenar uma estrutura única para todas essas informações de ordem - digamos, como documento JSON ou XML.

Na teoria do banco de dados relacionais, o objetivo é normalizar seus dados (ou seja, organizar os campos e tabelas para remover dados duplicados). Nos bancos de dados NoSQL - especialmente bancos de dados de documentos ou agregados - você geralmente desregulam dados deliberadamente, armazenando alguns dados várias vezes.

Você pode armazenar, por exemplo, "Endereço de entrega do cliente" várias vezes em muitas ordens que um cliente faz ao longo do tempo, em vez de armazená-lo uma vez e se referir a ele em vários pedidos. Isso requer espaço de armazenamento extra, e um pouco de previsão no gerenciamento em sua aplicação. Então, por que?

Existem duas vantagens para armazenar dados várias vezes:

• Armazenamento e recuperação fáceis: Apenas salve e obtenha um único registro.

• Velocidade de consulta: Em bancos de dados relacionais, você junta informações e adiciona restrições em tabelas no horário de consulta. Isso pode exigir que o mecanismo do banco de dados avalie muitas tabelas. Quanto mais restrições de consulta você possui em diferentes tabelas, mais você reduz a velocidade da consulta. (É por isso que um RDBMS tem visualizações précomputadas.) Em um banco de dados NoSQL, todas as informações que você precisa para avaliar sua consulta estão em um único documento. Portanto, você pode determinar rapidamente a lista de documentos correspondentes.

As visualizações relacionais e as desnormalizações do NoSQL são diferentes abordagens para o problema da disseminação de dados entre os registros. No NoSQL, você pode ter que manter várias desmineralizações que representam diferentes visualizações dos mesmos dados. Esta abordagem aumenta o custo do armazenamento, mas oferece muito melhor tempo de consulta.

Dado o custo de armazenamento cada vez maior e o aumento da velocidade de desenvolvimento e consulta, os dados desnormalizados (aka visualizações materializadas ) não são um motivo assassino para descontar as soluções NoSQL. É apenas uma maneira diferente de abordar o mesmo problema, com suas próprias vantagens e desvantagens.

O NoSQL é altamente distribuível e usa hardware de mercadorias

Em muitos bancos de dados NoSQL, uma decisão de design chave é usar vários computadores para armazenar dados para um único banco de dados, em vez de ter todo o banco de dados em um único servidor.

Armazenar dados em várias máquinas e permitir que seja consultado é difícil. Você deve enviar a consulta a todos os servidores e aguarde uma resposta. Esperemos que você configure as máquinas para que elas sejam rápidas o suficiente para conversar entre si para lidar com consultas distribuídas!

A principal vantagem dessa abordagem é o caso de conjuntos de dados muito grandes, pois, para alguns requisitos de armazenamento, mesmo o maior servidor único disponível não pode armazenar nem processar todos os dados que você precisa. Considere todas as mensagens no Twitter e no Facebook. Você precisa de um mecanismo distribuído para gerir eficazmente todos esses dados, mesmo que seja principalmente sobre o que as pessoas tiveram para o café da manhã e vídeos de gato fofos.

Uma vantagem de distribuir seu banco de dados é que você pode usar servidores mais baratos, chamados servidores de commodities .Mesmo para conjuntos de dados menores, pode ser mais barato comprar três servidores de produtos básicos em vez de um único servidor de maior potência.

Outra vantagem importante é que adicionar alta disponibilidade é mais fácil; você já está a meio caminho distribuindo seus dados. Se você replicar seus dados uma ou duas vezes em outros servidores no cluster, seus dados ainda estarão acessíveis, mesmo que um dos servidores falhe, queime e morra.

Nem todos os bancos de dados de código aberto suportam alta disponibilidade, a menos que você compre a versão suportada e paga do banco de dados da empresa que a desenvolve.

Uma exceção à regra altamente distribuível é a de bancos de dados gráficos. Para responder efetivamente certas consultas gráficas em tempo hábil, os dados precisam ser armazenados em um único servidor. Ninguém resolveu este problema específico ainda.

Considere cuidadosamente se você precisa de uma loja tripla ou uma loja gráfica. As lojas triplas geralmente são distribuíveis, enquanto as lojas de gráficos não são. O que você precisa depende das consultas que você deve suportar.