Qual é a diferença entre os bancos de dados NoSQL e relacionais?
O Azure Cosmos DB é caracterizado como não relacional e horizontalmente escalonável.
Escala horizontal versus escala vertical
Os bancos de dados relacionais normalmente crescem aumentando o tamanho da VM ou da computação na qual estão hospedados. Bancos de dados NoSQL como o Azure Cosmos DB dimensionam adicionando mais servidores ou nós. Isso é conhecido como expansão. Esses nós também são conhecidos como partições físicas no Cosmos DB. Os dados armazenados nessas partições físicas precisam ser organizados para serem acessados com eficiência posteriormente.
Eles são encaminhados para partições físicas diferentes usando o valor de uma propriedade obrigatória em cada documento. Essa propriedade é chamada de chave de partição de contêiner, e essa chave de partição precisa ser especificada ao criar o contêiner. Passar a chave de partição quando os dados são gravados ou lidos de um contêiner garante que as operações sejam eficientes direcionando apenas a solicitação para a partição em que estão armazenados.
Embora a necessidade de uma chave de partição pareça ser uma restrição, ela tem alguns benefícios enormes. Normalmente, o banco de dados relacional possivelmente aumentará para menos de 100 TB no máximo. Um banco de dados NoSQL pode aumentar para tamanho ilimitado e pode fazer isso sem nenhum impacto aos tempos de resposta ao acessar dados de qualquer partição única.
Além disso, à medida que partições são adicionadas, também é mais possível adicionar computação e a quantidade de processamento com suporte do banco de dados aumenta simultaneamente. Isso significa que ele também pode dar suporte a usuários mais simultâneos. Também sem impacto no desempenho.
Bancos de dados não relacionais versus relacionais
A segunda definição da característica de um banco de dados NoSQL é que não há chaves estrangeiras, restrições nem relações impostas de nenhum tipo entre os dados. Como os dados de um banco de dados NoSQL são armazenados em diferentes servidores físicos, impor restrições ou relações ou estabelecer bloqueios a dados resultará em um desempenho negativo ou imprevisível.
No entanto, não ter relações impostas não significa que você não pode gerenciar entidades que têm relações em um banco de dados NoSQL, significa apenas que você precisa fazer isso de modo diferente.
Por que esses tipos de bancos de dados são tão diferentes?
Entender como a economia da computação mudou desde que os bancos de dados relacionais foram introduzidos pela primeira vez pode ajudar a explicar por que esses dois tipos de bancos de dados são tão diferentes.
Quando os bancos de dados relacionais foram inventados em 1970, os custos de armazenamento e memória foram altos em relação à computação. A meta de normalização de um modelo de banco de dados era reduzir o custo duplicado e, portanto, os custos em um banco de dados. O mecanismo de banco de dados aplicaria bloqueios e travamentos para impor semântica estrita (atomicidade, consistência, isolamento, durabilidade) à medida que realizou operações em todas as partes necessárias de dados juntos. Os bloqueios nos dados garantem dados consistentes, mas com compensações em simultaneidade, latência e disponibilidade.
Hoje, o custo de armazenamento e memória é relativamente barato em comparação à computação, portanto, para ser econômico, não precisamos mais de otimização para eficiência de armazenamento. Com cargas de trabalho que exigem níveis cada vez maiores de simultaneidade e disponibilidade e latências menores, havia a necessidade de um novo tipo de banco de dados otimizado para esses requisitos, assim, foram criados os bancos de dados NoSQL.
Também é por esses motivos que uma das metas na modelagem de dados para um banco de dados NoSQL é fazer isso de modo a garantir que a leitura ou a gravação de dados seja eficiente em termos de computação. No entanto, como os operadores relacionais, como junções entre documentos, não existem em bancos de dados NoSQL, é necessário que eles sejam armazenados, pois o aplicativo os utiliza para ser o mais eficiente. Com frequência, os dados precisam ser desnormalizados, duplicados ou armazenados de outra maneira de modo a interromper muitas das regras de normalização relacionais usadas para a modelagem de dados relacionais.
É possível usar o NoSQL para cargas de trabalho relacionais?
Neste ponto, você pode estar se perguntando se os bancos de dados NoSQL são apropriados para uso em cargas de trabalho relacionais. A resposta é sim. Os bancos de dados NoSQL podem ser certamente usados para cargas de trabalho em que existam relações entre entidades diferentes.
Os bancos de dados NoSQL geralmente são usados quando um banco de dados relacional não pode atender às necessidades de desempenho, escala ou disponibilidade desejadas do aplicativo.
As técnicas para o design de um banco de dados NoSQL são diferentes das técnicas para a modelagem dos dados de um banco de dados relacional. Essas técnicas também não são intuitivas para alguém com conhecimento de design de banco de dados relacional. Algumas das melhores práticas que você aprende para criar bancos de dados relacionais costumam ser antipadrões durante a criação de um banco de dados NoSQL.
Para o restante deste módulo e no módulo de modelagem avançada, vamos orientá-lo pelas técnicas usadas para modelar dados de um modo que resultará em um banco de dados NoSQL de alto desempenho.