Aspectos gerais do Bigtable

O Bigtable é uma tabela com pouco preenchimento que pode ser escalonada para bilhões de linhas e milhares de colunas, o que permite 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 uma alta capacidade de processamento de leitura e gravação latência e é uma 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 diretamente proporcional ao número de máquinas no cluster. Um HBase autogerenciado do aplicativo tem um afunilamento de design que limita o desempenho quando um determinado limite é atingido. 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 seus dados, adicione outro 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 de mudar do tamanho de um cluster, ele normalmente leva apenas alguns minutos sob carga para Bigtable para equilibrar o desempenho em todos os nós do no 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, preços de ações e as taxas de câmbio.
  • Dados da Internet das Coisas,como relatórios de utilização 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, e cada uma delas é um mapa de chave-valor ordenado. 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 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 e um qualificador de coluna, que é um nome exclusivo dentro do grupo.

Cada interseção de uma linha e 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 sparse; 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". O nós são organizados em um cluster do Bigtable, que pertence a um Instância do Bigtable, um contêiner para o 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 outros clusters, também podem enviar diferentes tipos de tráfego para clusters distintos. Então, 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 tablet tem associados a um nó específico do Bigtable. Além da seção SSTable, todas as gravações são armazenadas no registro compartilhado do Colossus assim que e são reconhecidos pelo Bigtable, oferecendo 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, os dados reais não são copiados. O Bigtable atualiza os ponteiros de cada nó.
  • A recuperação da falha de um nó do Bigtable é rápida, porque somente 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. Esse processo divide com mais ou menos atividade ao meio e mescla tablets menores/menos acessados, e redistribuindo-as entre nós conforme 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 conseguir isso é usar chaves de linha que não seguem 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 nesta linha. Cada linha é essencialmente uma coleção de entradas de chave-valor, em que a chave é uma combinação do grupo de colunas, do qualificador de coluna e carimbo de data/hora. Se uma linha não incluir um valor para uma coluna específica, o entrada de valor-chave ausente.

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.

Para mais informações sobre qualificadores de coluna, consulte Colunas.

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: na mesma linha ou em linhas adjacentes. Se você organizar as chaves de linha de forma que linhas com porções de dados idênticas estejam próximas, os dados poderão ser compactados com eficiência.
  • O Bigtable compacta valores com até 1 MiB de tamanho. Se você armazenar valores maiores que 1 MiB, compacte-os antes de gravá-los no Bigtable para economizar 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.

Também é possível controlar o acesso aos dados da tabela criando uma visualização autorizada. de uma tabela que representa um subconjunto dos dados da tabela. Em seguida, você pode conceder autorizadas no nível da visualização a alguns usuários sem concedendo a eles permissões em nível de tabela.

É possível gerenciar a segurança no nível do projeto, da instância, da visualizações autorizadas. O Bigtable não oferece suporte restrições de segurança em nível de linha, coluna ou 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 seu dados em repouso do Bigtable, é possível usar a criptografia gerenciada pelo cliente de código aberto (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 a captura de dados alterados (CDC) na forma de mudanças córregos. Os fluxos de alterações permitem capturar e mostrar as alterações de dados em uma tabela à medida que elas acontecem. É possível ler um fluxo de alterações usando um serviço como O Dataflow oferece suporte a casos de uso como análise de dados, auditorias, requisitos de arquivamento e acionamento da lógica de aplicativos 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 mais próximo cluster disponível em uma instância, incluindo as seguintes opções:
    • Qualquer cluster: qualquer cluster na instância pode receber solicitações.
    • Roteamento do grupo de clusters: um grupo especificado de clusters na instância pode receber solicitações.

Outras opções de armazenamento e banco de dados

O Bigtable não é um banco de dados relacional tradicional. Embora isso oferecer suporte a consultas SQL, alguns casos de uso podem ser mais adequado para outra opção de banco de dados.

  • 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, 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 Memorystore.
  • Para sincronizar dados entre usuários em tempo real, considere usar o Firebase Realtime Banco de dados.

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