Bigtable para usuários do Cassandra

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 armazenamento de dados. Este documento aplica seu conhecimento do Apache Cassandra ao uso do Bigtable.

O Bigtable e o Cassandra são bancos de dados distribuídos. Eles implementam armazenamentos de chave-valor multidimensionales que podem suportar dezenas de milhares de consultas por segundo (QPS, na sigla em inglês), armazenamento em até petabytes de dados e tolerância a falhas do nó.

Ainda que os conjuntos de recursos desses bancos de dados sejam de alto nível, as arquiteturas subjacentes e os detalhes de interação são diferentes de maneiras importantes. Neste documento, destacamos as semelhanças e as diferenças entre os dois sistemas de banco de dados.

Quando o Bigtable é um bom destino para cargas de trabalho do Cassandra

O melhor serviço do Google Cloud para sua carga de trabalho do Cassandra depende das suas metas de migração e das funcionalidades do Cassandra necessárias após a migração.

O Bigtable é ideal quando a taxa de transferência e a latência são tão importantes para gravações quanto para leituras. A consistência posterior do Bigtable, as gravações locais rápidas, a capacidade de usar carimbos de data/hora personalizados, o esquema flexível (como tipos de coleção atualizáveis) e a variedade de topologias de cluster permitem que o Bigtable ofereça suporte a aplicativos em evolução e ofereça baixas latências de forma econômica.

Para migrar aplicativos sem nenhuma mudança no código, você pode autogerenciar o Cassandra no GKE ou usar um parceiro do Google Cloud, como o DataStax ou o ScyllaDB. Se o aplicativo for de leitura pesada e você quiser refatorar o código para ter 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, se você escolher o Bigtable como o 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.

Comparar dois bancos de dados antigos não é uma tarefa simples. Para isso, 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 do Google 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 Cloud Bigtable em diferentes zonas ou regiões do Google Cloud 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 de 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.
contador: 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 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. APIs do Bigtable: 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ções de linhas e consultas. A API SQL do Bigtable será familiar para os usuários do CQL.

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 principais recursos descritos no documento 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 durabilidade que excede os níveis fornecidos pela replicação de três vias 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 HBase Apache, uma implementação alternativa do mecanismo de banco de dados de código aberto do documento do Bigtable.

O diagrama a seguir mostra como o Bigtable separa fisicamente os nós de processamento da camada de armazenamento:

Os clientes se comunicam por meio de uma camada de roteamento para processar nós, que, por sua vez, se comunicam com a 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:

O reequilíbrio espalha o processamento por vários nós, e o redimensionamento adiciona nós de processamento.

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. Após o reequilíbrio, o nó do meio, em vez do nó mais à esquerda, é responsável por veicular solicitações de dados para o conjunto de dados 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 e determinar o posicionamento dos dados. Assim como no Bigtable, você pode usar um particionamento de preservação de pedido para a geração de tokens e, assim, para a colocação de dados. No entanto, a documentação do Cassandra desaconselha essa abordagem porque o cluster provavelmente ficará desequilibrado, uma condição difícil de consertar. Por isso, este documento pressupõe que você use uma estratégia de hash consistente para gerar tokens que resultem na distribuição de dados nos 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 por meio de 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 em termos simplificados um cluster de seis nós com o intervalo de chave de cada nó dividido em cinco nós. Na prática, é possível ter mais nós e provavelmente haverá mais nós.

Uma arquitetura que inclui um nó de coordenador, armazenamento de nós local e outros nós, cada um com 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, proveniente de um aplicativo ou serviço cliente (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ó for sobrecarregado com solicitações para um determinado intervalo de hash de token, adicionar o processamento para esse intervalo de token será mais complexo no Cassandra do que no 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 força da consistência eventual podem variar, incluindo opções que exigem um único nó de réplica (ONE), um nó de réplica de data center majoritário (LOCAL_QUORUM) ou a maioria de todos os replicar nós 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 pode ser um grupo de clusters replicados. Você pode colocar clusters de instâncias em qualquer combinação de zonas em qualquer região oferecida pelo Google Cloud. Você pode adicionar e remover clusters de uma instância com impacto mínimo para outros clusters nela.

No Bigtable, as gravações são realizadas (com consistência na leitura das gravações) em um único cluster e, posteriormente, serão consistentes nos outros clusters da instância. Como as células individuais têm controle de versão por carimbo de data/hora, nenhuma gravação é perdida e cada cluster exibe as 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 do 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 seja compatível com transações de várias linhas complexas, cada um tem suporte de transações.

O Cassandra tem um método de transação leve (LWT, na sigla em inglês) que fornece atomicidade para atualizações em valores de coluna em uma única partição. O Cassandra também tem comparar e definir semânticas que concluem a operação de leitura de linha e comparação de valor antes de uma gravação ser iniciada.

O Bigtable é compatível com gravações de linha única e consistentes em um cluster. Transações de linha única são ainda mais ativadas por meio das 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. Ambos os sistemas são classificados como armazenamentos de coluna larga NoSQL.

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 de possíveis vantagens entre a execução de verificações eficientes em uma única partição e os custos do sistema associados à manutenção de partições grandes.

No Bigtable, você só precisa criar a tabela e definir os grupos de colunas antecipadamente. As colunas não são declaradas quando as tabelas são criadas, mas são criadas quando as chamadas da 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 do novel para os intervalos de chaves, geralmente chamados de blocos e, às vezes, de divisões. As chaves de linha do Bigtable geralmente consistem em vários valores de campo que são mesclados usando um caractere separador comumente usado de sua escolha, 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 da tabela é a chave de linha. A chave de linha precisa ser um valor único em uma tabela inteira. Crie chaves de várias partes concatenando elementos distintos que são separados por um delimitador comum. A chave de linha determina a ordem de classificação de dados global 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, crie uma chave de linha no Bigtable para que as linhas que você quer recuperar sejam armazenadas juntas. No entanto, no Bigtable, não é necessário projetar a chave de linha para colocação e ordem 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 oferecem métodos auxiliares para gravar valores de célula como bytes, strings codificadas em UTF-8 e big-end inteiros de 64 bits codificados (números 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). Você precisa criar grupos de colunas explicitamente para 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 antigos das células são recuperados com base em uma política de coleta de lixo configurada no nível do grupo de colunas.

Índices secundários

O Bigtable não é compatível com índices secundários. Se um índice for necessário, recomendamos o uso de um design de tabela que use uma segunda tabela com uma chave de linha diferente.

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 maneira 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 Bigtable encaminha chamadas de API para um cluster de destino com base em um parâmetro (um identificador de perfil do aplicativo) fornecido com cada operação. Os perfis de aplicativo são mantidos no serviço Bigtable. As operações de 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 tentar novamente usando um identificador de perfil de aplicativo alternativo ou você precisa executar o failover manualmente 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, e ela é usada no Bigtable.

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 vnós de destino. Caso contrário, o coordenador será um nó aleatório. O nó do coordenador identifica os nós em que estão localizadas as réplicas de dados da chave de partição de operação e, em seguida, instrui-os a executar 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 coordenação 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, basta responder a uma solicitação do nó para confirmar se a gravação foi bem-sucedida.

Posteriormente, se necessário, será possível liberar a memtable para o 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 immutable quando a tabela atinge um tamanho máximo especificado pelo serviço. Periodicamente, um processo de compactação mescla SSTables para 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 para cada célula, enquanto o Bigtable pode manter um grande número de valores com controle de versão para cada célula.

Quando o valor na interseção de uma coluna e um identificador de linha exclusivos é 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 ao lado do 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ê liberar pelo menos uma versão de um valor de célula para um disco em SSTables separados, os bancos de dados processam solicitações para esses dados de forma diferente. Quando a célula é solicitada do Cassandra, somente o valor mais recente de acordo com o carimbo de data/hora é retornado; Em outras palavras, a última gravação ganha. No Bigtable, você usa filtros para controlar as versões de células retornadas por uma solicitação de leitura.

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.

Tempo para ficar ativa

Os recursos de vida útil (TTL, na sigla em inglês) dos dois bancos de dados são semelhantes, exceto por uma disparidade. No Cassandra, é possível definir o TTL de uma coluna ou tabela. No Bigtable, só é possível definir TTLs do 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 Bloom é verificado para determinar se cada arquivo contém linhas a serem retornadas. Como os filtros do Bloom têm a garantia de nunca fornecer um falso negativo, todos os SSTables qualificados são adicionados a uma lista de candidatos a serem incluídos no processamento do resultado 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, somente o nó responsável pelo intervalo de chaves precisa ser consultado. Para o Cassandra, é preciso considerar as implicações de dimensionamento de 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 que uma consulta de leitura recupera.

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, 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 Bigtable no momento em que o nó de processamento recebe a mutação. As versões de célula podem ser interrompidas usando uma política de coleta de lixo que pode ser diferente para o grupo de colunas de cada tabela ou pode ser filtrada em um conjunto de resultados da consulta por meio da 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:

A arquitetura da replicação de dados inclui um front-end, clusters do Bigtable e o Colossus.

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 em Colossus é replicada várias vezes, a durabilidade é garantida mesmo que ocorra uma falha de hardware do Nodal antes que os dados sejam mantidos em uma SSTable no intervalo de linhas.

Interfaces de aplicativos

Originalmente, o acesso ao banco de dados do Cassandra foi exposto por meio de uma API Thrift, mas esse método de acesso foi descontinuado. A interação recomendada com o cliente é por meio da 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. Além disso, 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ê tem várias decisões de configuração a serem tomadas e as etapas a serem concluídas. Primeiro, você precisa configurar os nós de servidor para fornecer capacidade de computação e provisionar o armazenamento local. Ao usar um fator de replicação de três, a configuração recomendada e a mais comum, é necessário provisionar o armazenamento para armazenar três vezes a quantidade de dados que você espera manter em seu cluster. Também é preciso determinar e definir as configurações de vnodes, racks e replicações.

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, você não precisa considerar as réplicas de armazenamento como faria ao dimensionar um cluster do Cassandra. Não há perda de densidade de armazenamento para conseguir tolerância a falhas, como ocorre no Cassandra. Além disso, como o armazenamento não precisa ser provisionado expressamente, você só será 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 armazenamento SSD tem preço igual ou próximo aos custos de discos permanentes SSD provisionados, que variam por 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. Depois, divida a quantidade de armazenamento não replicada de todos os espaços principais por 3,5 TB (5 TB * ,70) para determinar o número sugerido de nós de SSD para lidar apenas com o armazenamento. para criar um anexo da VLAN de monitoramento. 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. É possível consultar as métricas do servidor do Airflow e do aplicativo Cassandra para ver um número aproximado de leituras e gravações contínuas 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. Você provavelmente precisa de mais nós para aplicativos que exigem resultados da consulta de baixa latência. O Google recomenda que você teste o desempenho do Bigtable com dados e consultas representativos para estabelecer uma métrica para o QPS por nó acessível 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 estiver em dúvida sobre suas necessidades de armazenamento ou capacidade, poderá corresponder o número de nós do Bigtable com 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 de nuvem com suporte em todo o mundo.

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 em uma instância precisa ser capaz de manipular todas as gravações no cluster e todas as leituras para pelo menos dois data centers, a fim de manter os objetivos de nível de serviço (SLOs, na sigla em inglês) durante uma interrupção no 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 uma corrupção no nível do aplicativo. Os backups que você cria por meio desse utilitário não consomem recursos de nó e têm preços de preços próprios ou próximos ao Cloud Storage. É possível invocar backups do Bigtable de maneira programática ou por meio do Console do Google Cloud para 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 de maneira programática usando a API Cloud Bigtable. Adicionar nós em um cluster pode gerar melhorias de desempenho perceptíveis em minutos. Alguns clientes têm usado um escalonador automático de código aberto desenvolvido pelo Spotify.

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 Google Cloud do Bigtable 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.

Com o Key Visualizer do Bigtable, um recurso de monitoramento no Console do Google Cloud, é possível fazer ajustes avançados de desempenho.

IAM e segurança

No Bigtable, a autorização é totalmente integrada ao framework do IAM do Google Cloud e requer configuração e manutenção mínimas. As contas e senhas de usuários locais não são compartilhadas com aplicativos clientes. Em vez disso, permissões e papéis granulares são concedidos a usuários no nível da organização e 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 acesso administrativo é totalmente registrado. É possível usar o VPC Service Controls para controlar o acesso a instâncias do Bigtable de fora de redes aprovadas.

A seguir