Este documento é destinado a desenvolvedores de software e administradores de banco de dados que querem migrar aplicativos atuais ou projetar novos aplicativos para uso com o Bigtable como um banco de dados. Este documento aplica seu conhecimento do Apache Cassandra ao uso do Bigtable para descrever conceitos que você precisa entender antes de migrar. Para informações sobre ferramentas de código aberto que podem ser usadas para concluir a migração, consulte Como migrar do Cassandra para o Bigtable.
O Bigtable e o Cassandra são bancos de dados distribuídos. Eles implementam armazenamentos de chave-valor multidimensionais que podem aceitar dezenas de milhares de consultas por segundo (QPS), leituras e gravações de baixa latência, armazenamento que pode ser escalonado verticalmente para petabytes de dados e tolerância a falhas de nós.
Quando o Bigtable é um bom destino para cargas de trabalho do Cassandra
O melhor Google Cloud serviço para sua carga de trabalho do Cassandra depende das suas metas de migração e da funcionalidade do Cassandra que você precisa após a migração.
Se uma ou mais das seguintes condições se aplicarem, o Bigtable será a melhor opção:
- Você quer um serviço totalmente gerenciado sem janelas de manutenção e com alta disponibilidade.
- Você precisa de um escalonamento elástico que responda automaticamente a mudanças no tráfego do servidor.
- Você precisa de uma latência consistente de um dígito em milissegundos para leituras e gravações.
- Você usa tipos de coleta, contadores ou visualizações materializadas do Cassandra, além de tipos escalares, para os quais o Bigtable é otimizado.
- Você tem um aplicativo que usa o parâmetro
USING TIMESTAMP. - A capacidade de processamento e a latência de gravação são tão importantes quanto as leituras.
- Você depende de um dos modelos de replicação com consistência posterior do Cassandra.
- Seu caso de uso exige um armazenamento econômico.
Para migrar aplicativos sem alterações de código, você pode optar por autogerenciar o Cassandra no GKE ou usar um parceiro do Google Cloud, como o DataStax ou o ScyllaDB. Se o aplicativo for pesado em leitura e você quiser refatorar o código para obter recursos de banco de dados relacional e consistência forte, considere o Spanner.
Este documento oferece dicas sobre o que considerar ao refatorar seu aplicativo, caso você escolha o Bigtable como destino de migração para suas cargas de trabalho do Cassandra.
Como usar este documento
Você não precisa ler este documento do início ao fim. Neste documento, apresentamos uma comparação dos dois bancos de dados, mas também é possível se concentrar nos tópicos que se aplicam ao seu caso de uso ou aos interesses.
Para ajudar você a comparar o Bigtable e o Cassandra, este documento faz o seguinte:
- Compara a terminologia, que pode diferir entre os dois bancos de dados.
- Oferece uma visão geral dos dois sistemas de banco de dados.
- Observe como cada banco de dados lida com a modelagem de dados para entender diferentes considerações de design.
- Compara o caminho percorrido pelos dados durante as gravações e leituras.
- Examina o layout físico dos dados para entender aspectos da arquitetura do banco de dados.
- Descreve como configurar a replicação geográfica para atender aos seus requisitos e como dimensionar o cluster.
- Analisa detalhes sobre gerenciamento de cluster, monitoramento e segurança.
Comparação de terminologia
Ainda que muitos dos conceitos usados no Bigtable e no Cassandra sejam semelhantes, cada banco de dados tem convenções de nomenclatura um pouco diferentes e diferenças sutis.
Um dos componentes principais de ambos os bancos de dados é a tabela de strings classificadas (SSTable). Nas duas arquiteturas, os SSTables são criados para manter os dados usados para responder às consultas de leitura.
Em uma postagem de blog (2012), Ilya Grigorik escreve o seguinte: "Uma SSTable é uma abstração simples para armazenar com eficiência grandes números de pares de chave-valor e, ao mesmo tempo, otimizar para cargas de trabalho de leitura ou gravação sequenciais de alta capacidade de processamento".
A tabela a seguir descreve os conceitos compartilhados e a terminologia correspondente que cada produto usa:
| Cassandra | Bigtable |
|---|---|
|
chave primária: um valor exclusivo ou de vários campos que determina a colocação e a ordem dos dados. chave de partição: um valor de um ou vários campos que determina a colocação de dados por hash consistente. coluna de clustering: um valor único ou de vários campos que determina a classificação de dados lexicográficas em uma partição. |
chave de linha: uma string de bytes única e única que determina o posicionamento dos dados por uma classificação lexicográfica. As chaves compostas são imitadas pela junção dos dados de várias colunas usando um delimitador comum, por exemplo, o símbolo de hash (#) ou porcentagem (%). |
| nó: uma máquina responsável por ler e gravar dados associados a uma série de intervalos de hash de partição de chave primária. No Cassandra, os dados são armazenados no armazenamento no nível de bloco anexado ao servidor do nó. | node: um recurso de computação virtual responsável por ler e gravar dados associados a uma série de intervalos de chaves de linha. No Bigtable, os dados não estão colocalizados com os nós de computação. Em vez disso, ele é armazenado no Colossus, o sistema de arquivos distribuídos do Google. Os nós têm responsabilidade temporária de exibir vários intervalos de dados com base na carga da operação e na integridade de outros nós no cluster. |
|
data center: semelhante a um cluster do Bigtable, exceto alguns aspectos de estratégia de topologia e replicação são configuráveis no Cassandra. rack: um agrupamento de nós em um data center que influencia a colocação de réplica. |
cluster: um grupo de nós na mesma zona geográfica doGoogle Cloud , colocados juntos para fins de latência e replicação. |
| cluster: uma implantação do Cassandra que consiste em uma coleção de data centers. | instância: um grupo de clusters do Bigtable em diferentes zonas ou regiões do Google Cloud em que ocorrem a replicação e o roteamento de conexão. |
| vnode: um intervalo fixo de valores de hash atribuídos a um nó físico específico. Os dados em um vnode são fisicamente armazenados no nó do Cassandra em uma série de SSTables. | tablet: uma SSTable contendo todos os dados de um intervalo contíguo de chaves de linha classificadas lexicograficamente. Os blocos não são armazenados em nós no Bigtable, mas são armazenados em uma série de SSTables no Colossus. |
| fator de replicação: o número de réplicas de um vnode que são mantidas em todos os nós do data center. O fator de replicação é configurado independentemente para cada data center. | replicação: processo de replicação dos dados armazenados no Bigtable em todos os clusters na instância. A replicação dentro de um cluster zonal é processada pela camada de armazenamento Colossus. |
| tabela (anteriormente grupo de colunas): uma organização lógica de valores indexados pela chave primária única. | tabela: uma organização lógica de valores indexados pela chave de linha exclusiva. |
| keyspace: um namespace de tabela lógico que define o fator de replicação para as tabelas que ele contém. | Não relevante. O Bigtable trata as preocupações do espaço de maneira transparente. |
| map: um tipo de coleção do Cassandra que contém pares de chave-valor. | grupo de colunas: um namespace especificado pelo usuário que agrupa qualificadores de coluna para leituras e gravações mais eficientes. Ao consultar o Bigtable usando SQL, grupos de colunas são tratados como os mapas do Cassandra. |
| chave do mapa: chave que identifica exclusivamente uma entrada de chave-valor em um mapa do Cassandra. | qualificador de coluna: um rótulo para um valor armazenado em uma tabela indexada pela chave de linha exclusiva. Ao consultar o Bigtable usando SQL, as colunas são tratadas como chaves de um mapa. |
| column: o rótulo de um valor armazenado em uma tabela indexada pela chave primária única. | column: o rótulo de um valor armazenado em uma tabela indexada pela chave de linha exclusiva. O nome da coluna é construído combinando o grupo de colunas com o qualificador de coluna. |
| célula: um valor de carimbo de data/hora em uma tabela associada à interseção de uma chave primária com a coluna. | célula: um valor de carimbo de data/hora em uma tabela associada à interseção de uma chave de linha com o nome da coluna. Várias versões com carimbo de data/hora podem ser armazenadas e recuperadas para cada célula. |
| counter: um tipo de campo incrementável otimizado para operações de soma de números inteiros. | Contadores: células que usam tipos de dados especializados para operações de soma de números inteiros. Para mais informações, consulte Criar e atualizar contadores. |
| Política de balanceamento de carga: uma política que você configura na lógica do aplicativo para rotear operações para um nó apropriado no cluster. A política considera a topologia do data center e os intervalos de tokens de nó. | perfil de aplicativo: configurações que informam ao Bigtable como encaminhar uma chamada da API do cliente para o cluster apropriado na instância. Também é possível usar o perfil do aplicativo como tag para segmentar métricas. Configure o perfil do aplicativo no serviço. |
| CQL: a linguagem de consulta do Cassandra, uma linguagem como SQL usada para criação de tabelas, alterações de esquema, mutações de linhas e consultas. | O cliente do Cassandra para Bigtable em Java é uma substituição perfeita para seus drivers do Cassandra. O cliente Java entende suas consultas CQL e permite que você use o Bigtable de forma transparente com seu aplicativo baseado em Cassandra sem reescrever o código. O adaptador de proxy do Cassandra para o Bigtable é uma camada independente que pode ser executada em paralelo ao aplicativo e conectada ao Bigtable como outro nó do Cassandra. O adaptador de proxy oferece compatibilidade com CQL e aceita gravações duplas e migrações em massa. Essa funcionalidade é semelhante ao que o cliente do Cassandra para Bigtable em Java oferece. As APIs do Bigtable são as bibliotecas de cliente e as APIs gRPC usadas para criar instâncias, clusters, tabelas e grupos de colunas, além de modificar linhas e executar consultas. A API SQL do Bigtable é familiar para usuários do CQL. |
Visualização materializada: uma instrução SELECT que define um conjunto de linhas correspondentes a linhas em uma tabela de origem subjacente. Quando a tabela de origem
muda, o Cassandra atualiza a visualização materializada automaticamente.
|
Visualização materializada contínua: um resultado totalmente gerenciado e pré-computado de uma consulta SQL que é atualizada de forma incremental e automática de uma tabela de origem. Para mais informações, consulte Visualizações materializadas contínuas. |
Visão geral do produto
Nas seções a seguir, fornecemos uma visão geral da filosofia de design e dos principais atributos do Bigtable e do Cassandra.
Bigtable
O Bigtable oferece muitos dos recursos principais descritos no artigo Bigtable: um sistema de armazenamento distribuído para dados estruturados. O Bigtable separa os nós de computação, que atendem as solicitações dos clientes do gerenciamento de armazenamento subjacente. Os dados são armazenados no Colossus. A camada de armazenamento replica automaticamente os dados para fornecer uma durabilidade que excede os níveis fornecidos pela replicação tripla padrão do Hadoop Distributed File System (HDFS).
Essa arquitetura fornece leituras e gravações consistentes em um cluster, faz o escalonamento horizontal sem qualquer custo de redistribuição de armazenamento e pode reequilibrar as cargas de trabalho sem modificar o cluster ou o esquema. Se qualquer nó de processamento de dados for comprometido, o serviço do Bigtable o substituirá de forma transparente. O Bigtable também oferece suporte à replicação assíncrona.
Além do gRPC e das bibliotecas de cliente para várias linguagens de programação, o Bigtable mantém compatibilidade com a biblioteca de cliente Java do Apache HBase de código aberto, uma implementação alternativa de mecanismo de banco de dados de código aberto do artigo do Bigtable.
O diagrama a seguir mostra como o Bigtable separa fisicamente os nós de processamento da camada de armazenamento:
No diagrama anterior, o nó de processamento do meio é responsável apenas por veicular solicitações de dados para o conjunto de dados C na camada de armazenamento. Se o Bigtable identificar que o rebalanceamento de atribuição de intervalos é necessário para um conjunto de dados, os intervalos de dados de um nó de processamento serão fáceis de alterar porque a camada de armazenamento é separada da camada de processamento.
O diagrama a seguir mostra, em termos simplificados, um reequilíbrio do intervalo de chaves e um redimensionamento de cluster:
A imagem Reequilíbrio ilustra o estado do cluster do Bigtable depois que o nó de processamento mais à esquerda recebe um número maior de solicitações para o conjunto de dados A. Depois que o rebalanceamento ocorre, o nó do meio, em vez do nó mais à esquerda, é responsável por atender às solicitações de dados do conjunto B. O nó mais à esquerda continua a atender às solicitações do conjunto de dados A.
O Bigtable pode reorganizar os intervalos de chaves de linha para equilibrar intervalos de conjunto de dados em um número maior de nós de processamento disponíveis. A imagem Redimensionamento mostra o estado do cluster do Bigtable depois que você adiciona um nó.
Cassandra
O Apache Cassandra é um banco de dados de código aberto que é parcialmente influenciado por conceitos do documento do Cloud Bigtable. Ele usa uma arquitetura de nós distribuída, em que o armazenamento é colocalizado com os servidores que respondem a operações de dados. Uma série de nós virtuais (vnodes) é atribuída aleatoriamente a cada servidor para veicular uma parte do keyspace do cluster.
Os dados são armazenados nos vnodes com base na chave de partição. Normalmente, uma função hash consistente é usada para gerar um token que determina o posicionamento dos dados. Assim como no Bigtable, você pode usar um particionador que preserva a ordem para geração de tokens e, portanto, também para posicionamento de dados. No entanto, a documentação do Cassandra não recomenda essa abordagem porque o cluster provavelmente ficará desequilibrado, uma condição difícil de corrigir. Por isso, este documento pressupõe que você usa uma estratégia de hash consistente para gerar tokens que resultam na distribuição de dados entre os nós.
O Cassandra oferece tolerância a falhas por meio de níveis de disponibilidade relacionados ao nível de consistência imperativa, permitindo que um cluster atenda a clientes enquanto um ou mais nós são prejudicados. Você define a replicação geográfica com uma estratégia de topologia de replicação de dados configurável.
Você especifica um nível de consistência para cada operação. A configuração típica é QUORUM (ou LOCAL_QUORUM em determinadas topologias de data center múltiplos). Essa configuração de nível de consistência exige que a maioria do nó de réplica responda ao nó do coordenador para que a operação seja considerada bem-sucedida. O fator de replicação, que você configura para cada keyspace, determina o número de réplicas de dados que são armazenadas em cada data center no cluster. Por exemplo, é normal usar um valor de fator de replicação de 3 para fornecer um equilíbrio prático entre a durabilidade e o volume de armazenamento.
O diagrama a seguir mostra, de forma simplificada, um cluster de seis nós com o intervalo de chaves de cada nó dividido em cinco vnodes. Na prática, você pode ter mais nós e provavelmente terá mais vnodes.
No diagrama anterior, é possível ver o caminho de uma operação de gravação, com um nível de consistência de QUORUM, que se origina de um aplicativo cliente ou serviço (Cliente). Para os fins deste diagrama, os intervalos de chaves são mostrados como intervalos alfabéticos. Na realidade, os tokens produzidos por um hash da chave primária são números inteiros assinados muito grandes.
Neste exemplo, o hash da chave é M e os vnodes para M estão nos nós 2, 4 e 6. O coordenador precisa entrar em contato com cada nó em que os intervalos de hash de chave são armazenados localmente para que a gravação possa ser processada. Como o nível de consistência é QUORUM, duas réplicas (a maioria) precisam responder ao nó do coordenador antes que o cliente seja notificado de que a gravação foi concluída.
Ao contrário do Bigtable, mover ou alterar intervalos de chaves no Cassandra requer que você copie fisicamente os dados de um nó para outro. Se um nó estiver sobrecarregado com solicitações para um determinado intervalo de hash de token, adicionar o processamento para esse intervalo de token é mais complexo no Cassandra em comparação com o Bigtable.
Replicação e consistência geográfica
O Bigtable e o Cassandra tratam a replicação geográfica (também conhecida como multirregião) e a consistência. Um cluster do Cassandra consiste no processamento de nós em racks, e os racks são agrupados em data centers. O Cassandra usa uma estratégia de topologia de rede que você configura para determinar como as réplicas do vnode são distribuídas entre os hosts em um data center. Essa estratégia revela as raízes do Cassandra como um banco de dados implantado originalmente em data centers locais. Essa configuração também especifica o fator de replicação para cada data center no cluster.
O Cassandra usa configurações de data center e rack para melhorar a tolerância a falhas das réplicas de dados. Durante as operações de leitura e gravação, a topologia determina os nós de participante necessários para fornecer garantias de consistência. É necessário configurar manualmente nós, racks e data centers ao criar ou estender um cluster. Em um ambiente de nuvem, uma implantação típica do Cassandra trata uma zona de nuvem como um rack e uma região de nuvem como um data center.
Use os controles de quórum do Cassandra para ajustar as garantias de consistência de cada operação de leitura ou gravação. Os níveis de consistência posterior podem variar, incluindo opções que exigem um único nó de réplica (ONE), uma maioria de nós de réplica de data center único (LOCAL_QUORUM) ou uma maioria de todos os nós de réplica em todos os data centers (QUORUM).
No Bigtable, os clusters são recursos zonais. Uma instância do Bigtable pode conter um único cluster ou ser um grupo de clusters totalmente replicados. É possível colocar clusters de instâncias em qualquer combinação de zonas em todas as regiões oferecidas pelo Google Cloud . É possível adicionar e remover clusters de uma instância com impacto mínimo em outros clusters na instância.
No Bigtable, as gravações são realizadas (com consistência na leitura das gravações) em um único cluster e terão consistência posterior nos outros clusters da instância. Como as células individuais são versionadas por carimbo de data/hora, nenhuma gravação é perdida, e cada cluster atende às células que têm os carimbos de data/hora mais atuais disponíveis.
O serviço expõe o status de consistência do cluster. A API Cloud Bigtable fornece um mecanismo para receber um token de consistência no nível da tabela. É possível usar esse token para verificar se todas as alterações feitas nessa tabela antes da criação do token foram replicadas completamente.
Compatibilidade com transações
Embora nenhum dos bancos de dados ofereça suporte a transações complexas de várias linhas, cada um tem algum suporte a transações.
O Cassandra tem um método de transação leve (LWT, na sigla em inglês) que oferece atomicidade para atualizações de valores de coluna em uma única partição. O Cassandra também tem semântica de comparação e definição que conclui a operação de leitura de linha e a comparação de valores antes de iniciar uma gravação.
O Bigtable é compatível com gravações de linha única e consistentes em um cluster. As transações de linha única são ativadas pelas operações de leitura-modificação-gravação e verificação-e-mutação. Os perfis de aplicativos de roteamento de vários clusters não são compatíveis com transações de linha única.
Modelo de dados
O Bigtable e o Cassandra organizam dados em tabelas compatíveis com pesquisas e verificações de intervalo usando o identificador exclusivo da linha. Os dois sistemas são classificados como armazenamentos NoSQL de família de colunas.
No Cassandra, é necessário usar o CQL para criar o esquema completo da tabela com antecedência, incluindo a definição da chave primária, com os nomes e os tipos das colunas. As chaves primárias no Cassandra são valores compostos exclusivos, consistindo em uma chave de partição obrigatória e uma chave de cluster opcional. A chave de partição determina a colocação de nó de uma linha, e a chave de cluster determina a ordem de classificação dentro de uma partição. Ao criar esquemas, é preciso estar ciente das possíveis compensações entre executar verificações eficientes em uma única partição e os custos do sistema associados à manutenção de grandes partições.
No Bigtable, basta criar a tabela e definir os grupos de colunas dela com antecedência. As colunas não são declaradas quando as tabelas são criadas, mas são criadas quando as chamadas de API do aplicativo adicionam células às linhas da tabela.
As chaves de linha são ordenadas lexicograficamente em todo o cluster do Bigtable. Os nós no Bigtable equilibram automaticamente a responsabilidade nodal pelos intervalos de chaves, geralmente chamados de tablets e às vezes de divisões. As chaves de linha do Bigtable geralmente consistem em vários valores de campo que são combinados usando um caractere separador comum escolhido por você (como um sinal de porcentagem). Quando separados, os componentes de string individuais são semelhantes aos campos de uma chave primária do Cassandra.
Design de chave de linha
No Bigtable, o identificador exclusivo de uma linha de tabela é a chave de linha. A chave de linha precisa ser um valor único em uma tabela inteira. É possível criar chaves de várias partes concatenando elementos diferentes separados por um delimitador comum. A chave de linha determina a ordem de classificação global dos dados em uma tabela. O serviço do Bigtable determina dinamicamente os intervalos de chaves atribuídos a cada nó.
Ao contrário do Cassandra, em que o hash da chave de partição determina a colocação de linha e as colunas de clustering determinam a ordem, a chave de linha do Bigtable fornece a atribuição e a ordem de noir. Assim como no Cassandra, você precisa projetar uma chave de linha no Bigtable para que as linhas que você quer recuperar juntas sejam armazenadas juntas. No entanto, no Bigtable, não é necessário criar a chave de linha para posicionamento e ordenação antes de usar uma tabela.
Tipos de dados
O serviço do Bigtable não aplica tipos de dados da coluna que o cliente envia. As bibliotecas de cliente fornecem métodos auxiliares para gravar valores de células como bytes, strings codificadas em UTF-8 e inteiros de 64 bits codificados big-endian. Os inteiros codificados big-endian são necessários para operações de incremento atômico.
Grupo de colunas
No Bigtable, um grupo de colunas determina quais colunas em uma tabela são armazenadas e recuperadas em conjunto. Cada tabela precisa de pelo menos um grupo de colunas, embora as tabelas frequentemente tenham mais (o limite é de 100 grupos de colunas para cada tabela). É preciso criar explicitamente os grupos de colunas antes que um aplicativo possa usá-los em uma operação.
Qualificadores de coluna
Cada valor armazenado em uma tabela em uma chave de linha está associado a um rótulo chamado qualificador de coluna. Como os qualificadores de coluna são apenas rótulos, não há limite prático para o número de colunas que você pode ter em um grupo. Os qualificadores de coluna são frequentemente usados no Bigtable para representar dados do aplicativo.
Célula
No Bigtable, uma célula é a interseção da chave de linha e do nome da coluna (um grupo de colunas combinado com um qualificador de coluna). Cada célula contém um ou mais valores com carimbo de data/hora que podem ser fornecidos pelo cliente ou aplicados automaticamente pelo serviço. Os valores de células antigas são recuperados com base em uma política de coleta de lixo configurada no nível do grupo de colunas.
Índices secundários
É possível usar visualizações materializadas contínuas como índices secundários assíncronos para tabelas para consultar os mesmos dados usando diferentes padrões ou atributos de pesquisa. Para mais informações, consulte Criar um índice secundário assíncrono.
Modelagem de dados: flexibilidade com coleções
O adaptador de proxy do Cassandra para o Bigtable transforma tipos de coleção do Cassandra, como mapas, conjuntos e listas, em famílias de colunas no Bigtable. Isso torna o uso do Bigtable com tipos de coleta do Cassandra muito eficiente, já que colunas individuais podem ser gravadas e lidas muito mais rápido do que blobs únicos.
Com o Bigtable, é possível criar aplicativos com coleções grandes e dinâmicas sem as compensações de desempenho exigidas pelo Cassandra, pelos seguintes motivos:
- O Bigtable armazena elementos de coleção como células individuais, para que as operações neles sejam altamente granulares. Isso significa que uma única atualização de mapa se traduz em uma gravação de célula leve, o que oferece alto desempenho e escalonabilidade.
- As coleções do Bigtable não têm um limite de tamanho prático, além dos limites gerais de tamanho de linha.
- O Bigtable mantém uma baixa latência consistente, não importa o tamanho da coleção, conforme mostrado na Figura 4.
Por outro lado, a documentação do Cassandra incentiva você a limitar estritamente o uso de tipos de coleção e, muitas vezes, limitar as contagens de elementos a números pequenos devido à degradação do desempenho. Como o Cassandra lê colunas de coleta como um todo, coleções grandes causam picos de latência de leitura e possível instabilidade do nó.
É possível contornar esses limites com soluções alternativas, como coleções congeladas ou armazenamento de dados como strings JSON, que sacrificam o desempenho ao introduzir uma taxa de leitura-modificação-gravação. Essa sobrecarga força o banco de dados a ler, desserializar, atualizar e reescrever todo o objeto para qualquer alteração. Além disso, o Cassandra trata esses blobs JSON como texto opaco, exigindo toda a lógica de análise na camada do aplicativo. Isso é diferente do Bigtable, que oferece processamento integrado do lado do servidor para strings JSON usando funções da API SQL.
Com o Bigtable, é possível combinar elementos de esquema fixos com dinâmicos sem comprometer nada. Isso dá aos aplicativos a flexibilidade de aplicar estrutura onde é importante, mantendo a agilidade, o que permite evoluir o modelo de dados sem migrações extensas ou tempo de inatividade. Ele também é compatível com cargas de trabalho modernas, como machine learning e IA, que exigem iteração frequente em Feature Stores e disponibilização em tempo real em escala global.
Failover e balanceamento de carga do cliente
No Cassandra, o cliente controla o balanceamento de carga das solicitações. O driver do cliente define uma política especificada como parte da configuração ou de forma programática durante a criação da sessão. O cluster informa a política sobre data centers que estão mais próximos do aplicativo. O cliente identifica nós desses data centers para processar uma operação.
O serviço do Bigtable encaminha chamadas de API para um cluster de destino com base em um parâmetro (um identificador de perfil de aplicativo) fornecido com cada operação. Os perfis de aplicativo são mantidos no serviço do Bigtable. As operações do cliente que não selecionam um perfil usam um perfil padrão.
O Bigtable tem dois tipos de políticas de roteamento de perfil de aplicativo: de cluster único e de vários clusters. Um perfil de vários clusters encaminha as operações para o cluster disponível mais próximo. Consideramos os clusters na mesma região do ponto de vista do roteador de operação. Se o nó responsável pelo intervalo de chaves solicitado estiver sobrecarregado ou temporariamente indisponível em um cluster, esse tipo de perfil oferecerá failover automático.
Em relação ao Cassandra, uma política de vários clusters oferece os benefícios de failover de uma política de balanceamento de carga que está ciente dos data centers.
Um perfil de aplicativo com roteamento de cluster único direciona todo o tráfego para um único cluster. A consistência forte entre linhas e transações de linha única estão disponíveis apenas em perfis com roteamento de cluster único.
A desvantagem de uma abordagem de cluster único é que, em um failover, o aplicativo precisa ser capaz de tentar novamente usando um identificador de perfil de aplicativo alternativo ou você precisa realizar manualmente o failover dos perfis de roteamento de cluster único afetados.
Roteamento de operação
O Cassandra e o Bigtable usam métodos diferentes para selecionar o nó de processamento para operações de leitura e gravação. No Cassandra, a chave de partição é identificada, enquanto no Bigtable a chave de linha é usada.
No Cassandra, o cliente primeiro inspeciona a política de balanceamento de carga. Esse objeto do lado do cliente determina o data center para o qual a operação é encaminhada.
Depois que o data center é identificado, o Cassandra entra em contato com um nó do coordenador para gerenciar a operação. Se a política reconhecer tokens, o coordenador será um nó que veicula dados da partição de vnode de destino; caso contrário, o coordenador será um nó aleatório. O nó coordenador identifica os nós em que as réplicas de dados da chave de partição da operação estão localizadas e, em seguida, instrui esses nós a realizar a operação.
No Bigtable, como discutido anteriormente, cada operação inclui um identificador do perfil do aplicativo. O perfil do aplicativo é definido no nível de serviço. A camada de roteamento do Bigtable inspeciona o perfil para escolher o cluster de destino apropriado para a operação. A camada de roteamento fornece um caminho para a operação alcançar os nós de processamento corretos usando a chave de linha da operação.
Processo de gravação de dados
Ambos os bancos de dados são otimizados para gravações rápidas e usam um processo similar para concluir uma gravação. No entanto, as etapas que os bancos de dados percorrem variam um pouco, especialmente para o Cassandra, em que, dependendo do nível de consistência da operação, a comunicação com os nós de participantes adicionais pode ser necessária.
Depois que a solicitação de gravação é encaminhada para os nós apropriados (Cassandra) ou nó (Bigtable), as gravações são mantidas primeiro em disco sequencialmente em um registro de confirmação (Cassandra) ou um registro compartilhado (Bigtable). Em seguida, as gravações são inseridas em uma tabela na memória (também conhecida como memtable) ordenada como as SSTables.
Depois dessas duas etapas, o nó responde para indicar que a gravação foi concluída. No Cassandra, várias réplicas (dependendo do nível de consistência especificado para cada operação) precisam responder antes que o coordenador informe ao cliente que a gravação foi concluída. No Bigtable, como cada chave de linha é atribuída a um único nó em qualquer momento, uma resposta do nó é tudo o que é necessário para confirmar que uma gravação foi bem-sucedida.
Depois, se necessário, é possível limpar a memtable no disco na forma de uma nova SSTable. No Cassandra, a limpeza ocorre quando o registro de confirmação atinge um tamanho máximo ou quando a tabela excede um limite que você configura. No Bigtable, uma limpeza é iniciada para criar novas SSTables imutáveis quando a memtable atinge um tamanho máximo especificado pelo serviço. Periodicamente, um processo de compactação mescla SSTables de um determinado intervalo de chaves em uma única SSTable.
Atualizações de dados
Os dois bancos de dados lidam com atualizações de dados de maneira semelhante. No entanto, o Cassandra permite apenas um valor por célula, enquanto o Bigtable pode manter um grande número de valores com versões para cada célula.
Quando o valor na interseção de um identificador de linha exclusivo e uma coluna é modificado, a atualização é mantida conforme descrito anteriormente na seção Processo de gravação de dados. O carimbo de data/hora de gravação é armazenado com o valor na estrutura SSTable.
Se você não limpa uma célula atualizada em uma SSTable, pode armazenar apenas o valor da célula na mtable, mas os bancos de dados são diferentes no que está armazenado. O Cassandra salva apenas o valor mais recente na memtable, enquanto o Bigtable salva todas as versões na memtable.
Como alternativa, se você tiver transferido pelo menos uma versão de um valor de célula para o disco em SSTables separadas, os bancos de dados vão processar as solicitações desses dados de maneira diferente. Quando a célula é solicitada do Cassandra, apenas o valor mais recente de acordo com o carimbo de data/hora é retornado. Em outras palavras, a última gravação vence. No Bigtable, use filtros para controlar quais versões de células uma solicitação de leitura retorna.
Exclusões de linhas
Como os dois bancos de dados usam arquivos SSTable imutáveis para manter os dados no disco, não é possível excluir uma linha imediatamente. Para garantir que as consultas retornem os resultados corretos depois que uma linha é excluída, os dois bancos de dados processam as exclusões usando o mesmo mecanismo. Um marcador (chamado de tombstone no Cassandra) é adicionado primeiro à memtable. Por fim, uma SSTable recém-grava contém um marcador com carimbo de data/hora que indica que o identificador de linha exclusivo foi excluído e não precisa ser retornado nos resultados da consulta.
Time to live (TTL)
Os recursos de time to live (TTL) nos dois bancos de dados são semelhantes, exceto por uma disparidade. No Cassandra, é possível definir o TTL para uma coluna ou tabela, enquanto no Bigtable, só é possível definir TTLs para o grupo de colunas. Há um método para o Bigtable que pode simular o TTL no nível de célula.
Coleta de lixo
Como as atualizações ou exclusões de dados imediatas não são possíveis com SSTables imutáveis, como discutido anteriormente, a coleta de lixo ocorre durante um processo chamado compactação. O processo remove células ou linhas que não devem ser exibidas nos resultados da consulta.
O processo de coleta de lixo exclui uma linha ou célula quando ocorre uma mesclagem de SSTable. Se existir um marcador ou Tombstone para uma linha, essa linha não será incluída na SSTable resultante. Os dois bancos de dados podem excluir uma célula da SSTable mesclada. Se o carimbo de data/hora da célula exceder uma qualificação TTL, ela será excluída pelos bancos de dados. Se houver duas versões com carimbo de data/hora para uma determinada célula, o Cassandra incluirá apenas o valor mais recente na SSTable mesclada.
Caminho de leitura de dados
Quando uma operação de leitura chega ao nó de processamento apropriado, o processo de leitura para coletar dados para satisfazer um resultado de consulta é o mesmo para os dois bancos de dados.
Para cada SSTable no disco que pode conter resultados de consulta, um filtro de Bloom é verificado para determinar se cada arquivo contém linhas a serem retornadas. Como os filtros de Bloom nunca fornecem um falso negativo, todas as SSTables qualificadas são adicionadas a uma lista de candidatos para serem incluídas no processamento de resultados de leitura.
A operação de leitura é realizada usando uma visualização mesclada criada a partir da mtabletable e a candidata às SSTables no disco. Como todas as chaves são classificadas lexicograficamente, é eficiente conseguir uma visualização mesclada que é verificada para receber os resultados da consulta.
No Cassandra, um conjunto de nós de processamento determinados pelo nível de consistência da operação precisa participar da operação. No Bigtable, apenas o nó responsável pelo intervalo de chaves precisa ser consultado. No Cassandra, é preciso considerar as implicações para o dimensionamento da computação, porque é provável que vários nós processem cada leitura.
Os resultados de leitura podem ser limitados no nó de processamento de maneiras ligeiramente diferentes.
No Cassandra, a cláusula WHERE em uma consulta CQL restringe as linhas retornadas. A restrição é que as colunas na chave primária ou nas colunas incluídas em um índice secundário podem ser usadas para limitar os resultados.
O Bigtable oferece uma grande variedade de filtros que afetam as linhas ou células recuperadas por uma consulta de leitura.
Há três categorias de filtros:
- Como limitar filtros, que controlam as linhas ou células incluídas na resposta.
- Filtros de modificação, que afetam os dados ou metadados de células individuais.
- Combinação de filtros, que permitem combinar vários filtros em um único filtro
Os filtros de limitação são os mais usados com frequência. Por exemplo, a expressão regular do grupo de colunas e a expressão regular do qualificador de coluna.
Armazenamento de dados físicos
O Bigtable e o Cassandra armazenam dados em SSTables, que são mesclados regularmente durante uma fase de compactação. A compactação de dados SSTable oferece benefícios semelhantes para reduzir o tamanho do armazenamento. No entanto, a compactação é aplicada automaticamente no Bigtable e é uma opção de configuração no Cassandra.
Ao comparar os dois bancos de dados, é preciso entender como cada banco de dados armazena fisicamente os dados de maneira diferente nos seguintes aspectos:
- Estratégia de distribuição de dados
- O número de versões de célula disponíveis
- O tipo de disco de armazenamento
- O mecanismo de durabilidade e replicação de dados
Distribuição de dados
No Cassandra, um hash consistente das colunas de partição da chave primária é o método recomendado para determinar a distribuição de dados nas várias SSTables veiculadas pelos nós do cluster.
O Bigtable usa um prefixo variável para a chave de linha completa para colocar os dados lexicograficamente em SSTables.
Versões móveis
O Cassandra mantém apenas uma versão de valor de célula ativa. Se duas gravações forem feitas em uma célula, uma política de última gravação garantirá que apenas um valor seja retornado.
O Bigtable não limita o número de versões com carimbo de data/hora para cada célula. Outros limites de tamanho de linha podem ser aplicados. Se não for definido pela solicitação do cliente, o carimbo de data/hora será determinado pelo serviço do Bigtable no momento em que o nó de processamento receber a mutação. As versões de células podem ser removidas usando uma política de coleta de lixo que pode ser diferente para cada família de colunas da tabela ou podem ser filtradas de um conjunto de resultados de consulta pela API.
Armazenamento em disco
O Cassandra armazena SSTables em discos anexados a cada nó do cluster. Para reequilibrar os dados no Cassandra, os arquivos precisam ser copiados fisicamente entre os servidores.
O Bigtable usa o Colossus para armazenar SSTables. Como o Bigtable usa esse sistema de arquivos distribuído, é possível que o serviço Bigtable reatribua SSTables instantaneamente a nós diferentes.
Durabilidade e replicação de dados
O Cassandra oferece durabilidade dos dados por meio da configuração do fator de replicação. O fator de replicação determina o número de cópias SSTable armazenadas em nós diferentes no cluster. Uma configuração típica do fator de replicação é 3, que ainda oferece garantias de consistência mais forte com QUORUM ou LOCAL_QUORUM, mesmo que ocorra uma falha no nó.
Com o Bigtable, são oferecidas garantias de alta durabilidade de dados por meio da replicação fornecida pelo Colossus.
O diagrama a seguir ilustra o layout de dados físicos, os nós de processamento de computação e a camada de roteamento do Bigtable:
Na camada de armazenamento Colossus, cada nó é atribuído para disponibilizar os dados armazenados em uma série de SSTables. Esses SSTables contêm os dados dos intervalos de chaves de linha atribuídos dinamicamente a cada nó. Embora o diagrama mostre três SSTables para cada nó, provavelmente há mais porque os SSTables são criados continuamente à medida que os nós recebem novas alterações nos dados.
Cada nó tem um registro compartilhado. As gravações processadas por cada nó são mantidas imediatamente no registro compartilhado antes que o cliente receba uma confirmação de gravação. Como uma gravação no Colossus é replicada várias vezes, a durabilidade é garantida mesmo se ocorrer uma falha de hardware nodal antes que os dados sejam mantidos em uma SSTable para o intervalo de linhas.
Interfaces de aplicativos
Originalmente, o acesso ao banco de dados do Cassandra era exposto por uma API Thrift, mas esse método de acesso foi descontinuado. A interação recomendada com o cliente é por meio do CQL.
Semelhante à API original do Thrift do Cassandra, o acesso ao banco de dados do Bigtable é fornecido por meio de uma API que lê e grava dados com base nas chaves de linha fornecidas.
Assim como o Cassandra, o Bigtable tem uma interface de linha de comando,
chamada
CLI cbt,
e bibliotecas de cliente compatíveis com muitas linguagens de programação
comuns. Essas bibliotecas são criadas com base nas APIs
gRPC e REST. Os aplicativos criados para o Hadoop e que dependem da biblioteca de código aberto Apache HBase para Java podem se conectar sem alterações significativas ao Bigtable. Para aplicativos que não exigem compatibilidade com o HBase, recomendamos que você use o cliente Java integrado do Bigtable.
Os controles de gerenciamento de identidade e acesso (IAM) do Bigtable são totalmente integrados ao Google Cloud, e as tabelas também podem ser usadas como uma fonte de dados externa do BigQuery.
Configuração do banco de dados
Ao configurar um cluster do Cassandra, você precisa tomar várias decisões de configuração e concluir algumas etapas. Primeiro, configure os nós do servidor para fornecer capacidade de computação e provisionar armazenamento local. Ao usar um fator de replicação de três, a configuração recomendada e mais comum, é necessário provisionar o armazenamento para armazenar três vezes a quantidade de dados que você espera manter no cluster. Também é preciso determinar e definir configurações para vnodes, racks e replicação.
A separação de computação do armazenamento no Bigtable simplifica o escalonamento de clusters, em comparação com o Cassandra. Em um cluster de execução normalmente, você só precisa se preocupar com o armazenamento total usado pelas tabelas gerenciadas, que determina o número mínimo de nós, e você tem nós suficientes para manter o QPS atual.
É possível ajustar rapidamente o tamanho do cluster do Bigtable se o cluster estiver super ou subprovisionado com base na carga de produção.
Armazenamento do Bigtable
Além da localização geográfica do cluster inicial, a única opção que você precisa fazer ao criar sua instância do Bigtable é o tipo de armazenamento. O Bigtable oferece duas opções de armazenamento: unidades de estado sólido (SSD, na sigla em inglês) ou unidades de disco rígido (HDD, na sigla em inglês). Todos os clusters em uma instância precisam compartilhar o mesmo tipo de armazenamento.
Ao considerar as necessidades de armazenamento com o Bigtable, não é necessário considerar as réplicas de armazenamento, como você faria ao dimensionar um cluster do Cassandra. Não há perda de densidade de armazenamento para alcançar a tolerância a falhas, como ocorre no Cassandra. Além disso, como o armazenamento não precisa ser provisionado expressamente, você só é cobrado pelo armazenamento em uso.
SSD
A capacidade de 5 TB do nó SSD, que é preferível para a maioria das cargas de trabalho, fornece maior densidade de armazenamento em comparação à configuração recomendada para máquinas Cassandra, que têm uma densidade máxima de armazenamento prática menor que 2 TB para cada nó. Ao avaliar as necessidades de capacidade de armazenamento, lembre-se de que o Bigtable conta apenas uma cópia dos dados. Por comparação, o Cassandra precisa considerar três cópias dos dados na maioria das configurações.
Embora o QPS de gravação para SSD seja aproximadamente o mesmo que o HDD, o SSD fornece um QPS de leitura significativamente maior do que o HDD. O preço do armazenamento SSD é igual ou próximo aos custos dos discos permanentes SSD provisionados e varia de acordo com a região.
HDD
O tipo de armazenamento HDD permite uma densidade de armazenamento considerável: 16 TB para cada nó. A desvantagem é que as leituras aleatórias são significativamente mais lentas, sendo compatíveis com apenas 500 linhas lidas por segundo para cada nó. O HDD é preferível em cargas de trabalho com gravação pesada, em que leituras são esperadas verificações de intervalo associadas ao processamento em lote. O armazenamento HDD é cobrado de acordo com o custo associado ao Cloud Storage e varia de acordo com a região.
Considerações sobre o tamanho do cluster
Ao dimensionar uma instância do Bigtable para se preparar para migrar uma carga de trabalho do Cassandra, há considerações ao comparar clusters de data center do data center com instâncias do Bigtable de cluster único e o data center do Cassandra com vários dados. clusters para instâncias do Bigtable com vários clusters. As diretrizes nas seções a seguir pressupõem que não é necessária nenhuma alteração significativa no modelo de dados para migrar e que há uma compactação de armazenamento equivalente entre o Cassandra e o Bigtable.
Um cluster de data center único
Ao comparar um cluster de data center único a uma instância do Bigtable de cluster único, primeiro você precisa considerar os requisitos de armazenamento. É possível estimar o tamanho não replicado de cada keyspace usando o comando tablestats nodetool e dividindo o tamanho total de armazenamento liberado pelo fator de replicação do keyspace. para criar um anexo da VLAN de monitoramento. Depois, divida a quantidade de armazenamento não replicada de todos os espaços de chaves por
3,5 TB (5 TB *
.70
) para determinar o número sugerido de nós de SSD para lidar apenas com o armazenamento. Conforme discutido, o Bigtable lida com a replicação e a durabilidade do armazenamento em um nível separado que é transparente para o usuário.
A seguir, considere os requisitos de computação para o número de nós. Consulte as métricas do servidor e do aplicativo cliente do Cassandra para ter um número aproximado de leituras e gravações sustentadas que foram executadas. Para estimar o número mínimo de nós do SSD que serão executados na carga de trabalho, divida essa métrica por 10.000. É provável que você precise de mais nós para aplicativos que exigem resultados de consulta de baixa latência. O Google recomenda testar a performance do Bigtable com dados e consultas representativos para estabelecer uma métrica de QPS por nó que seja possível alcançar para sua carga de trabalho.
O número de nós necessários para o cluster precisa ser igual ao maior das necessidades de armazenamento e computação. Se você tiver dúvidas sobre suas necessidades de armazenamento ou capacidade de processamento, faça a correspondência entre o número de nós do Bigtable e o número de máquinas típicas do Cassandra. É possível escalonar verticalmente um cluster do Bigtable para atender às necessidades da carga de trabalho com o mínimo de esforço e sem inatividade.
Um cluster de data center múltiplos
Com clusters de data center múltiplos, é mais difícil determinar a configuração de uma instância do Bigtable. O ideal é ter um cluster na instância para cada data center na topologia do Cassandra. Cada cluster do Bigtable na instância precisa armazenar todos os dados na instância e ser capaz de lidar com a taxa de inserção total em todo o cluster. Os clusters em uma instância podem ser criados em qualquer região da nuvem compatível no mundo todo.
A técnica para estimar as necessidades de armazenamento é semelhante à abordagem para clusters de data center único. Use nodetool para capturar o tamanho do armazenamento de cada keyspace no cluster do Cassandra e, em seguida, divida esse tamanho pelo número de réplicas. Você precisa lembrar que o keyspace da tabela pode ter diferentes fatores de replicação para cada data center.
O número de nós em cada cluster de uma instância precisa ser capaz de processar todas as gravações no cluster e todas as leituras em pelo menos dois data centers para manter os objetivos de nível de serviço (SLOs) durante uma interrupção do cluster. Uma abordagem comum é começar com todos os clusters que tenham a capacidade de nó equivalente do data center mais movimentado no cluster do Cassandra. Os clusters do Bigtable em uma instância podem ser escalonados individualmente para corresponder às necessidades de carga de trabalho sem tempo de inatividade.
Administração
O Bigtable fornece componentes totalmente gerenciados para funções de administração comuns realizadas no Cassandra.
Backup e restauração
O Bigtable oferece dois métodos para atender às necessidades comuns de backup: backups do Bigtable e exportações de dados gerenciadas.
Os backups do Bigtable são semelhantes a uma versão gerenciada do recurso de snapshot nodetool do Cassandra. Os backups do Bigtable criam cópias restauráveis de uma tabela, que são armazenadas como objetos membros de um cluster. É possível restaurar backups como uma nova tabela no cluster que
iniciou o backup. Os backups são projetados para criar pontos de restauração se
ocorrer corrupção no nível do aplicativo. Os backups criados por esse utilitário não consomem recursos de nó e têm preços iguais ou próximos aos do Cloud Storage. É possível invocar backups do Bigtable de maneira programática ou pelo console do Google Cloud para o Bigtable.
Outra maneira de fazer o backup do Bigtable é usar uma exportação de dados gerenciada para o Cloud Storage. É possível exportar para os formatos de arquivo Avro, Parquet ou Hadoop Sequence. Em comparação com os backups do Bigtable, as exportações levam mais tempo para serem executadas e geram custos extras de computação porque as exportações usam o Dataflow. No entanto, essas exportações criam arquivos de dados portáteis que podem ser consultados off-line ou importados para outro sistema.
Redimensionar
Como o Bigtable separa o armazenamento e a computação, é possível adicionar ou remover nós do Bigtable em resposta à demanda de consulta com mais facilidade do que é possível no Cassandra. A arquitetura homogênea do Cassandra requer que você reequilibre nós (ou vnós) nas máquinas do cluster.
É possível alterar o tamanho do cluster manualmente no console do Google Cloud ou usando a API Cloud Bigtable de maneira programática. Adicionar nós em um cluster pode gerar melhorias de desempenho perceptíveis em minutos. Alguns clientes usaram com sucesso um escalonador automático de código aberto desenvolvido pelo Spotify (link em inglês).
Manutenção interna
O serviço Bigtable gerencia perfeitamente tarefas de manutenção internas do Cassandra, como aplicação de patches de SO, recuperação de nós, reparo de nós, monitoramento de compensação de armazenamento e rotação de certificados SSL.
Monitoramento
Conectar o Bigtable à visualização de métricas ou alerta não requer esforço de administração ou desenvolvimento. A página do console do Bigtable noGoogle Cloud vem com painéis pré-criados para rastrear métricas de capacidade e utilização no nível da instância, do cluster e da tabela. As visualizações e os alertas personalizados podem ser criados nos painéis do Cloud Monitoring, em que as métricas são disponibilizadas automaticamente.
O Key Visualizer do Bigtable, um recurso de monitoramento no console do Google Cloud , permite fazer ajuste de desempenho avançado.
IAM e segurança
No Bigtable, a autorização é totalmente integrada ao framework do IAM doGoogle Cloud e requer configuração e manutenção mínimas. As contas de usuário e as senhas locais não são compartilhadas com aplicativos cliente. Em vez disso, permissões e papéis granulares são concedidos a usuários no nível da organização e a contas de serviço.
O Bigtable criptografa automaticamente todos os dados em repouso e em trânsito. Não há opções para desativar esses recursos. Todo o acesso administrativo é totalmente registrado. É possível usar o VPC Service Controls para controlar o acesso a instâncias do Bigtable de fora das redes aprovadas.
A seguir
- Leia sobre o design de esquema do Bigtable.
- Saiba mais sobre o Apache Cassandra.
- Faça o codelab do Bigtable para usuários do Cassandra.
- Aprenda mais sobre o emulador do Bigtable.
- Confira arquiteturas de referência, diagramas, tutoriais e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.