Este documento ajuda desenvolvedores de software e administradores de banco de dados a migrar aplicativos Aerospike atuais com o Bigtable como um banco de dados. Ele usa seu conhecimento do Aerospike para descrever conceitos que você precisa entender antes de migrar para o Bigtable.
Para ajudar você 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.
- Oferece uma visão geral das operações do Bigtable e descreve o layout dos dados no serviço.
- Explica a modelagem de dados e as principais considerações de design.
- Esclarece como a replicação é realizada e qual é o impacto dela.
Para informações sobre o processo de migração e ferramentas de código aberto que podem ser usadas para concluir a migração, consulte Migrar do Aerospike para o Bigtable.
Comparação de terminologia
O Aerospike e o Bigtable são bancos de dados NoSQL distribuídos, mas diferem significativamente em design, operação e terminologia.
No Aerospike, os dados são armazenados em registros. Cada registro contém um ou mais agrupamentos nomeados, além de metadados como tamanho do registro (em bytes), time to live (TTL) e o último horário de atualização (LUT).
O Bigtable armazena dados em tabelas escalonáveis, sendo que cada uma é um mapa de chave-valor classificado. A tabela é composta de linhas indexadas por chaves de linha e colunas identificadas por um qualificador de coluna. Se relacionadas entre si, as colunas podem formar um grupo de colunas. Essa estrutura permite armazenar várias versões de um valor na mesma chave. Cada versão é identificada por um carimbo de data/hora exclusivo. As versões anteriores podem ser filtradas durante operações de leitura ou removidas por coleta de lixo com base nas políticas configuradas.
Para mais informações, consulte Modelo de armazenamento do Bigtable.
A tabela a seguir descreve e descreve conceitos compartilhados e a terminologia correspondente que cada produto usa:
| Aerospike | Bigtable |
|---|---|
| Nenhum item correspondente direto. | instância: um grupo gerenciado de clusters em diferentes zonas ou regiões de Google Cloud entre as quais ocorrem replicação e roteamento de conexão. |
| cluster: uma implantação do Aerospike que consiste em uma coleção de nós. | cluster: um grupo de nós nas mesmas zonas geográficas Google Cloud . |
| Nó: um servidor que fornece computação e possui armazenamento. | node: um servidor que fornece apenas computação. O armazenamento é processado pelo Colossus, um sistema de arquivos distribuído separado. |
| namespace: armazena parâmetros como TTL ou tipo de armazenamento. Em um namespace, os dados são subdivididos em conjuntos e registros. | table: o equivalente mais próximo a um namespace do Aerospike. Alguns parâmetros são definidos para todas as tabelas no nível do cluster. É possível ter um controle mais refinado no nível da tabela ou do grupo de colunas. |
| set: usado para divisão lógica de registros e parâmetros como TTL e tamanho de limitação. As chaves precisam ser exclusivas em um conjunto. | Nenhum item correspondente direto. |
| Nenhum item correspondente direto. | table: um recurso no nível da instância que é replicado automaticamente para todos os clusters. Uma tabela contém um conjunto de valores identificados por chaves de linha exclusivas. As tabelas são esparsas, o que significa que elas não usam espaço extra para armazenar colunas que não contêm valores. |
| Nenhum item correspondente direto. | tablet: um intervalo contínuo de linhas armazenadas juntas. O Bigtable usa blocos para balanceamento de carga, atribuindo-os a nós. Os limites dos tablets são dinâmicos e podem ser divididos ou mesclados com o tempo. |
| Registro: um conjunto de classes nomeadas usadas para armazenar dados. Ele pode ter no máximo 8 MB. | linha: um conjunto de valores identificados por grupo de colunas, qualificador de coluna e carimbo de data/hora. Todas as operações são atômicas no nível da linha. |
| Nenhum item correspondente direto. | Grupo de colunas: um grupo de colunas classificadas em ordem lexicográfica. A coleta de lixo é definida nesse nível. |
| intervalo: um par de chave-valor em que o nome do intervalo é o identificador de um valor em um registro. | qualificador de coluna: um rótulo para um valor armazenado em uma tabela. |
| Nenhum item correspondente direto. | célula: um rótulo para um valor com carimbo de data/hora armazenado em uma tabela. |
| Digest(registro): um hash de uma tupla de três elementos que identifica um registro: namespace, conjunto e chave. | Nenhum item correspondente direto. |
| key: um identificador de registro exclusivo em um conjunto. | Chave de linha: um identificador de linha exclusivo em uma tabela. |
| AQL:uma ferramenta de linha de comando para navegar pelos dados e desenvolver funções definidas pelo usuário para o banco de dados Aerospike. | GoogleSQL: uma linguagem de consulta usada por vários serviços do Google Cloud , incluindo Spanner, BigQuery e Bigtable. |
Limites de tipos de dados
A tabela a seguir compara os limites dos tipos de dados usados pelo Aerospike e pelo Bigtable:
| Aerospike | Bigtable |
|---|---|
| namespace: o número máximo de namespaces para a Enterprise Edition é 32. | table: uma instância pode ter até 1.000 tabelas. O nome de uma tabela não pode ter mais de 50 caracteres. |
| set: um cluster pode ter até 4.095 conjuntos. O nome de um conjunto não pode exceder 63 bytes. | Nenhum item correspondente direto. |
| registro: o tamanho máximo do registro é de 8 MB. | row: o tamanho máximo da linha é de 256 MB. |
| Nenhum item correspondente direto. | Grupo de colunas: o número de grupos de colunas é ilimitado, mas mais de 100 podem prejudicar o desempenho. |
| bin: o número de agrupamentos é ilimitado, mas cada agrupamento pode conter no máximo 1 MB de dados. O nome do agrupamento não pode ter mais de 15 bytes. | qualificador de coluna: o limite é de 100 MB, mas é recomendável não exceder 10 MB. O número de colunas é ilimitado. |
| key: o tamanho máximo da chave é de 8 KB. | Chave de linha: o tamanho máximo da chave de linha é 4 KB. |
Para mais informações sobre os limites do Bigtable e do Aerospike, consulte Cotas e limites e Limites e thresholds do sistema Aerospike, respectivamente.
Arquitetura
As seções a seguir fornecem uma visão geral da arquitetura do Bigtable e do Aerospike.
Bigtable
Os nós do Bigtable são separados da camada de armazenamento, o que significa que eles não afetam a durabilidade dos dados. Os clientes de tabela do Bigtable não conhecem a distribuição de dados subjacente. Uma camada de roteamento adicional distribui as solicitações para o nó correto. Cada nó processa um subgrupo de solicitações realizadas ao cluster. Uma tabela do Bigtable é fragmentada em blocos de linhas contíguas, chamados de blocos, que são armazenados no Colossus, um sistema de arquivos distribuído que oferece alta durabilidade. Cada bloco está associado a um nó específico do Bigtable.
A arquitetura do Bigtable oferece os seguintes benefícios:
- Os clientes do Bigtable não precisam saber sobre a distribuição de dados e o balanceamento de carga. Essas complexidades são processadas pela camada de roteamento.
- O rebalanceamento acontece muito rapidamente, e a recuperação de falhas é rápida porque os dados reais não são copiados entre os nós.
- Não há perda de dados quando um nó do Bigtable falha.
Aerospike
Ao contrário do Bigtable, o armazenamento do Aerospike está localizado nos nós que o atendem. Todos os nós (servidores) no cluster do Aerospike são idênticos. Os dados em cada namespace são divididos em exatamente 4.096 partições por hash de nomes de registros. Essas partições são distribuídas igualmente entre os nós.
Os nós conhecem uns aos outros e reequilibram as partições armazenadas quando o cluster muda. Cada vez que ocorre uma mudança de cluster, as réplicas escolhem uma réplica principal que coordena o rebalanceamento. As bibliotecas de cliente devem rastrear qual réplica armazena a partição principal e enviar solicitações de gravação para as réplicas corretas. Se um cliente enviar uma solicitação para o nó errado (isso pode acontecer durante o rebalanceamento), ela será redirecionada pelos nós.
Replicação
Nesta seção, comparamos o processo de replicação do Aerospike e do Bigtable.
Bigtable
Uma instância do Bigtable pode consistir em um único cluster ou em vários clusters replicados. Uma tabela é sempre replicada para todos os clusters em uma instância. Os clusters podem ser adicionados ou removidos de uma instância com impacto mínimo em outros clusters.
O Bigtable oferece consistência na leitura das gravações em um único cluster. As gravações são realizadas em um único cluster e se tornam consistentes em outros clusters da instância. Ao contrário do Aerospike, o Bigtable não perde atualizações intermediárias porque as células individuais são versionadas internamente, garantindo que nenhuma gravação seja perdida. Cada cluster exibe as células que têm os carimbos de data/hora mais atuais disponíveis.
A API Bigtable oferece um token de consistência no nível da tabela, que pode ser usado para verificar se todas as mudanças feitas antes da criação do token foram replicadas completamente.
Aerospike
O Aerospike processa a replicação em um cluster no nível da partição. Um namespace é dividido em partições distribuídas igualmente entre os nós. A consistência forte é garantida em um cluster. Uma operação de gravação só é confirmada depois que todas as réplicas no cluster a reconhecem.
A replicação entre data centers (XDR) pode ser configurada para sincronização de dados entre diferentes clusters. A convergência de bins do Aerospike garante que os dados sejam iguais em todos os data centers no final da replicação, mas atualizações intermediárias podem ser perdidas.
Para durabilidade, o algoritmo de consistência baseado em lista do Aerospike exige N+1 cópias para lidar com N falhas.
Modelo de dados
Esta seção compara os modelos de dados usados pelo Bigtable e pelo Aerospike.
Esquema flexível
O Aerospike não impõe restrições de esquema, permitindo que cada registro tenha compartimentos diferentes com tipos de valores variados. Da mesma forma, o Bigtable oferece suporte a colunas esparsas, portanto, nenhum armazenamento é consumido para colunas sem valores. Embora não haja um limite estrito para o número de colunas ou grupos de colunas, é melhor manter o número de grupos abaixo de 100 por motivos de desempenho.
Design de chave de linha
O Bigtable identifica as linhas por chaves de linha, que precisam ser exclusivas em uma tabela. Eles são classificados lexicograficamente e mantidos juntos em tablets. Isso é diferente do Aerospike, em que os registros são distribuídos entre os nós com base no hash deles. As chaves de linha precisam ser projetadas para garantir que as linhas acessadas com frequência juntas também sejam armazenadas juntas.
Tipos de dados
O Aerospike é compatível com tipos de dados avançados, incluindo escalares, GeoJSON, HyperLogLogs, listas e objetos aninhados. Esses tipos podem ser indexados e consultados com suporte de índices secundários. Além disso, o Aerospike oferece APIs do lado do servidor que permitem operações complexas nesses tipos de dados, como filtragem por geolocalização ou manipulação do conteúdo da lista.
A API Bigtable se concentra principalmente no processamento de bytes brutos, com algumas exceções. Ele também usa INT64 de forma nativa para carimbos de data/hora e contadores que podem ser incrementados como uma operação atômica. A linguagem de consulta também é compatível com muitos tipos complexos, como escalares, objetos JSON e agrupamentos HLL. Os tipos avançados podem ser cada vez mais aceitos no futuro, mas, no momento em que este documento foi escrito, não há como colocar esses tipos no Bigtable. Tudo é serializado no lado do cliente. Use a biblioteca de adaptadores das ferramentas aerospike-migration-tools para serializar seus tipos de dados.
Grupo de colunas
No Bigtable, os grupos de colunas definem quais colunas em uma tabela são armazenadas e recuperadas juntas, e cada tabela precisa ter pelo menos um grupo de colunas. Colunas relacionadas precisam ser agrupadas na mesma família. Dados com requisitos de retenção diferentes precisam ser separados em grupos de colunas distintos, já que as políticas de coleta de lixo são aplicadas no nível do grupo de colunas.
Qualificadores de coluna
No Bigtable, os qualificadores de coluna são usados em um grupo de colunas para definir colunas individuais. As tabelas podem ter milhões de colunas, mas a prática recomendada é limitar o número de colunas em uma única linha. Opcionalmente, os qualificadores de coluna podem ser tratados como dados, permitindo que os valores sejam incorporados diretamente no nome da coluna para economizar espaço.
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.
Índices secundários
As visualizações materializadas contínuas podem funcionar como índices secundários assíncronos, permitindo que as tabelas sejam consultadas usando diferentes padrões de pesquisa ou atributos. Para mais informações, consulte Criar um índice secundário assíncrono.
Transações
O Bigtable e o Aerospike não oferecem suporte a transações de várias linhas, mas diferem nos recursos de linha única. O Bigtable oferece gravações de linha única totalmente consistentes em um cluster e é compatível com transações de linha única por solicitações de mutação de linha. Elas permitem várias operações em uma única linha, todas executadas de forma atômica e com sucesso ou falha. Além disso, há operações de leitura/modificação/gravação e verificação e mutação, mas elas não estão disponíveis com perfis de roteamento de vários clusters. Em contraste, o Aerospike estende as transações de linha única com manipulação de dados do lado do servidor e execução de funções definidas pelo cliente.
Balanceamento de carga e failover
O Aerospike usa o Smart Client para processar o balanceamento de carga no lado do cliente. Um processo em execução no lado do cliente que conhece o estado do cluster e a distribuição de dados. Esse cliente é responsável por encaminhar a solicitação.
Se um nó falhar ou um novo nó for adicionado, o cluster precisará ser rebalanceado. Um nó principal temporário é escolhido para orquestrar o ato de rebalancear e redistribuir as partições entre os nós. Enquanto isso acontece, o cluster permanece operacional, mas o cliente precisa rastrear as mudanças para o roteamento de solicitações. Se uma solicitação chegar ao nó errado, ela será roteada internamente para o correto.
O cliente do Bigtable é um cliente thin, que oculta todas as complexidades, como estado do cluster e distribuição de dados, do usuário. O roteamento da solicitação é processado pela próxima camada, um cliente avançado na infraestrutura do Bigtable Google Cloud.
Outra diferença é a política de roteamento, que não está disponível no Aerospike. O Bigtable usa perfis de aplicativo para gerenciar o roteamento de solicitações, com prioridades configuráveis para controlar a ordem em que as solicitações são atendidas. Há dois tipos de políticas de roteamento: 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 perfil vai oferecer failover automático. Por outro lado, o Aerospike não oferece failover automático em caso de falha completa do cluster.
Backup e restauração
O Aerospike oferece ferramentas externas de backup e restauração chamadas asbackup e asrestore, que criam backups lógicos do lado do cliente e são análogas à execução de uma verificação. O gerenciamento de backup também pode ser feito pelo serviço de backup do Aerospike ou pelo operador do Aerospike Kubernetes, que usam asbackup e asrestore internamente e oferecem programação e coordenação de vários processos. Os backups não são atômicos, ou seja, as operações de gravação que ocorrem durante o backup podem não ser capturadas.
O Bigtable oferece dois métodos para abranger necessidades comuns de backup: backups do Bigtable e exportações de dados gerenciadas. Os backups 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 do Bigtable também não são atômicos. As mudanças podem ser feitas em uma seção da tabela que o backup já copiou.
Principais diferenças no tratamento de backups
- Os backups do Aerospike são criados do lado do cliente. Eles não exigem espaço adicional no lado do servidor, mas são mais lentos. No Bigtable, um backup compartilha o armazenamento físico com a tabela de origem e outros backups da tabela.
- O usuário do Aerospike precisa lidar com a exportação, o armazenamento e a remoção de backups desatualizados. Como os backups no Bigtable são totalmente integrados, todas essas ações são realizadas automaticamente pelo serviço do Bigtable.
Considerações sobre desempenho
Como o Aerospike e o Bigtable tratam as operações de leitura e gravação de maneira diferente, eles têm diferenças de desempenho que são importantes considerar. A tabela a seguir inclui vários exemplos de diferenças de desempenho entre os dois bancos de dados. Para mais informações, consulte as diretrizes de desempenho do Bigtable.
| Consideração | Bigtable | Aerospike |
|---|---|---|
| Linhas quentes | Distribui tablets e operações para igualar o uso de recursos. Uma linha acessada com frequência pode ser isolada em um bloco de linha única em um nó, limitando o impacto em outras linhas. | Distribui linhas com base em hashes em todos os nós, independente do tráfego. Uma linha ativa pode afetar a performance de uma partição inteira. |
| Verificações em chaves classificadas | Armazena dados lexicograficamente, o que o torna altamente eficaz para streaming de dados classificados. | Distribui registros com base em hashes. Portanto, a verificação de muitas chaves consecutivas exige a consulta de vários nós e a agregação de resultados, o que pode ser mais lento. Oferece suporte a índices secundários, incluindo tipos avançados, o que pode reduzir a necessidade de verificações. |
| Inserir muitas chaves consecutivas | Armazena dados lexicograficamente, ou seja, um único nó processa muitas operações consecutivas de gravação de chaves. Como resultado, um padrão de leitura ou gravação pode acabar no nó que contém o tablet responsável pelo final do espaço da chave de linha, sobrecarregando-o. | Distribui chaves com base no hash, distribuindo a carga entre vários nós ao gravar chaves consecutivas. |
| Linhas com um grande número de colunas | Embora o Bigtable possa aceitar linhas de até 256 MB, o processamento de linhas grandes pode afetar o desempenho. O Bigtable é otimizado para linhas menores. Por isso, a organização de células e o acesso aos dados precisam ser considerados durante o design do esquema para evitar a distribuição de dados em muitas células, se não for necessário. | Tem desempenho abaixo do ideal ao encontrar uma linha ou um registro com um grande número de colunas ou agrupamentos. |
| Inicializações a frio | Tem um desempenho melhor com tabelas grandes que são acessadas com frequência. Se você começar a enviar solicitações após um período sem uso (uma inicialização a frio), poderá observar alta latência. Isso acontece porque a divisão em tablets e a distribuição deles entre os nós podem não ser ideais e porque os caches estão vazios. A distribuição entre os nós pode não ser totalmente ideal até alguns minutos durante a inicialização a frio e o rebalanceamento. | O desempenho não muda com o tempo porque a distribuição de dados não é baseada em carga. Enquanto os caches precisam de aquecimento, os índices são mantidos na memória, minimizando o tempo de pesquisa em disco e reduzindo a importância do cache. |
| Muitas tabelas pequenas | Evite criar muitas tabelas pequenas. Tabelas separadas são justificadas para diferentes casos de uso ou esquemas, mas não para dados semelhantes, já que isso não melhora o balanceamento de carga e aumenta a sobrecarga de gerenciamento. | A maioria dos registros reside em um namespace, agrupados em conjuntos. Os conjuntos não têm esquemas específicos, mas os índices secundários ou as operações de verificação podem ser definidos por conjunto. Dividir os dados em conjuntos não afeta a performance. |
| Conjunto de dados grande | Capaz de armazenar conjuntos de dados de exabytes. O desempenho não é afetado pelo tamanho total do conjunto de dados devido à arquitetura e à divisão dinâmica de tabelas. | Tecnicamente, os bancos de dados do Aerospike não têm um limite de tamanho, mas armazenam índices e registros separadamente. Os dois tipos de dados podem ser armazenados em diferentes tipos de dispositivos de armazenamento para aumentar o desempenho. Armazenar índices na RAM é essencial para baixa latência, mas pode não ser viável para conjuntos de dados muito grandes. Por exemplo, com 4 bilhõ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 em uma configuração de memória híbrida, em que o índice principal está na memória, seriam usados 476,8 GiB de memória. |
| Escalonamento | O processamento e o armazenamento são desacoplados e podem ser escalonados de forma independente. Um único nó pode processar blocos de dados de várias centenas de terabytes ou até petabytes. | Armazenar índices na RAM é essencial para baixa latência. Nesse caso, as máquinas precisam ser escalonadas verticalmente junto com a capacidade de armazenamento para considerar o índice principal. |
A seguir
- Leia sobre o design do esquema do Bigtable.
- Saiba mais sobre o Aerospike.
- Saiba mais sobre o emulador do Bigtable.
- Confira arquiteturas de referência, diagramas e práticas recomendadas do Google Cloud. Confira o Centro de arquitetura do Cloud.