Bigtable para utilizadores do Aerospike

Este documento ajuda os programadores de software e os administradores de bases de dados a migrar aplicações Aerospike existentes com o Bigtable como base de dados. Usa o seu conhecimento do Aerospike para descrever conceitos que tem de compreender antes de migrar para o Bigtable.

Para ajudar a começar a trabalhar com o Bigtable e o Aerospike, este documento faz o seguinte:

  • Compara a terminologia entre o Aerospike e o Bigtable.
  • Fornece uma vista geral das operações do Bigtable e descreve o esquema de dados no Bigtable.
  • Explica a modelagem de dados e as principais considerações de design.
  • Esclarece como a replicação é realizada e qual é o seu impacto.

Para obter informações sobre o processo de migração e as ferramentas de código aberto que pode usar para concluir a migração, consulte o artigo Migrar do Aerospike para o Bigtable.

Comparação de terminologia

O Aerospike e o Bigtable são bases de dados NoSQL distribuídas, mas diferem significativamente no respetivo design, funcionamento e terminologia.

No Aerospike, os dados são armazenados em registos. Cada registo contém um ou mais contentores com nome, juntamente com metadados, como o tamanho do registo (em bytes), o tempo de vida (TTL) e a hora da última atualização (LUT).

O Bigtable armazena dados em tabelas escaláveis, cada uma das quais é um mapa de chave/valor ordenado. A tabela é composta por linhas indexadas por chaves de linhas e colunas identificadas por um qualificador de coluna. Se estiverem relacionadas entre si, as colunas podem formar uma família de colunas. Esta estrutura permite-lhe armazenar várias versões de um valor na mesma chave. Cada versão é identificada por uma data/hora única. As versões anteriores podem ser filtradas durante as operações de leitura ou removidas através da recolha de lixo com base nas políticas configuradas.

Para mais informações, consulte o artigo Modelo de armazenamento do Bigtable.

A tabela seguinte descreve os conceitos partilhados e a terminologia correspondente que cada produto usa:

Aerospike Bigtable
Nenhum item correspondente direto. instância: um grupo gerido de clusters em diferentes Google Cloud zonas ou regiões entre os quais ocorre a replicação e o encaminhamento de ligações.
cluster: uma implementação do Aerospike que consiste numa coleção de nós. cluster: um grupo de nós nas mesmas Google Cloud zonas geográficas.
Nó: um servidor que fornece computação e é proprietário do respetivo armazenamento. nó: um servidor que fornece apenas computação. O armazenamento é processado pelo Colossus, um sistema de ficheiros distribuído separado.
namespace: armazena parâmetros como o TTL ou o tipo de armazenamento. Num espaço de nomes, os dados são subdivididos em conjuntos e registos. Tabela: o equivalente mais próximo de um espaço de nomes do Aerospike. Alguns parâmetros são definidos para todas as tabelas ao nível do cluster. É possível um controlo mais preciso ao nível da tabela ou da família de colunas.
set: usado para a divisão lógica de registos e parâmetros, como TTL e tamanho do limite. As chaves têm de ser exclusivas num conjunto. Nenhum item correspondente direto.
Nenhum item correspondente direto. table: um recurso ao nível da instância que é replicado automaticamente para todos os clusters. Uma tabela contém um conjunto de valores identificados por chaves de linhas únicas. As tabelas são esparsas, o que significa que não usam espaço adicional para armazenar colunas que não contêm valores.
Nenhum item correspondente direto. Tabela: um intervalo contínuo de linhas armazenadas em conjunto. O Bigtable usa tablets para o equilíbrio de carga, atribuindo-os a nós. Os limites dos tablets são dinâmicos e podem dividir-se ou unir-se ao longo do tempo.
registo: um conjunto de contentores com nomes usados para armazenar dados. Pode ter, no máximo, 8 MB. linha: um conjunto de valores identificados pela família de colunas, pelo qualificador de coluna e pela data/hora. Todas as operações são atómicas ao nível da linha.
Nenhum item correspondente direto. Família de colunas: um grupo de colunas ordenadas por ordem lexicográfica. A recolha de lixo é definida a este nível.
bin: um par de chave-valor em que o nome do recipiente é o identificador de um valor num registo. Qualificador de coluna: uma etiqueta para um valor armazenado numa tabela.
Nenhum item correspondente direto. célula: uma etiqueta para um valor com data/hora armazenado numa tabela.
Resumo(registo): um hash de uma tripla que identifica um registo: espaço de nomes, conjunto e chave. Nenhum item correspondente direto.
key: um identificador de registo exclusivo num conjunto. row key: um identificador de linha exclusivo numa tabela.
AQL:uma ferramenta de linha de comandos para procurar dados e desenvolver funções definidas pelo utilizador para a base de dados Aerospike. GoogleSQL: uma linguagem de consulta usada por vários Google Cloud serviços, incluindo o Spanner, o BigQuery e o Bigtable.

Limites de tipos de dados

A tabela seguinte compara os limites dos tipos de dados usados pelo Aerospike e pelo Bigtable:

Aerospike Bigtable
namespace: o número máximo de espaços de nomes para a Enterprise Edition é 32. tabela: uma instância pode ter até 1000 tabelas. O nome de uma tabela não pode exceder 50 carateres.
set: um cluster pode ter até 4095 conjuntos. Um nome do conjunto não pode exceder 63 bytes. Nenhum item correspondente direto.
Registo: o tamanho máximo do registo é de 8 MB. Linha: o tamanho máximo da linha é de 256 MB.
Nenhum item correspondente direto. Família de colunas: o número de famílias de colunas é ilimitado. No entanto, mais de 100 pode causar uma degradação do desempenho.
bin: o número de contentores é ilimitado. No entanto, cada contentor não pode conter mais de 1 MB de dados. O nome do contentor não pode exceder 15 bytes. qualificador de coluna: o limite é de 100 MB, mas recomenda-se não exceder os 10 MB. O número de colunas é ilimitado.
key: o tamanho máximo da chave é de 8 KB. chave da linha: o tamanho máximo da chave da linha é de 4 KB.

Para mais informações sobre os limites do Bigtable e do Aerospike, consulte as secções Quotas e limites e Limites e limites mínimos do sistema Aerospike, respetivamente.

Arquitetura

As secções seguintes fornecem uma vista geral da arquitetura do Bigtable e do Aerospike.

Bigtable

Os nós do Bigtable estão separados da camada de armazenamento, o que significa que os nós não afetam a durabilidade dos dados. Os clientes de tabelas do Bigtable não têm conhecimento da distribuição de dados subjacente. Uma camada de encaminhamento adicional distribui os pedidos para o nó correto. Cada nó processa um subconjunto dos pedidos para o cluster. Uma tabela do Bigtable é dividida em blocos de linhas contíguas, denominados tablets, que são armazenados no Colossus, um sistema de ficheiros distribuído que oferece uma elevada durabilidade. Cada tablet está associado a um nó do Bigtable específico.

Os clientes no cluster do Bigtable comunicam com os nós através da camada de encaminhamento que distribui os dados para o nó correto.

A arquitetura do Bigtable oferece as seguintes vantagens:

  • Os clientes do Bigtable não precisam de estar cientes da distribuição de dados e do equilíbrio de carga. Estas complexidades são processadas pela camada de encaminhamento.
  • O reequilíbrio ocorre muito rapidamente e a recuperação de falhas é rápida porque os dados reais não são copiados entre os nós.
  • Quando um nó do Bigtable falha, não se perdem dados.

Aerospike

Ao contrário do Bigtable, o armazenamento do Aerospike está localizado nos nós que o servem. Todos os nós (um servidor) no cluster do Aerospike são idênticos. Os dados em cada espaço de nomes são divididos exatamente em 4096 partições através da aplicação de hash aos nomes dos registos. Estas partições são distribuídas uniformemente entre os nós.

Os nós têm conhecimento uns dos outros e reequilibram as partições armazenadas quando o cluster muda. Sempre que ocorre uma alteração do cluster, as réplicas elegem uma réplica principal que coordena o reequilíbrio. Espera-se que as bibliotecas cliente acompanhem a réplica que armazena a partição principal e enviem pedidos de gravação para as réplicas certas. Se um cliente enviar um pedido para o nó errado (isto pode acontecer durante o reequilíbrio), o pedido é reencaminhado pelos nós.

Os clientes no cluster do Aerospike comunicam com os nós que processam o reequilíbrio da carga de trabalho

Replicação

Esta secção compara o processo de replicação do Aerospike e do Bigtable.

Bigtable

Uma instância do Bigtable pode consistir num único cluster ou em vários clusters replicados. Uma tabela é sempre replicada para todos os clusters numa instância. Os clusters podem ser adicionados ou removidos de uma instância com um impacto mínimo noutros clusters.

O Bigtable oferece consistência de leitura das suas escritas num único cluster. As escritas são realizadas num único cluster e tornam-se eventualmente consistentes noutros clusters na instância. Ao contrário do Aerospike, o Bigtable não perde atualizações intermédias porque as células individuais têm versões internas, o que garante que não se perdem escritas. Cada cluster publica as células que têm as datas/horas mais atuais disponíveis.

A API Bigtable oferece um token de consistência ao nível da tabela, que pode ser usado para verificar se todas as alterações feitas antes da criação do token foram replicadas completamente.

Aerospike

O Aerospike processa a replicação num cluster ao nível da partição. Um espaço de nomes é dividido em partições que são distribuídas uniformemente entre os nós. A consistência forte é garantida num cluster. Uma operação de escrita só é confirmada depois de todas as réplicas no cluster a terem reconhecido.

A replicação entre centros de dados (XDR) pode ser configurada para a sincronização de dados entre diferentes clusters. A convergência de contentores do Aerospike garante que os dados são eventualmente os mesmos em todos os centros de dados no final da replicação. No entanto, as atualizações intermédias podem ser perdidas.

Para a durabilidade, o algoritmo de consistência baseado em listas do Aerospike requer N+1 cópias para processar N falhas.

Modelo de dados

Esta secção compara os modelos de dados usados pelo Bigtable e pelo Aerospike.

Esquema flexível

O Aerospike não aplica restrições de esquema, o que permite que cada registo tenha diferentes contentores com tipos de valores variáveis. Da mesma forma, o Bigtable suporta colunas esparsas, pelo que não é consumido armazenamento para colunas sem valores. Embora não exista um limite rigoroso para o número de colunas ou famílias de colunas, é melhor manter o número de famílias de colunas abaixo de 100 por motivos de desempenho.

Design da chave da linha

O Bigtable identifica as linhas por chaves de linhas, que têm de ser exclusivas numa tabela. São ordenados lexicograficamente e mantidos juntos em comprimidos. Isto difere do Aerospike, onde os registos são distribuídos pelos nós com base no respetivo hash. As chaves de linhas devem ser concebidas para garantir que as linhas acedidas frequentemente em conjunto também são armazenadas em conjunto.

Tipos de dados

O Aerospike suporta tipos de dados avançados, incluindo escalares, GeoJSON, HyperLogLogs, listas e objetos aninhados. Estes tipos podem ser indexados e consultados com o suporte de índices secundários. Além disso, o Aerospike fornece APIs do lado do servidor que permitem operações complexas nestes tipos de dados, como a filtragem por geolocalização ou a manipulação de conteúdos de listas.

A API Bigtable foca-se principalmente no processamento de bytes não processados, com algumas exceções. Também usa nativamente INT64 para datas/horas e contadores que podem ser incrementados como uma operação atómica. A linguagem de consulta também suporta muitos tipos complexos, como escalares, objetos JSON e contentores HLL. Os tipos avançados podem ser cada vez mais suportados no futuro, mas, no momento da redação deste documento, não existe forma de colocar esses tipos no Bigtable. Tudo é serializado no lado do cliente. Pode usar a biblioteca de adaptadores das aerospike-migration-tools para serializar os seus tipos de dados.

Família de colunas

No Bigtable, as famílias de colunas definem que colunas numa tabela são armazenadas e obtidas em conjunto, e tem de existir, pelo menos, uma família de colunas para cada tabela. As colunas relacionadas devem ser agrupadas na mesma família. Os dados com diferentes requisitos de retenção devem ser separados em famílias de colunas distintas, uma vez que as políticas de recolha de lixo se aplicam ao nível da família de colunas.

Qualificadores de colunas

No Bigtable, os qualificadores de colunas são usados numa família de colunas para definir colunas individuais. As tabelas podem suportar milhões de colunas. No entanto, a prática recomendada é limitar o número de colunas numa única linha. Opcionalmente, os qualificadores de colunas podem ser tratados como dados, o que permite incorporar valores diretamente no nome da coluna para poupar espaço.

Células

No Bigtable, uma célula é a interseção da chave da linha e do nome da coluna (uma família de colunas combinada com um qualificador de coluna). Cada célula contém um ou mais valores com data/hora que podem ser fornecidos pelo cliente ou aplicados automaticamente pelo serviço.

Índices secundários

As vistas materializadas contínuas podem funcionar como índices secundários assíncronos, o que permite consultar tabelas através de diferentes padrões de pesquisa ou atributos. Para mais informações, consulte o artigo Crie um índice secundário assíncrono.

Transações

O Bigtable e o Aerospike não suportam transações de várias linhas, mas diferem nas respetivas capacidades de linha única. O Bigtable oferece gravações de linha única totalmente consistentes num cluster e suporta transações de linha única através de pedidos de alteração de linha. Permitem várias operações numa única linha, todas executadas de forma atómica e todas bem-sucedidas ou todas falhadas. Além disso, existem operações de leitura-modificação-escrita e de verificação e mutação, embora não estejam disponíveis com perfis de encaminhamento de vários clusters. Por outro lado, o Aerospike expande as transações de linha única com a manipulação de dados do lado do servidor e a execução de funções definidas pelo cliente.

Balanceamento de carga e comutação por falha

O Aerospike usa o cliente inteligente para processar o equilíbrio de carga no lado do cliente. Um processo executado por parte do cliente que tem conhecimento do estado do cluster e da distribuição de dados. Este cliente é responsável pelo encaminhamento do pedido.

Se um nó falhar ou for adicionado um novo nó, o cluster tem de ser reequilibrado. É escolhido um nó principal temporário para orquestrar o ato de reequilibrar e redistribuir as partições entre os nós. Enquanto isso acontece, o cluster permanece operacional, mas o cliente tem de acompanhar as alterações para o encaminhamento de pedidos. Se um pedido chegar ao nó errado, é encaminhado internamente para o correto.

O cliente do Bigtable é um cliente simples, que oculta todas as complexidades, como o estado do cluster e a distribuição de dados, do utilizador. O encaminhamento do pedido é processado pela camada seguinte, um cliente complexo na infraestrutura do Google CloudBigtable.

Outra diferença é a política de encaminhamento, que não está disponível no Aerospike. O Bigtable usa perfis de aplicações para gerir o encaminhamento de pedidos, com prioridades configuráveis para controlar a ordem em que os pedidos são processados. Existem dois tipos de políticas de encaminhamento: de cluster único e de vários clusters. Um perfil com vários clusters encaminha as operações para o cluster disponível mais próximo. Os clusters na mesma região são considerados equidistantes do ponto de vista do router de operações. Se o nó responsável pelo intervalo de chaves pedido estiver sobrecarregado ou temporariamente indisponível num cluster, este perfil oferece uma comutação por falha automática. Por outro lado, o Aerospike não oferece comutação por falha automática em caso de falha completa do cluster.

Cópia de segurança e restauro

A Aerospike fornece ferramentas externas de cópia de segurança e restauro denominadas asbackup e asrestore que criam cópias de segurança lógicas por parte do cliente e são análogas à execução de uma análise. A gestão de cópias de segurança também pode ser processada através do Aerospike Backup Service ou do Aerospike Kubernetes Operator, que usam asbackup e asrestore internamente e oferecem agendamento e coordenação de vários processos. As cópias de segurança não são atómicas, o que significa que as operações de escrita que ocorrem durante a cópia de segurança podem não ser capturadas.

O Bigtable oferece dois métodos para abranger as necessidades comuns de cópias de segurança: cópias de segurança do Bigtable e exportações de dados geridas. As cópias de segurança criam cópias restauráveis de uma tabela que são armazenadas como objetos membros de um cluster. Pode restaurar cópias de segurança como uma nova tabela no cluster que iniciou a cópia de segurança. As cópias de segurança foram concebidas para criar pontos de restauro se ocorrer corrupção ao nível da aplicação. As cópias de segurança do Bigtable também não são atómicas. As alterações podem ser feitas numa secção da tabela que a cópia de segurança já copiou.

Principais diferenças no processamento de cópias de segurança

  • As cópias de segurança do Aerospike são criadas do lado do cliente. Não requerem espaço adicional do lado do servidor, mas são mais lentos. No Bigtable, uma cópia de segurança partilha o armazenamento físico com a tabela de origem e outras cópias de segurança da tabela.
  • O utilizador do Aerospike tem de processar a exportação, o armazenamento e a remoção de cópias de segurança desatualizadas. Uma vez que as cópias de segurança no Bigtable estão totalmente integradas, todas estas ações são processadas automaticamente pelo serviço Bigtable.

Considerações sobre o desempenho

Uma vez que o Aerospike e o Bigtable tratam as operações de leitura e escrita de forma diferente, têm diferenças de desempenho que é importante considerar. A tabela seguinte inclui vários exemplos de diferenças de desempenho entre as duas bases de dados. Para mais informações, consulte as diretrizes de desempenho do Bigtable.

Ponderação Bigtable Aerospike
Linhas quentes Distribui tablets e operações para igualizar a utilização de recursos. Uma linha acedida com frequência pode ser isolada numa tabela de uma única linha num nó, o que limita o impacto noutras linhas. Distribui linhas com base em hashes por todos os nós, independentemente do tráfego. Uma linha ativa pode afetar o desempenho de uma partição inteira.
Análises sobre chaves ordenadas Armazena dados lexicograficamente, o que o torna altamente eficaz para transmitir dados ordenados. Distribui os registos com base em hashes, pelo que a análise de muitas chaves consecutivas requer a consulta de vários nós e a agregação de resultados, o que pode ser mais lento. Suporta índices secundários, incluindo tipos avançados, o que pode reduzir a necessidade de verificações.
Inserir muitas teclas consecutivas Armazena dados lexicograficamente, o que significa que um único nó processa muitas operações de escrita de chaves consecutivas. Como resultado, um padrão de leitura ou escrita pode acabar no nó que contém o tablet responsável pelo fim do espaço de chaves de linhas, sobrecarregando-o efetivamente. Distribui chaves com base no hash, distribuindo a carga entre vários nós quando escreve chaves consecutivas.
Linhas com um número muito elevado de colunas Embora o Bigtable possa suportar linhas até 256 MB, o processamento de linhas grandes pode afetar o desempenho. O Bigtable está otimizado para linhas mais pequenas. É por isso que a organização das células e o acesso aos dados devem ser considerados durante a conceção do esquema para evitar a propagação de dados por muitas células, se não for necessário. Tem um desempenho abaixo do ideal quando encontra uma linha ou um registo com um número muito grande de colunas ou intervalos.
Inícios a frio Tem o melhor desempenho com tabelas grandes que são acedidas com frequência. Se começar a enviar pedidos após um período sem utilização (início a frio), pode observar uma latência elevada. Isto acontece porque a divisão em tabelas e a respetiva distribuição entre nós podem não ser ideais e porque as caches estão frias. A distribuição entre nós pode não ser totalmente ideal até alguns minutos durante o arranque a frio e durante o reequilíbrio. O desempenho não se altera ao longo do tempo, uma vez que a distribuição de dados não se baseia na carga. Embora as caches precisem de aquecimento, os índices são mantidos na memória, o que minimiza o tempo de pesquisa no disco e reduz a importância do armazenamento em cache.
Muitas mesas pequenas Evite criar muitas tabelas pequenas. As tabelas separadas são justificadas para diferentes exemplos de utilização ou esquemas, mas não para dados semelhantes, uma vez que não melhoram o equilíbrio de carga e aumentam os custos gerais de gestão. A maioria dos registos reside num espaço de nomes, agrupados em conjuntos. Os conjuntos não têm esquemas específicos, mas os índices secundários ou as operações de análise podem ser definidos por conjunto. A divisão dos dados em conjuntos não afeta o desempenho.
Conjunto de dados grande Capaz de armazenar conjuntos de dados à escala de exabytes. O desempenho não é afetado pelo tamanho total do conjunto de dados devido à sua arquitetura e divisão dinâmica de tabelas. Tecnicamente, as bases de dados do Aerospike não têm um limite de tamanho. No entanto, o Aerospike armazena índices e registos separadamente. Ambos os tipos de dados podem ser armazenados em diferentes tipos de dispositivos de armazenamento para aumentar o desempenho. O armazenamento de índices na RAM é essencial para latências baixas, mas pode não ser viável para conjuntos de dados muito grandes. Por exemplo, com 4 mil milhões de objetos e um fator de replicação de 2 (RF2), a memória consumida em associação com o índice principal no cluster em All Flash é de 2,5 GiB. Usando o mesmo exemplo numa configuração de memória híbrida, em que o índice principal está na memória, seriam usados 476,8 GiB de memória.
Dimensionamento O processamento e o armazenamento estão separados e podem ser dimensionados de forma independente. Um único nó pode processar blocos de dados de várias centenas de terabytes ou até petabytes. O armazenamento de índices na RAM é essencial para latências baixas. Nesse caso, as máquinas têm de ser dimensionadas verticalmente juntamente com a capacidade de armazenamento para ter em conta o índice principal.

O que se segue?