Visão geral do Bigtable

Cloud Bigtable é uma tabela preenchida de maneira esparsa que pode ser escalonada para bilhões de linhas e milhares de colunas, permitindo armazenar terabytes, ou até mesmo petabytes, de dados. Um único valor em cada linha é indexado. Esse valor é conhecido como a chave de linha. O Bigtable é ideal para armazenar grandes volumes de dados de chave única com baixa latência. Ele conta com alta capacidade de operações de leitura e gravação em latência baixa, além de ser uma fonte de dados ideal para operações de MapReduce.

O Bigtable é exposto a aplicativos por meio de várias bibliotecas de cliente, inclusive uma extensão compatível para a biblioteca do Apache HBase para Java. Dessa maneira, ela se integra ao ecossistema do Apache existente de software do Big Data de código aberto.

Os potentes servidores back-end eficientes do Bigtable oferecem diversas vantagens importantes em comparação com uma instalação autogerenciada do HBase:

  • Escalabilidade incrível. O Bigtable é escalonado na proporção direta do número de máquinas no cluster. Uma instalação autogerenciada do HBase tem um afunilamento projetado para limitar o desempenho após atingir um determinado patamar. O Bigtable não tem esse afunilamento, então é possível escalonar o cluster para lidar com mais leituras e gravações.
  • Administração simples. O Bigtable processa upgrades e reinicializações de maneira transparente e mantém automaticamente a alta durabilidade de dados. Para replicar os dados, basta adicionar um segundo cluster à instância, e a replicação começa automaticamente. Não se preocupe mais com o gerenciamento de réplicas ou regiões. Basta projetar os esquemas de tabela que o Bigtable processa todo o resto para você.
  • Redimensionamento de cluster sem inatividade. É possível aumentar o tamanho de um cluster do Bigtable por algumas horas para lidar com uma carga grande e reduzir o tamanho do cluster novamente, tudo sem inatividade. Depois que você alterar o tamanho de um cluster, normalmente levará alguns minutos sob carga para o Bigtable equilibrar o desempenho em todos os nodes do cluster.

Indicações de uso

O Bigtable é ideal para aplicativos que precisam de alta capacidade e escalonabilidade para dados de chave/valor, em que cada valor normalmente não é maior que 10 MB. O Bigtable também se destaca como um mecanismo de armazenamento para operações em lote do MapReduce, processamento/análise de stream e aplicativos de machine learning.

Use o Bigtable para armazenar e consultar todos os tipos de dados a seguir:

  • dados de série temporal, como utilização da CPU e da memória ao longo do tempo em vários servidores
  • dados de marketing, como históricos de compras e preferências de clientes
  • dados financeiros, como históricos de transações, cotações de ações e taxas de câmbio
  • dados da Internet das coisas, como relatórios de utilização gerados por medidores de energia e aparelhos domésticos
  • dados do gráfico, como informações sobre como os usuários estão conectados uns aos outros.

Modelo de armazenamento do Bigtable

O Bigtable armazena dados em tabelas altamente escalonáveis, sendo que cada uma é um mapa de chave/valor classificado. A tabela é composta de linhas, que geralmente descrevem uma entidade única e de colunas contendo os valores individuais das linhas. Cada linha é indexada por apenas uma chave de linha e as colunas inter-relacionadas, em geral, são agrupadas em um grupo de colunas. Cada coluna é identificada por uma combinação do grupo de colunas com um qualificador de coluna, que é um nome exclusivo dentro do grupo.

Cada interseção de linha/coluna pode conter várias células. Cada célula contém uma versão exclusiva e com carimbo de data/hora dos dados para essa linha e coluna. O armazenamento de várias células em uma coluna fornece um registro de como os dados armazenados nessa linha e coluna mudaram ao longo do tempo. As tabelas do Bigtable são esparsas. Se uma coluna não for usada em uma linha específica, ela não ocupará espaço.

Diagrama do modelo de armazenamento do Bigtable

Vale observar alguns pontos nessa ilustração:

  • As colunas não podem ser usadas em uma linha.
  • Cada célula de uma determinada linha e coluna tem um carimbo de data/hora exclusivo (t).

Arquitetura do Bigtable

No diagrama a seguir, há uma versão simplificada da arquitetura geral do Bigtable:

Arquitetura geral do Bigtable.

Conforme ilustrado pelo diagrama, todas as solicitações de cliente passam por um servidor front-end antes de ser enviadas para um nó do Bigtable. No documento original do Bigtable, esses nós são chamados de "servidores de blocos". Os nós são organizados em um cluster do Bigtable, que, por sua vez, pertence a uma instância, um contêiner do cluster.

Cada node processa um subgrupo de solicitações realizadas ao cluster. Ao adicionar nós a um cluster, é possível aumentar o número de solicitações simultâneas que ele pode processar. Adicionar nós também aumenta a capacidade máxima de processamento do cluster. Se você ativar a replicação adicionando mais clusters, também poderá enviar tipos diferentes de tráfego para clusters diferentes. Se um cluster ficar indisponível, será possível fazer o failover para outro cluster.

A tabela do Bigtable é fragmentada em conjuntos de linhas contíguas, chamados de blocos. Essa fragmentação ajuda a balancear a carga de trabalho das consultas. Os blocos são semelhantes às regiões do HBase. São armazenados em formato SSTable no Colossus, o sistema de arquivos do Google. Esse formato fornece um mapa permanente, ordenado e imutável das correspondências entre chaves e valores, no qual ambos são strings arbitrárias de bytes. Cada bloco está associado a um nó específico do Bigtable. Além dos arquivos SSTable, todas as gravações também são armazenadas no registro compartilhado do Colossus assim que reconhecidas pelo Bigtable. Isso oferece mais durabilidade.

É importante ressaltar que os dados nunca são armazenados nos nós do Bigtable. Cada node conta com ponteiros para um grupo de blocos armazenados no Colossus. Estes são os resultados:

  • O reequilíbrio de blocos de um nó para outro acontece rapidamente, porque os dados reais não são copiados. O Bigtable simplesmente atualiza os ponteiros de cada node.
  • A recuperação da falha de um nó do Bigtable é rápida, porque apenas os metadados precisam ser migrados para o nó substituto.
  • Não há perda de dados quando um nó do Bigtable falha.

Para mais informações sobre como trabalhar com esses blocos de construção fundamentais, consulte Instâncias, clusters e nós.

Balanceamento de carga

Cada zona do Bigtable é gerenciada por um processo principal que distribui equilibradamente a carga de trabalho e o volume de dados no interior dos clusters. O processo divide ao meio os blocos maiores ou mais acessados e mescla os blocos menores ou menos acessados, fazendo uma redistribuição entre os nós, quando necessário. Se um determinado bloco receber um pico de tráfego, o Bigtable dividirá o bloco em dois e moverá um dos novos blocos para outro nó. O Bigtable gerencia automaticamente a divisão, a mesclagem e o reequilíbrio, eliminando o esforço de administrar seus blocos manualmente. Consulte a seção Entender o desempenho para ver mais detalhes sobre esse processo.

Para ter o melhor desempenho nas operações de gravação com o Bigtable, é importante distribui-las da forma mais uniforme possível por todos os nodes. Uma maneira de fazê-lo é usar chaves de linha que não sigam uma ordem previsível. Por exemplo, nomes de usuário tendem a ser distribuídos mais ou menos por igual pelo alfabeto. Dessa maneira, incluir um nome de usuário no início da chave de linha tenderá a distribuir gravações por igual.

Ao mesmo tempo, é útil agrupar linhas relacionadas. Assim, elas ficam próximas umas das outras, o que aumenta a eficiência na leitura simultânea de várias linhas. Por exemplo, se você estiver armazenando tipos diferentes de dados climáticos ao longo do tempo, a chave de linha provavelmente será o local em que os dados foram coletados seguido de um carimbo de data/hora (como WashingtonDC#201803061617). Esse tipo de chave de linha agruparia todos os dados de um local em um intervalo contíguo de linhas. Para dados de outros locais, a linha iniciaria com um identificador diferente. Com a coleta de dados para vários locais na mesma taxa, as gravações ainda seriam espalhadas de forma uniforme por todos os blocos.

Consulte Como escolher uma chave de linha para saber mais detalhes sobre a escolha da chave de linha adequada para seus dados.

Tipos de dados compatíveis

Na maioria dos casos, o Bigtable trata todos os dados como strings de bytes brutos. O Bigtable tenta determinar o tipo dos dados somente nas operações de incremento com o destino que requer um número inteiro de 64 bits codificado como um valor big-endian de 8 bytes.

Utilização da memória e do disco

As seções a seguir descrevem como vários componentes do Bigtable afetam a utilização da memória e do disco para a instância.

Colunas não utilizadas

As colunas que não são usadas em uma linha do Bigtable não ocupam espaço nela. Basicamente, cada linha é uma coleção de entradas de valor/chave, sendo a chave uma combinação composta por grupo de colunas, qualificador de coluna e carimbo de data/hora. Se uma linha não incluir um valor para uma coluna específica, a entrada de valor/chave simplesmente não existirá.

Qualificadores de coluna

Os qualificadores de coluna ocupam espaço na linha, já que são armazenados na própria linha. Como resultado, geralmente é eficiente usar qualificadores de coluna como dados.

Compactações

Periodicamente, o Bigtable regrava as tabelas para remover entradas excluídas e reorganizar os dados, tornando as leituras e gravações mais eficientes. Esse processo é conhecido como compactação. Não há definições de configuração para as compactações. O Bigtable compacta os dados automaticamente.

Mutações e exclusões

As mutações ou alterações realizadas em uma linha ocupam espaço de armazenamento extra, porque são acumuladas pelo Bigtable em sequência e compactadas somente de tempos em tempos. Quando o Bigtable faz a compactação de uma tabela, ele remove os valores que não são mais necessários. Se você atualizar o valor de uma célula, ambos os valores original e novo serão armazenados em disco por um determinado período, até que os dados sejam compactados.

As exclusões também ocupam espaço de armazenamento extra por um curto prazo, porque, na realidade, são um tipo especializado de mutação. Até que a tabela seja compactada, a exclusão ocupa armazenamento extra, em vez de liberar espaço.

Compactação de dados

O Bigtable usa um algoritmo inteligente para compactar dados automaticamente. Não é possível definir as configurações dessa compactação para a sua tabela. No entanto, para que a compactação seja eficiente, é importante saber como armazenar os dados:

  • Dados aleatórios não são compactados com a mesma eficiência que dados padronizados. Um exemplo de dados padronizados são os textos, como a página que você está lendo neste momento.
  • A compactação funciona melhor quando valores idênticos estão próximos, seja na mesma linha ou em linhas adjacentes. Se você organizar as chaves de linha de forma que porções de dados idênticas estejam próximas, os dados serão compactados com eficiência.
  • Compacte valores maiores que 1 MiB antes de armazená-los no Bigtable. Essa compressão economiza ciclos de CPU, memória do servidor e largura de banda da rede. O Bigtable desativa automaticamente a compactação de valores maiores que 1 MiB.

Durabilidade dos dados

Quando você usa o Bigtable, seus dados são armazenados no Colossus, o sistema de arquivos de alta durabilidade usado internamente pelo Google. O processamento ocorre por meio de dispositivos de armazenamento nos data centers do Google. Não é necessário executar um cluster do HDFS ou outro sistema de arquivos para usar o Bigtable. Se a instância usar replicação, o Bigtable manterá uma cópia dos dados no Colossus para cada cluster na instância. Cada cópia está localizada em uma zona ou região diferente, aumentando ainda mais a durabilidade.

Internamente, o Google usa métodos de armazenamento reservados para que os dados tenham uma durabilidade muito maior do que a oferecida pela replicação tripla do HDFS padrão. Além disso, criamos cópias dos dados para protegê-los de eventos catastróficos e possibilitar a recuperação de desastres.

Modelo de consistência

As instâncias do Bigtable de cluster único oferecem consistência forte. Por padrão, instâncias com mais de um cluster oferecem consistência posterior, mas em alguns casos de uso, elas podem ser configuradas para fornecer consistência de leitura das gravações ou consistência forte, dependendo das configurações de carga de trabalho e do perfil do aplicativo.

Segurança

O acesso a suas tabelas do Bigtable é controlado pelo projeto do Google Cloud e pelos papéis de gerenciamento de identidade e acesso (IAM) que você atribui aos usuários. Por exemplo, você pode atribuir papéis do IAM para evitar que usuários específicos leiam tabelas, gravem tabelas ou criem novas instâncias. Se uma pessoa não tiver acesso ao seu projeto ou não tiver um papel do IAM com as permissões apropriadas para o Bigtable, ela não poderá acessar nenhuma tabela.

Gerencie a segurança nos níveis do projeto, da instância e da tabela. O Bigtable não é compatível com restrições de segurança no nível da linha, da coluna ou da célula.

Encryption

Por padrão, todos os dados armazenados no Google Cloud, incluindo os dados em tabelas do Bigtable, são criptografados em repouso usando os mesmos sistemas de gerenciamento de chaves protegidos que usamos para nossos próprios dados criptografados.

Para ter mais controle sobre as chaves usadas para criptografar os dados do Bigtable em repouso, use as chaves de criptografia gerenciadas pelo cliente (CMEK).

Backups

Com os backups do Bigtable, você pode salvar uma cópia do esquema e dos dados de uma tabela para, depois, restaurá-los em uma tabela a partir do backup. Os backups podem ajudar você a recuperar dados corrompidos no nível do aplicativo ou por erros do operador, como a exclusão acidental de uma tabela.

Solicitar roteamento com perfis de app

As políticas de roteamento do perfil de app permitem controlar quais clusters processam as solicitações recebidas dos seus apps. As opções para políticas de roteamento incluem o seguinte:

  • Roteamento de cluster único: envia todas as solicitações para um único cluster.
  • Roteamento de vários clusters para qualquer cluster: envia solicitações para o cluster disponível mais próximo em uma instância.
  • Roteamento de grupo de clusters: envia solicitações ao cluster disponível mais próximo em um grupo de clusters selecionado em uma instância.

Outras opções de armazenamento e banco de dados

O Bigtable não é um banco de dados relacional. Ele não é compatível com consultas SQL, mesclagens ou transações de várias linhas.

  • Caso precise de compatibilidade total relacionada ao SQL para um sistema de processamento de transações on-line (OLTP, na sigla em inglês), pense em usar o Cloud Spanner ou o Cloud SQL.
  • Se você precisa de consultas interativas em um sistema de processamento analítico online (OLAP, na sigla em inglês), pense em usar o BigQuery.
  • Se você precisa armazenar objetos altamente estruturados em um banco de dados de documentos compatível com transações ACID e consultas semelhantes a SQL, considere o Firestore.
  • Para armazenamento de dados na memória com baixa latência, pense em usar o Memorystore.
  • Para sincronizar dados entre os usuários em tempo real, pense em usar o Firebase Realtime Database.

Para saber mais sobre outras opções de bancos de dados, consulte a visão geral dos serviços de bancos de dados. O Google Cloud também tem várias opções de armazenamento.

A seguir