Qual é a diferença entre NoSQL e bancos de dados relacionais?
O Azure Cosmos DB é caracterizado como não relacional e horizontalmente escalável.
Escala horizontal versus escala vertical
Os bancos de dados relacionais normalmente crescem aumentando o tamanho da VM ou da computação em que estão hospedados. Os bancos de dados NoSQL, como o Azure Cosmos DB, são dimensionados adicionando mais servidores ou nós. Isso é conhecido como scale-out. 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 que possam ser acessados com eficiência mais tarde.
Os dados são roteados para partições físicas diferentes usando o valor de uma propriedade necessária em cada documento. Essa propriedade é chamada de chave de partição do contêiner, 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 ela está armazenada.
Embora a necessidade de uma chave de partição possa parecer uma restrição, ela tem alguns benefícios enormes. Normalmente, o banco de dados relacional possivelmente crescerá para menos de 100 TB no máximo. Um banco de dados NoSQL pode crescer para um tamanho ilimitado e pode fazê-lo sem qualquer impacto nos tempos de resposta quando está acessando dados de qualquer partição única.
Além disso, à medida que as partições são adicionadas, também é adicionada mais computação e a quantidade de processamento suportada pelo banco de dados cresce simultaneamente. Isso significa que ele também pode suportar mais usuários simultâneos. Também sem impacto no desempenho.
Bancos de dados não relacionais versus relacionais
A segunda característica definidora de um banco de dados NoSQL é que não há chaves estrangeiras, restrições ou relações impostas de qualquer tipo entre partes de dados. Como os dados em um banco de dados NoSQL são armazenados em servidores físicos diferentes, impor restrições ou relacionamentos ou colocar bloqueios nos dados resultaria em desempenho negativo ou imprevisível.
No entanto, não ter relações impostas não significa que você não possa gerenciar entidades que tenham relacionamentos em um banco de dados NoSQL, significa apenas que você precisa fazer isso de forma diferente.
Por que esses tipos de banco 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 eram altos em relação à computação. O objetivo de normalizar um modelo de banco de dados era reduzir dados duplicados e, portanto, o custo dentro de um banco de dados. O mecanismo de banco de dados aplicaria bloqueios e travas para impor semântica ACID estrita (atomicidade, consistência, isolamento, durabilidade) à medida que realizava operações em todos os dados necessários juntos. Os bloqueios nos dados garantiram 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 com a computação, portanto, para ser rentável, não precisamos mais otimizar para a eficiência do armazenamento. Com cargas de trabalho exigindo níveis crescentes de simultaneidade e disponibilidade e latências mais baixas, houve a necessidade de um novo tipo de banco de dados otimizado para esses requisitos, e assim nasceram os bancos de dados NoSQL.
É também por esses motivos que um dos objetivos na modelagem de dados para um banco de dados NoSQL é fazê-lo de uma maneira que garanta que a leitura ou gravação de dados seja computacionalmente eficiente. Em parte, como operadores relacionais como junções entre documentos não existem em bancos de dados NoSQL, os dados devem ser armazenados à medida que o aplicativo os usa para que sejam mais eficientes. Muitas vezes, os dados precisam ser desnormalizados, duplicados ou armazenados de uma forma que quebre muitas das regras de normalização relacional usadas para modelagem de dados relacionais.
Você pode 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. E a resposta é sim! Os bancos de dados NoSQL podem absolutamente ser usados para cargas de trabalho onde existem relações entre entidades diferentes.
Os bancos de dados NoSQL são frequentemente usados quando um banco de dados relacional não pode atender às necessidades desejadas de desempenho, escala ou disponibilidade do aplicativo.
As técnicas para projetar um banco de dados NoSQL são diferentes das técnicas para modelar dados para um banco de dados relacional. Essas técnicas também não são intuitivas para alguém com experiência em design de banco de dados relacional. Algumas das práticas recomendadas que você aprende para criar bancos de dados relacionais geralmente são antipadrões quando você está projetando para um banco de dados NoSQL.
Para o restante deste módulo e no módulo de modelagem avançada, vamos orientá-lo através das técnicas que são usadas para modelar dados de uma maneira que resultará em um banco de dados NoSQL de alto desempenho.