SQL versus Dados NoSQL
Dica
Esse conteúdo é um trecho do livro eletrônico, para Projetar os Aplicativos .NET nativos de nuvem para o Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.
Relacional (SQL) e não relacional (NoSQL) são dois tipos de sistemas de banco de dados normalmente implementados em aplicativos nativos de nuvem. Eles são compilados de forma diferente, armazenam dados de forma diferente e acessados de forma diferente. Nesta seção, examinaremos ambos. Mais adiante neste capítulo, examinaremos uma tecnologia de banco de dados emergente chamada NewSQL.
Os bancos de dados relacionais têm sido uma tecnologia predominante há décadas. Eles são maduros, comprovados e amplamente implementados. Produtos de banco de dados concorrentes, ferramentas e experiência são abundantes. Os bancos de dados relacionais fornecem um repositório de tabelas de dados relacionadas. Essas tabelas têm um esquema fixo, usam SQL (Linguagem de Consulta Estruturada) para gerenciar dados e dão suporte a garantias de ACID: atomicidade, consistência, isolamento e durabilidade.
Os bancos de dados NoSQL são armazenamentos de dados não relacionais de alto desempenho. Eles se destacam em suas características de facilidade de uso, escalabilidade, resiliência e disponibilidade. Em vez de unir tabelas de dados normalizados, o NoSQL armazena dados não estruturados ou semiestruturados, muitas vezes em pares chave-valor ou documentos JSON. Os bancos de dados NoSQL normalmente não fornecem garantias de ACID além do escopo de uma única partição de banco de dados. Serviços de alto volume que exigem tempo de resposta de sub-segundo favorecem os armazenamentos de dados NoSQL.
O impacto das tecnologias NoSQL para sistemas nativos de nuvem distribuídos não pode ser exagerado. A proliferação de novas tecnologias de dados nesse espaço interrompeu soluções que antes dependiam exclusivamente de bancos de dados relacionais.
Os bancos de dados NoSQL incluem vários modelos diferentes para acessar e gerenciar dados, cada um adequado para casos de uso específicos. A Figura 5-9 apresenta quatro modelos comuns.
Figura 5-9: modelos de dados para bancos de dados NoSQL
| Modelar | Características |
|---|---|
| Repositório de documentos | Os dados e os metadados são armazenados hierarquicamente em documentos baseados em JSON no banco de dados. |
| Key Value Store | O mais simples dos bancos de dados NoSQL, que são representados como uma coleção de pares chave-valor. |
| Wide-Column Store | Os dados relacionados são armazenados como um conjunto de pares de valor/chave aninhados em uma única coluna. |
| Repositório de grafo | Os dados são armazenados em uma estrutura de grafo como propriedades de nó, borda e dados. |
O Teorema de CAP
Como forma de entender as diferenças entre esses tipos de bancos de dados, considere o teorema CAP, um conjunto de princípios aplicados a sistemas distribuídos que armazenam o estado. A Figura 5-10 mostra as três propriedades do teorema CAP.
Figura 5-10. O Teorema de CAP
O teorema afirma que os sistemas de dados distribuídos oferecerão uma compensação entre consistência, disponibilidade e tolerância à partição. E que qualquer banco de dados só pode garantir duas das três propriedades:
Consistência. Cada nó no cluster responde com os dados mais recentes, mesmo se o sistema precisar bloquear a solicitação até que todas as réplicas sejam atualizadas. Se você consultar um "sistema consistente" para um item atualmente atualizado, aguardará essa resposta até que todas as réplicas sejam atualizadas com êxito. No entanto, você receberá os dados mais atuais. Deve-se entender que o termo "consistência" como é usado no contexto do teorema CAP tem um significado técnico distinto da maneira como a "consistência" é definida no contexto das garantias de ACID.
Disponibilidade. Cada solicitação recebida por um nó que não falha no sistema precisa resultar em uma resposta. Para simplificar, se você consultar um “sistema disponível” para um item que está sendo atualizado, obterá a melhor resposta possível que o serviço pode fornecer nesse momento. Porém, observe que a “disponibilidade” definida pelo teorema CAP é tecnicamente diferente da “alta disponibilidade”, pois ela é convencionalmente conhecida para sistemas distribuídos.
Tolerância a Partição. Garante que o sistema continue operando mesmo que um nó de dados replicado falhe ou perca a conectividade com outros nós de dados replicados.
O teorema de CAP explica as compensações associadas ao gerenciamento de consistência e disponibilidade durante uma partição de rede; no entanto, as compensações em relação à consistência e ao desempenho também existem com a ausência de uma partição de rede. O teorema de CAP geralmente é estendido ainda mais ao PACELC para explicar as compensações de forma mais abrangente.
Observação
Mesmo se você escolher a disponibilidade em vez da consistência, em tempos de partição de rede, a disponibilidade será afetada. O sistema disponível do CAP está mais disponível para alguns dos clientes, mas não necessariamente “altamente disponível” para todos os clientes.
Os bancos de dados relacionais normalmente fornecem consistência e disponibilidade, mas não tolerância à partição. Normalmente, eles são provisionados em um único servidor e escalados verticalmente adicionando mais recursos ao computador.
Muitos sistemas de banco de dados relacionais dão suporte a recursos de replicação internos em que cópias do banco de dados primário podem ser feitas em outras instâncias de servidor secundário. As operações de gravação são feitas na instância primária e replicadas para cada uma das secundárias. Após uma falha, a instância primária pode fazer failover para um secundário para fornecer alta disponibilidade. Secundários também podem ser usados para distribuir operações de leitura. Embora as operações de gravação sempre vão contra a réplica primária, as operações de leitura podem ser roteadas para qualquer uma das secundárias para reduzir a carga do sistema.
Os dados também podem ser particionados horizontalmente em vários nós, como com a fragmentação. No entanto, a fragmentação aumenta drasticamente a sobrecarga operacional dividindo dados em muitas partes que não podem se comunicar facilmente. Pode ser caro e demorado para gerenciar. Recursos relacionais que incluem junções de tabela, transações e integridade referencial exigem penalidades de desempenho acentuadas em implantações fragmentadas.
Os objetivos de ponto de recuperação e consistência de replicação podem ser ajustados configurando se a replicação ocorre de forma síncrona ou assíncrona. Se as réplicas de dados perderem a conectividade de rede em um cluster de banco de dados relacional “altamente consistente” ou síncrono, você não poderá gravar no banco de dados. O sistema rejeitaria a operação de gravação, pois não pode replicar essa alteração para a outra réplica de dados. Cada réplica de dados precisa ser atualizada antes que a transação possa ser concluída.
Os bancos de dados NoSQL normalmente dão suporte à alta disponibilidade e tolerância à partição. Eles escalam horizontalmente, muitas vezes entre os servidores de commodities. Essa abordagem fornece uma disponibilidade tremenda, dentro e entre regiões geográficas, a um custo reduzido. Você particiona e replica dados nesses computadores ou nós, fornecendo redundância e tolerância a falhas. A consistência normalmente é ajustada por meio de protocolos de consenso ou mecanismos de quorum. Eles fornecem mais controle ao navegar pelas compensações entre o ajuste de replicação síncrono versus assíncrono em sistemas relacionais.
Se as réplicas de dados perderem a conectividade em um cluster de banco de dados NoSQL "altamente disponível", você ainda poderá concluir uma operação de gravação no banco de dados. O cluster de banco de dados permitiria a operação de gravação e atualizaria cada réplica de dados conforme ela se torna disponível. Bancos de dados NoSQL que dão suporte a várias réplicas graváveis podem fortalecer ainda mais a alta disponibilidade, evitando a necessidade de failover ao otimizar o objetivo de tempo de recuperação.
Os bancos de dados NoSQL modernos normalmente implementam recursos de particionamento como um recurso de design do sistema. O gerenciamento de partição normalmente é interno para o banco de dados e o roteamento é obtido por meio de dicas de posicionamento, muitas vezes chamadas de chaves de partição. Um modelo de dados flexível permite que os bancos de dados NoSQL reduzam a carga do gerenciamento de esquemas e melhorem a disponibilidade ao implantar atualizações de aplicativo que exigem alterações no modelo de dados.
A alta disponibilidade e a escalabilidade maciça geralmente são mais críticas para os negócios do que junções de tabela relacional e integridade referencial. Os desenvolvedores podem implementar técnicas e padrões como Sagas, CQRS e mensagens assíncronas para adotar a consistência eventual.
Hoje em dia, deve-se tomar cuidado ao considerar as restrições do teorema de CAP. Surgiu um novo tipo de banco de dados, chamado NewSQL, que estende o mecanismo de banco de dados relacional para dar suporte à escalabilidade horizontal e ao desempenho escalonável de sistemas NoSQL.
Considerações sobre sistemas relacionais versus NoSQL
Com base em requisitos de dados específicos, um microsserviço com base em nativo de nuvem pode implementar um armazenamento de dados relacional, NoSQL ou ambos.
| Considere um armazenamento de dados NoSQL quando: | Considere um banco de dados relacional quando: |
|---|---|
| Você tem cargas de trabalho de alto volume que exigem uma latência previsível em grande escala (por exemplo, a latência medida em milissegundos ao executar milhões de transações por segundo) | Seu volume de carga de trabalho geralmente se encaixa em milhares de transações por segundo |
| Seus dados são dinâmicos e frequentemente são alterados | Seus dados são altamente estruturados e exigem integridade referencial |
| As relações podem ser modelos de dados desnormalizados | As relações são expressas por meio de junções de tabela em modelos de dados normalizados |
| A recuperação de dados é simples e expressa sem junções de tabela | Você trabalha com consultas e relatórios complexos |
| Os dados normalmente são replicados entre regiões geográficas e exigem um controle mais fino sobre consistência, disponibilidade e desempenho | Os dados normalmente são centralizados ou podem ser replicados de forma assíncrona |
| Seu aplicativo será implantado no hardware de commodities, como com nuvens públicas | Seu aplicativo será implantado em hardware grande e de ponta |
Nas próximas seções, exploraremos as opções disponíveis na nuvem do Azure para armazenar e gerenciar seus dados nativos de nuvem.
Banco de dados como serviço
Para começar, provisione uma máquina virtual do Azure e instale o banco de dados de sua escolha para cada serviço. Embora você tenha controle total sobre o ambiente, você abriria mão de muitos recursos internos da plataforma de nuvem. Você também seria responsável por gerenciar a máquina virtual e o banco de dados para cada serviço. Essa abordagem pode rapidamente se tornar demorada e cara.
Em vez disso, os aplicativos nativos de nuvem favorecem os serviços de dados expostos como um DBaaS (Banco de Dados como Serviço). Totalmente gerenciados por um fornecedor de nuvem, esses serviços fornecem segurança interna, escalabilidade e monitoramento. Em vez de possuir o serviço, basta consumi-lo como um serviço de backup. O provedor opera o recurso em escala e assume a responsabilidade pelo desempenho e manutenção.
Eles podem ser configurados entre zonas e regiões de disponibilidade de nuvem para obter alta disponibilidade. Todos eles dão suporte à capacidade just-in-time e a um modelo pago conforme o uso. O Azure apresenta diferentes tipos de opções de serviço de dados gerenciados, cada uma com benefícios específicos.
Primeiro, examinaremos os serviços DBaaS relacionais disponíveis no Azure. Você verá que o principal banco de dados SQL Server da Microsoft está disponível junto com várias opções de software de código aberto. Em seguida, falaremos sobre os serviços de dados NoSQL no Azure.
Bancos de dados relacionais do Azure
Para os microsserviços nativos de nuvem que exigem dados relacionais, o Azure oferece quatro ofertas de DBaaS (bancos de dados como serviço) relacionais gerenciados, mostradas na Figura 5-11.
Figura 5-11. Bancos de dados relacionais gerenciados disponíveis no Azure
Na figura anterior, observe como cada um se baseia em uma infraestrutura DBaaS comum que apresenta recursos importantes sem custo adicional.
Esses recursos são especialmente importantes para organizações que provisionam um grande número de bancos de dados, mas têm recursos limitados para administrá-los. Provisione um banco de dados do Azure em minutos selecionando a quantidade de núcleos de processamento, memória e armazenamento subjacente. Você pode escalar o banco de dados em tempo real e ajustar dinamicamente os recursos com pouco ou nenhum tempo de inatividade.
Banco de Dados SQL do Azure
As equipes de desenvolvimento com experiência no Microsoft SQL Server devem considerar o Banco de Dados SQL do Azure. É um DBaaS (banco de dados como serviço) relacional totalmente gerenciado com base no Mecanismo de Banco de Dados do Microsoft SQL Server. O serviço compartilha muitos recursos encontrados na versão local do SQL Server e executa a versão estável mais recente do mecanismo de banco de dados SQL Server.
Para uso com um microsserviço nativo de nuvem, o Banco de Dados SQL do Azure está disponível com três opções de implantação:
Um Banco de Dados Individual representa um Banco de Dados SQL totalmente gerenciado em execução em um servidor de Banco de Dados SQL do Azure na nuvem do Azure. O banco de dados é considerado contido, pois não tem dependências de configuração no servidor de banco de dados subjacente.
Um Instância Gerenciada é uma instância totalmente gerenciada do Mecanismo de Banco de Dados da Microsoft SQL Server que fornece quase 100% de compatibilidade com um SQL Server local. Essa opção dá suporte a bancos de dados maiores, até 35 TB e é colocada em uma Rede Virtual do Azure para um melhor isolamento.
O Banco de Dados SQL do Azure sem servidor é uma camada de computação para um banco de dados individual que é dimensionado automaticamente com base na demanda de carga de trabalho. Ele cobra apenas pela quantidade de computação usada por segundo. O serviço é adequado para cargas de trabalho com padrões de uso intermitentes e imprevisíveis, intercalados com períodos de inatividade. A camada de computação sem servidor também pausa bancos de dados automaticamente durante períodos inativos, para que apenas as cobranças por armazenamento sejam cobradas. Ela retoma automaticamente quando a atividade retorna.
Além da pilha tradicional do Microsoft SQL Server, o Azure também apresenta versões gerenciadas de três bancos de dados de software de código aberto populares.
Bancos de dados de software de código aberto no Azure
Bancos de dados relacionais de software de código aberto tornaram-se uma escolha popular para aplicativos nativos de nuvem. Muitas empresas os favorecem em relação a produtos de banco de dados comerciais, especialmente para economia de custos. Muitas equipes de desenvolvimento desfrutam de sua flexibilidade, desenvolvimento com suporte da comunidade e ecossistema de ferramentas e extensões. Os bancos de dados de software de código aberto podem ser implantados em vários provedores de nuvem, ajudando a minimizar a preocupação com o "bloqueio do fornecedor".
Os desenvolvedores podem auto-hospedar facilmente qualquer banco de dados de software de código aberto em uma VM do Azure. Ao fornecer controle total, essa abordagem coloca você no gancho para o gerenciamento, o monitoramento e a manutenção do banco de dados e da VM.
No entanto, a Microsoft continua seu compromisso de manter o Azure uma "plataforma aberta" oferecendo vários bancos de dados de software de código aberto populares como serviços DBaaS totalmente gerenciados.
Banco de Dados do Azure para MySQL
O MySQL é um banco de dados relacional de software de código aberto e um pilar para aplicativos compilados na pilha de software LAMP. Amplamente escolhido para ler cargas de trabalho pesadas, é usado por muitas grandes organizações, incluindo Facebook, Twitter e YouTube. A edição da comunidade está disponível gratuitamente, enquanto a edição corporativa requer uma compra de licença. Criado originalmente em 1995, o produto foi comprado pela Sun Microsystems em 2008. A Oracle adquiriu a Sun e a MySQL em 2010.
O Banco de Dados do Azure para MySQL é um serviço de banco de dados relacional gerenciado com base no mecanismo de banco de dados MySQL de software de código aberto. Ele usa a edição do MySQL Community. O servidor MySQL do Azure é o ponto administrativo para o serviço. É o mesmo mecanismo de servidor MySQL usado para implantações locais. O mecanismo pode criar um banco de dados único por servidor ou vários bancos de dados por servidor que compartilham recursos. Continue a gerenciar dados usando as mesmas ferramentas de software de código aberto sem precisar aprender novas habilidades ou gerenciar máquinas virtuais.
Banco de Dados do Azure para MariaDB
O MariaDB Server é outro servidor de banco de dados de software de código aberto popular. Foi criado como uma bifurcação do MySQL quando a Oracle comprou a Sun Microsystems, proprietária do MySQL. A intenção era garantir que o MariaDB permanecesse um software de código aberto. Como MariaDB é uma bifurcação do MySQL, as definições de dados e tabelas são compatíveis e os protocolos de cliente, estruturas e APIs são próximos.
O MariaDB tem uma comunidade forte e é usado por várias empresas de grande porte. Enquanto a Oracle continua a manter, aprimorar e dar suporte ao MySQL, a fundação MariaDB gerencia o MariaDB, permitindo contribuições públicas para o produto e a documentação.
Banco de Dados do Azure para MariaDB é um banco de dados relacional totalmente gerenciado como um serviço na nuvem do Azure. O serviço se baseia no mecanismo de servidor de edição da comunidade MariaDB. Ele pode lidar com cargas de trabalho críticas com desempenho previsível e escalabilidade dinâmica.
Banco de Dados do Azure para PostgreSQL
O PostgreSQL é um banco de dados relacional de software de código aberto com mais de 30 anos de desenvolvimento ativo. O PostgreSQL tem uma forte reputação de confiabilidade e integridade de dados. Ele é avançado em recursos, em conformidade com SQL e considerado com melhor desempenho do que o MySQL. Especialmente para cargas de trabalho com consultas complexas e gravações pesadas. Várias empresas de grande porte, incluindo Apple, Red Hat e Fujitsu, criaram produtos usando o PostgreSQL.
O Banco de Dados do Azure para PostgreSQL é um serviço de banco de dados relacional totalmente gerenciado, com base no mecanismo de banco de dados Postgres de software de código aberto. O serviço dá suporte a muitas plataformas de desenvolvimento, incluindo C++, Java, Python, Node, C# e PHP. Migre bancos de dados PostgreSQL para ele usando a ferramenta de interface de linha de comando ou o Serviço de Migração de Dados do Azure.
O Banco de Dados do Azure para PostgreSQL está disponível com duas opções de implantação:
A opção de implantação do Servidor Único é um ponto administrativo central para vários bancos de dados nos quais você pode implantar muitos bancos de dados. O preço é estruturado por servidor com base em núcleos e armazenamento.
A opção Hiperescala (Citus) é alimentada pela tecnologia Citus Data. Ele permite alto desempenho dimensionando horizontalmente um único banco de dados em centenas de nós para fornecer desempenho e escala rápidos. Essa opção permite que o mecanismo ajuste mais dados na memória, paralelize consultas em centenas de nós e indexe dados mais rapidamente.
Dados NoSQL no Azure
O Cosmos DB é um serviço de banco de dados NoSQL totalmente gerenciado e distribuído globalmente na nuvem do Azure. Foi adotado por várias empresas de grandes porte ao redor do mundo, incluindo Coca-Cola, Skype, ExxonMobil e Liberty Mutual.
Se seus serviços exigirem resposta rápida de qualquer lugar do mundo, alta disponibilidade ou escalabilidade elástica, o Cosmos DB será uma ótima opção. A Figura 5-12 mostra o Cosmos DB.
Figura 5-12: Visão geral do Azure Cosmos DB
A figura anterior apresenta muitos dos recursos nativos de nuvem internos disponíveis no Cosmos DB. Nesta seção, vamos examiná-las mais detalhadamente.
Suporte global
Os aplicativos nativos de nuvem geralmente têm um público global e exigem escala global.
Distribuía bancos de dados do Cosmos entre regiões ou ao redor do mundo, colocando dados próximos aos usuários, melhorando o tempo de resposta e reduzindo a latência. É possível adicionar ou remover um banco de dados de uma região sem pausar ou reimplantar seus serviços. Em segundo plano, o Cosmos DB replica de forma transparente os dados para cada uma das regiões configuradas.
O Cosmos DB dá suporte ao cluster ativo/ativo no nível global, permitindo que você configure qualquer uma de suas regiões de banco de dados para dar suporte a gravações e leituras.
O protocolo de gravação de várias regiões é um recurso importante no Cosmos DB que habilita a seguinte funcionalidade:
Escalabilidade de leitura e gravação elástica ilimitada.
99,999% de leitura e gravação de disponibilidade em todo o mundo.
Garantia de leituras e gravações atendidas em menos de 10 milissegundos no percentil 99.
Com as APIs multi-Homing do Cosmos DB, seu microsserviço está automaticamente ciente da região mais próxima do Azure e envia solicitações para ela. A região mais próxima é identificada pelo Cosmos DB sem alterações de configuração. Se uma região ficar indisponível, o recurso Multi-Homing roteará automaticamente as solicitações para a próxima região disponível mais próxima.
Suporte a vários modelos
Ao realocar plataformas de aplicativos monolíticos para uma arquitetura nativa de nuvem, as equipes de desenvolvimento às vezes precisam migrar armazenamentos de dados NoSQL de software de código aberto. O Cosmos DB pode ajudá-lo a preservar seu investimento nesses armazenamentos de dados NoSQL com sua plataforma de dados de vários modelos. A tabela a seguir mostra as APIs de compatibilidade do NoSQL com suporte.
| Provedor | Descrição |
|---|---|
| API NoSQL | A API para NoSQL armazena dados no formato de documento |
| API do BD do Mongo | Dá suporte a APIs do Mongo DB e documentos JSON |
| API do Gremlin | Dá suporte à API do Gremlin com nós baseados em grafo e representações de dados de borda |
| API Cassandra | Dá suporte à API Casandra para representações de dados de coluna larga |
| API de Tabela | Dá suporte ao Armazenamento de Tabelas do Azure com aprimoramentos Premium |
| API para PostgreSQL | Serviço gerenciado para executar o PostgreSQL em qualquer escala |
As equipes de desenvolvimento podem migrar os bancos de dados do Mongo, Gremlin, ou Cassandra existentes para o Cosmos DB com alterações mínimas em dados ou código. Para novos aplicativos, as equipes de desenvolvimento podem escolher entre as opções de software de código aberto ou o modelo de API do SQL interno.
Internamente, o Cosmos armazena os dados em um formato struct simples composto por tipos de dados primitivos. Para cada solicitação, o mecanismo de banco de dados converte os dados primitivos na representação de modelo selecionada.
Na tabela anterior, observe a opção API de Tabela. Essa API é uma evolução do Armazenamento de Tabelas do Azure. Ambos compartilham o mesmo modelo de tabela subjacente, mas a API de Tabela do Cosmos DB adiciona aprimoramentos Premium não disponíveis na API de Armazenamento do Microsoft Azure. A tabela a seguir contrasta os recursos.
| Recurso | Armazenamento de Tabelas do Azure | Azure Cosmos DB |
|---|---|---|
| Latency | Rápido | Latência de milissegundo de dígito único para leituras e gravações em qualquer lugar do mundo |
| Produtividade | Limite de 20 mil operações por tabela | Operações ilimitadas por tabela |
| Distribuição Global | Região única com uma única região de leitura secundária opcional | Distribuições turnkey para todas as regiões com failover automático |
| Indexação | Disponível apenas para propriedades de chave de linha e partição | Indexação automática de todas as propriedades |
| Preços | Otimizado para cargas de trabalho frias (baixa taxa de transferência: taxa de armazenamento) | Otimizado para cargas de trabalho quentes (alta taxa de transferência: taxa de armazenamento) |
Os microsserviços que consomem o Armazenamento de Tabelas do Azure podem migrar facilmente para a API de Tabela Cosmos DB. Nenhuma alteração de código é necessária.
Consistência ajustável
Anteriormente, na seção Relational versus NoSQL, abordaremos o assunto da consistência de dados. A consistência de dados refere-se à integridade de seus dados. Os serviços nativos de nuvem com dados distribuídos dependem da replicação e devem fazer uma compensação fundamental entre consistência de leitura, disponibilidade e latência.
A maioria dos bancos de dados distribuídos permite que os desenvolvedores escolham entre dois modelos de consistência: forte e eventual. A consistência forte é o padrão ouro de programação de dados. Ele garante que uma consulta sempre retornará os dados mais atuais, mesmo que o sistema precise incorrer em latência aguardando uma atualização para ser replicada em todas as cópias do banco de dados. Já um banco de dados configurado para consistência eventual retornará dados imediatamente, mesmo que esses dados não sejam a cópia mais atual. A última opção permite maiores disponibilidade, escala e desempenho.
O Azure Cosmos DB oferece cinco modelos de consistência bem definidos mostrados na Figura 5-13.
Figura 5-13: níveis de consistência do Cosmos DB
Essas opções permitem que você faça escolhas precisas e compensações granulares para consistência, disponibilidade e desempenho para seus dados. Os níveis são apresentados na tabela a seguir.
| Nível de coerência | Descrição |
|---|---|
| Eventual | Não há garantia de classificação para leituras. As réplicas eventualmente convergirão. |
| Prefixo constante | As leituras ainda são eventuais, mas os dados são retornados na ordenação na qual elas são gravadas. |
| Session | Garante que você pode ler todos os dados gravados durante a sessão atual. É o nível de consistência padrão. |
| Desatualização limitada | Lê gravações de trilha por intervalo que você especificar. |
| Forte | É garantido que as leituras retornem a versão autorizada mais recente de um item. Um cliente nunca vê uma leitura não autorizada ou parcial. |
No artigo Getting Behind the 9-Ball: Cosmos DB Consistency Levels Explained, o Gerente de Programas Jeremy Likness da Microsoft fornece uma excelente explicação dos cinco modelos.
Particionamento
o Azure Cosmos DB adota o particionamento automático para escalar um banco de dados para atender às necessidades de desempenho de seus serviços nativos de nuvem.
Você gerencia dados em dados do Cosmos DB criando bancos de dados, contêineres e itens.
Os contêineres residem em um banco de dados do Cosmos DB e representam um agrupamento de itens de esquema agnóstico. Os itens são os dados que você adiciona ao contêiner. Eles são representados como documentos, linhas, nós ou bordas. Todos os itens adicionados a um contêiner são indexados automaticamente.
Para particionar o contêiner, os itens são divididos em subconjuntos distintos chamados partições lógicas. As partições lógicas são preenchidas com base no valor de uma chave de partição associada a cada item em um contêiner. A Figura 5-14 mostra dois contêineres cada um com uma partição lógica com base em um valor de chave de partição.
Figura 5-14: Mecânica de particionamento do Cosmos DB
Observe na figura anterior como cada item inclui uma chave de partição de 'cidade' ou 'aeroporto'. A chave determina a partição lógica do item. Itens com um código da cidade são atribuídos ao contêiner à esquerda e itens com um código de aeroporto, para o contêiner à direita. A combinação do valor da chave de partição com o valor da ID cria um índice de item, que identifica exclusivamente o item.
Internamente, o Cosmos DB gerencia de forma automática o posicionamento de partições lógicas em partições físicas para atender às necessidades de escalabilidade e desempenho do contêiner. À medida que os requisitos de armazenamento e de taxa de transferência do aplicativo aumentam, o Azure Cosmos DB redistribui partições lógicas em um número maior de servidores. As operações de redistribuição são gerenciadas pelo Cosmos DB e invocadas sem interrupção ou tempo de inatividade.
Bancos de dados NewSQL
O NewSQL é uma tecnologia de banco de dados emergente que combina a escalabilidade distribuída do NoSQL com as garantias ACID de um banco de dados relacional. Os bancos de dados NewSQL são importantes para sistemas de negócios que devem processar grandes volumes de dados, em ambientes distribuídos, com suporte transacional completo e conformidade ACID. Embora um banco de dados NoSQL possa fornecer escalabilidade maciça, ele não garante a consistência dos dados. Problemas intermitentes de dados inconsistentes podem colocar um fardo sobre a equipe de desenvolvimento. Os desenvolvedores devem construir proteções em seu código de microsserviço para gerenciar problemas causados por dados inconsistentes.
O CNCF (Cloud Native Computing Foundation) apresenta vários projetos de banco de dados NewSQL.
| Project | Características |
|---|---|
| BD de barata | Um banco de dados relacional em conformidade com ACID que escala globalmente. Adicione um novo nó a um cluster e o CockroachDB cuida do balanceamento dos dados entre instâncias e geografias. Ele cria, gerencia e distribui réplicas para garantir a confiabilidade. É um código aberto e disponível gratuitamente. |
| TiDB | Um banco de dados de software de código aberto que dá suporte a cargas de trabalho HTAP (Processamento Transacional e Analítico Híbrido). Ele é compatível com MySQL e apresenta escalabilidade horizontal, consistência forte e alta disponibilidade. O TiDB atua como um servidor MySQL. Continue a usar bibliotecas de cliente MySQL existentes, sem exigir alterações de código abrangentes em seu aplicativo. |
| YugabyteDB | Um banco de dados SQL distribuído de código aberto e alto desempenho. Ele dá suporte à baixa latência de consulta, à resiliência contra falhas e à distribuição de dados global. O YugabyteDB é compatível com PostgreSQL e lida com o RDBMS em expansão e cargas de trabalho OLTP em escala de internet. O produto também dá suporte ao NoSQL e é compatível com o Cassandra. |
| Vitess | O Vitess é uma solução de banco de dados para implantar, dimensionar e gerenciar clusters grandes de instâncias do MySQL. Ele pode ser executado em uma arquitetura de nuvem pública ou privada. O Vitess combina e estende muitos recursos importantes do MySQL e apresenta suporte a fragmentação vertical e horizontal. Originado pelo YouTube, o Vitess atende todo o tráfego de banco de dados do YouTube desde 2011. |
Os projetos de software de código aberto na figura anterior estão disponíveis na Cloud Native Computing Foundation. Três das ofertas são produtos de banco de dados completos, que incluem suporte ao .NET. O outro, Vitess, é um sistema de cluster de banco de dados que escala horizontalmente grandes clusters de instâncias MySQL.
Uma das principais metas de design para bancos de dados NewSQL é trabalhar nativamente no Kubernetes, aproveitando a resiliência e a escalabilidade da plataforma.
Os bancos de dados NewSQL foram projetados para prosperar em ambientes de nuvem efêmeras em que máquinas virtuais subjacentes podem ser reiniciadas ou reagendadas a qualquer momento. Os bancos de dados foram projetados para sobreviver a falhas de nó sem perda de dados nem tempo de inatividade. O CockroachDB, por exemplo, é capaz de sobreviver a uma perda de computador mantendo três réplicas consistentes de qualquer dado entre os nós em um cluster.
O Kubernetes usa um constructo de Serviços para permitir que um cliente resolva um grupo de processos de bancos de dados NewSQL idênticos de uma única entrada DNS. Ao desacoplar as instâncias de banco de dados do endereço do serviço com o qual ele está associado, podemos escalar sem interromper as instâncias de aplicativo existentes. Enviar uma solicitação para qualquer serviço em um determinado momento sempre produzirá o mesmo resultado.
Nesse cenário, todas as instâncias de banco de dados são iguais. Não há relações primárias ou secundárias. Técnicas como a replicação de consenso encontrada em CockroachDB permitem que qualquer nó de banco de dados lide com qualquer solicitação. Se o nó que recebe uma solicitação com balanceamento de carga tiver os dados necessários localmente, ele responderá imediatamente. Caso contrário, o nó se torna um gateway e encaminha a solicitação para os nós apropriados para obter a resposta correta. Do ponto de vista do cliente, cada nó de banco de dados é o mesmo: ele aparece como um banco de dados lógico único com as garantias de consistência de um sistema de computador único, apesar de ter dezenas ou até centenas de nós que estão funcionando nos bastidores.
Para obter uma visão detalhada da mecânica por trás dos bancos de dados NewSQL, consulte o artigo DASH: Four Properties of Kubernetes-Native Databases.
Migração de dados para a nuvem
Uma das tarefas mais demoradas é migrar dados de uma plataforma de dados para outra. O Serviço de Migração de Dados do Azure pode ajudar a agilizar esses esforços. Ele pode migrar dados de várias fontes de banco de dados externas para plataformas de Dados do Azure com tempo de inatividade mínimo. As plataformas de destino incluem os seguintes serviços:
- Banco de Dados SQL do Azure
- Banco de Dados do Azure para MySQL
- Banco de Dados do Azure para MariaDB
- Banco de Dados do Azure para PostgreSQL
- Azure Cosmos DB
O serviço fornece recomendações para guiá-lo pelas alterações necessárias para executar uma migração, pequena ou grande.
