Este documento é destinado a desenvolvedores de software e administradores de banco de dados que querem migrar aplicativos existentes ou projetar novos aplicativos para usar 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 você pode usar para concluir a migração, consulte 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 suportar dezenas de milhares de consultas por segundo (QPS), leituras e gravações de baixa latência, armazenamento em até petabytes de dados e tolerância a falhas do nó.
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.
O Bigtable é ideal se uma ou mais das seguintes condições forem atendidas:
- 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 às mudanças no tráfego do servidor.
- Você precisa de 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 de gravação e a latência são tão importantes quanto as leituras.
- Você usa um dos modelos de replicação com consistência eventual do Cassandra.
- Seu caso de uso exige armazenamento econômico.
Para migrar aplicativos sem alterações no código, você pode optar por gerenciar o Cassandra por conta própria no GKE ou usar um parceiro Google Cloud como a DataStax ou a ScyllaDB. Se o aplicativo for pesado para 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 da 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 dos dados físicos para entender aspectos da arquitetura do banco de dados.
- Descreve como configurar a replicação geográfica para atender aos seus requisitos e como abordar o dimensionamento de 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 do blog (2012), Ilya Grigorik escreve o seguinte: "Uma SSTable é uma abstração simples para armazenar de maneira eficiente um grande número de pares de chave-valor enquanto otimiza alta capacidade, cargas de trabalho de leitura ou gravação sequenciais."
A tabela a seguir descreve e descreve 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 , colocalizado para questões 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 Google Cloud zonas ou regiões entre 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, as famílias de colunas são tratadas como mapas do Cassandra. |
| chave do mapa: chave que identifica de forma exclusiva 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 é um substituto perfeito para seus drivers do Cassandra. O cliente Java entende suas consultas CQL e permite que você use o Bigtable de maneira 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 com seu aplicativo e se conectar ao Bigtable como outro nó do Cassandra. O adaptador de proxy oferece compatibilidade com CQL e aceita migrações em massa e de gravação dupla. Essa funcionalidade é semelhante à oferecida pelo cliente do Cassandra para Bigtable em Java. As APIs do Bigtable são as bibliotecas de cliente e as APIs gRPC usadas na criação de instâncias e clusters, criação de grupos de colunas e tabelas, mutação de linhas e execução de consultas. A API SQL do Bigtable é familiar para usuários do CQL. |
| Visualização materializada: uma instrução |