Aspectos gerais do Bigtable

O 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 quantidades de dados de chave única com baixa latência. Ele oferece suporte a alta capacidade de processamento de leitura e gravação em baixa latência, além de ser a fonte de dados ideal para operações 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 escalona em proporção direta ao 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 limite. O Bigtable não tem esse gargalo. Portanto, é 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 é mais necessário gerenciar réplicas ou regiões. Basta criar os esquemas de tabela e o Bigtable cuidará do 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 de alterar o tamanho de um cluster, o Bigtable costuma levar alguns minutos sob carga para equilibrar o desempenho em todos os nós 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 uso gerados por medidores de energia e eletrodomé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 uma única chave de linha. As colunas inter-relacionadas, normalmente, são reunidas em um grupo de colunas. Cada coluna é identificada por uma combinação de grupo de colunas e 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 pertence a uma instância do Bigtable, 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 do cluster. Se você ativar a replicação adicionando outros clusters, também será possível enviar diferentes tipos de tráfego para clusters distintos. Em seguida, 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 são armazenadas no registro compartilhado do Colossus assim que reconhecidas pelo Bigtable, proporcionando maior 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 rebalanceamento 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 nó.
  • 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 modo que as linhas com blocos de dados idênticos estejam próximas umas das outras, os dados poderão ser compactados com eficiência.
  • O Bigtable compacta valores com até 1 MiB. Se você armazenar valores maiores que 1 MiB, compacte-os antes de gravá-los no Bigtable. Assim, você economiza ciclos de CPU, memória do servidor e largura de banda da rede.

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. 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.

A durabilidade é aprimorada ainda mais ao usar a replicação. O Bigtable mantém uma cópia separada dos seus dados no local selecionado para cada cluster de uma instância replicada.

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 oferece suporte a restrições de segurança em nível de linha, coluna ou célula.

Criptografia

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.

Se você quiser mais controle sobre as chaves usadas para criptografar os dados do Bigtable em repouso, use chaves de criptografia gerenciadas pelo cliente (CMEK, na sigla em inglês).

Backups

Os backups do Bigtable permitem salvar uma cópia do esquema e dos dados de uma tabela e restaurá-los em uma nova tabela posteriormente. Usando backups, é possível restaurar para uma nova tabela em qualquer região ou projeto em que você tenha uma instância do Bigtable, independentemente de onde a tabela de origem esteja.

Captura de dados alterados

O Bigtable fornece captura de dados alterados (CDC) na forma de fluxos de alterações. Os fluxos de alterações permitem capturar e transmitir alterações de dados para uma tabela à medida que elas acontecem. É possível ler um fluxo de alterações usando um serviço como o Dataflow para dar suporte a casos de uso, incluindo análise de dados, auditorias, requisitos de arquivamento e acionamento de lógica de aplicativo downstream. Para mais informações, consulte a Visão geral do fluxo de alterações.

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.

  • Se for necessário suporte completo ao SQL para um sistema de processamento de transações on-line (OLTP, na sigla em inglês), considere o 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 do documento, com suporte para transações ACID e consultas semelhantes a SQL, considere o Firestore.
  • Para armazenamento de dados na memória com baixa latência, considere usar o Memorystore.
  • Para sincronizar dados entre usuários em tempo real, considere 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