Vista geral do Bigtable

O Bigtable é uma tabela pouco preenchida que pode ser dimensionada para milhares de milhões de linhas e milhares de colunas, o que lhe permite armazenar terabytes ou até petabytes de dados. É indexado um único valor em cada linha. Este valor é conhecido como a chave da linha. O Bigtable é ideal para armazenar grandes quantidades de dados com uma única chave e baixa latência. Suporta um elevado débito de leitura e escrita com baixa latência e é uma origem de dados ideal para operações MapReduce.

O Bigtable é exposto às aplicações através de várias bibliotecas cliente, incluindo uma extensão suportada à biblioteca Apache HBase para Java. Como resultado, integra-se com o ecossistema Apache existente de software de big data de código aberto.

Os servidores de back-end eficientes do Bigtable oferecem várias vantagens importantes em relação a uma instalação do HBase autogerida:

  • Escalabilidade incrível. O Bigtable é dimensionado em proporção direta ao número de máquinas no seu cluster. Uma instalação do HBase autogerida tem um gargalo de estrangulamento de design que limita o desempenho após atingir um determinado limite. O Bigtable não tem este gargalo, pelo que pode dimensionar o cluster para processar mais leituras e escritas.
  • Administração simples. O Bigtable processa as atualizações e os reinícios de forma transparente e mantém automaticamente uma elevada durabilidade dos dados. Para replicar os seus dados, adicione um segundo cluster à sua instância e a replicação é iniciada automaticamente. Não tem de gerir réplicas nem regiões. Basta conceber os esquemas das tabelas e o Bigtable trata do resto.
  • Redimensionamento do cluster sem período de descanso. Pode aumentar o tamanho de um cluster do Bigtable durante algumas horas para processar uma carga grande e, em seguida, reduzir novamente o tamanho do cluster, tudo sem tempo de inatividade. Depois de alterar o tamanho de um cluster, normalmente, o Bigtable demora apenas alguns minutos sob carga a equilibrar o desempenho em todos os nós do cluster.
  • Escala automática. Pode configurar o Bigtable para monitorizar continuamente a capacidade da CPU do cluster e ajustar automaticamente o número de nós num cluster quando necessário.

Para que é útil

O Bigtable é ideal para aplicações que precisam de elevado débito e escalabilidade para dados de chave-valor, em que cada valor não é normalmente superior a 10 MB. O Bigtable também destaca-se como um motor de armazenamento para operações MapReduce em lote, processamento/análise de streams e aplicações de aprendizagem automática.

Pode usar o Bigtable para armazenar e consultar todos os seguintes tipos de dados:

  • Dados de séries cronológicas, como a utilização da CPU e da memória ao longo do tempo para vários servidores.
  • Dados de marketing,como históricos de compras e preferências dos clientes.
  • Dados financeiros, como históricos de transações, preços das ações e taxas de câmbio.
  • Dados da Internet das Coisas,como relatórios de utilização de contadores de energia e eletrodomésticos.
  • Dados de grafos,como informações sobre a forma como os utilizadores estão ligados uns aos outros.

Modelo de armazenamento do Bigtable

O Bigtable armazena dados em tabelas altamente escaláveis, cada uma das quais é um mapa de chave/valor ordenado. A tabela é composta por linhas, cada uma das quais descreve normalmente uma única entidade, e colunas, que contêm valores individuais para cada linha. Cada linha é indexada por uma única chave de linha, e as colunas que estão relacionadas entre si são normalmente agrupadas numa família de colunas. Cada coluna é identificada por uma combinação da família de colunas e um qualificador de coluna, que é um nome único na família de colunas.

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

Diagrama do modelo de armazenamento do Bigtable

Alguns aspetos a ter em atenção nesta ilustração:

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

Arquitetura do Bigtable

O diagrama seguinte mostra uma versão simplificada da arquitetura geral do Bigtable:

Arquitetura geral do Bigtable.

Conforme ilustrado no diagrama, todos os pedidos do cliente passam por um servidor de front-end antes de serem enviados para um nó do Bigtable. (No original artigo sobre o Bigtable, estes nós são denominados "servidores de tabelas".) Os nós estão organizados num cluster do Bigtable, que pertence a uma instância do Bigtable, um contentor para o cluster.

Cada nó no cluster processa um subconjunto dos pedidos para o cluster. Ao adicionar nós a um cluster, pode aumentar o número de pedidos simultâneos que o cluster pode processar. A adição de nós também aumenta o débito máximo do cluster. Se ativar a replicação adicionando clusters adicionais, também pode enviar diferentes tipos de tráfego para diferentes clusters. Em seguida, se um cluster ficar indisponível, pode fazer a comutação por falha para outro cluster.

Uma tabela do Bigtable é dividida em blocos de linhas contíguas, denominados tablets, para ajudar a equilibrar a carga de trabalho das consultas. (As tablets são semelhantes às regiões do HBase.) Os tablets são armazenados no Colossus, o sistema de ficheiros da Google, no formato SSTable. Uma SSTable fornece um mapa imutável persistente e ordenado de chaves para valores, em que as chaves e os valores são strings de bytes arbitrárias. Cada tablet está associado a um nó do Bigtable específico. Além dos ficheiros SSTable, todas as escritas são armazenadas no registo partilhado do Colossus assim que são confirmadas pelo Bigtable, o que aumenta a durabilidade.

É importante referir que os dados nunca são armazenados nos próprios nós do Bigtable; cada nó tem ponteiros para um conjunto de tablets que são armazenados no Colossus. Como resultado:

  • O reequilíbrio de tabelas de um nó para outro ocorre rapidamente, porque 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 apenas os metadados têm de ser migrados para o nó de substituição.
  • Quando um nó do Bigtable falha, não se perdem dados.

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

Balanceamento de carga

Cada zona do Bigtable é gerida por um processo principal, que equilibra a carga de trabalho e o volume de dados nos clusters. Este processo divide os tablets mais ocupados ou maiores ao meio e junta os tablets menos acedidos/mais pequenos, redistribuindo-os entre os nós conforme necessário. Se um determinado tablet receber um pico de tráfego, o Bigtable divide o tablet em dois e, em seguida, move um dos novos tablets para outro nó. O Bigtable gere a divisão, a união e o reequilíbrio automaticamente, o que lhe poupa o esforço de administrar manualmente os seus tablets. O artigo Compreenda o desempenho fornece mais detalhes sobre este processo.

Para conseguir o melhor desempenho de escrita do Bigtable, é importante distribuir as escritas o mais uniformemente possível pelos nós. Uma forma de atingir este objetivo é usar chaves de linhas que não seguem uma ordem previsível. Por exemplo, os nomes de utilizador tendem a ser distribuídos mais ou menos uniformemente ao longo do alfabeto, pelo que a inclusão de um nome de utilizador no início da chave da linha tende a distribuir as escritas uniformemente.

Ao mesmo tempo, é útil agrupar linhas relacionadas para que fiquem lado a lado, o que torna a leitura de várias linhas ao mesmo tempo muito mais eficiente. Por exemplo, se estiver a armazenar diferentes tipos de dados meteorológicos ao longo do tempo, a chave da linha pode ser a localização onde os dados foram recolhidos, seguida de uma data/hora (por exemplo, WashingtonDC#201803061617). Este tipo de chave da linha agruparia todos os dados de uma localização num intervalo contíguo de linhas. Para outras localizações, a linha começaria com um identificador diferente. Com muitas localizações a recolher dados à mesma taxa, as gravações continuariam a ser distribuídas uniformemente pelos tablets.

Consulte o artigo Escolher uma chave de linha para ver mais detalhes sobre como escolher uma chave de linha adequada para os seus dados.

Computação

Por predefinição, o Bigtable usa nós do cluster para armazenamento e computação. Para tarefas de leitura de elevado débito, pode usar o Data Boost para o Bigtable para computação. O Data Boost permite-lhe enviar grandes tarefas de leitura e consultas usando a computação sem servidor enquanto a sua aplicação principal continua a usar nós de cluster para computação. Para mais informações, consulte a vista geral do aumento de dados.

Tipos de dados suportados

O Bigtable trata todos os dados como strings de bytes não processados para a maioria dos fins. O Bigtable só tenta determinar o tipo para operações de incremento, em que o destino tem de ser 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 secções seguintes descrevem como vários componentes do Bigtable afetam a utilização de memória e disco da sua instância.

Colunas não usadas

As colunas que não são usadas numa linha do Bigtable não ocupam espaço nessa linha. Cada linha é essencialmente uma coleção de entradas de chave-valor, em que a chave é uma combinação da família de colunas, do qualificador de coluna e do carimbo de data/hora. Se uma linha não incluir um valor para uma coluna específica, a entrada de valor-chave não está presente.

Qualificadores de colunas

Os qualificadores de colunas ocupam espaço numa linha, uma vez que cada qualificador de coluna usado numa linha é armazenado nessa linha. Como resultado, é frequentemente eficiente usar qualificadores de colunas como dados.

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

Compactações

O Bigtable reescreve periodicamente as suas tabelas para remover entradas eliminadas e reorganizar os seus dados de modo que as leituras e as escritas sejam mais eficientes. Este processo é conhecido como compactação. Não existem definições de configuração para compactações. O Bigtable compacta os seus dados automaticamente.

Mutações e eliminações

As mutações, ou alterações, a uma linha ocupam espaço de armazenamento adicional, porque o Bigtable armazena as mutações sequencialmente e compacta-as apenas periodicamente. Quando o Bigtable compacta uma tabela, remove os valores que já não são necessários. Se atualizar o valor numa célula, o valor original e o novo valor são armazenados no disco durante algum tempo até os dados serem compactados.

As eliminações também ocupam espaço de armazenamento adicional, pelo menos a curto prazo, porque as eliminações são, na verdade, um tipo especializado de mutação. Até a tabela ser compactada, uma eliminação usa armazenamento adicional em vez de libertar espaço.

Compressão de dados

O Bigtable comprime os seus dados automaticamente através de um algoritmo inteligente. Não pode configurar as definições de compressão para a sua tabela. No entanto, é útil saber como armazenar dados para que possam ser comprimidos de forma eficiente:

  • Não é possível comprimir dados aleatórios com a mesma eficiência que dados padronizados. Os dados padronizados incluem texto, como a página que está a ler neste momento.
  • A compressão funciona melhor se os valores idênticos estiverem próximos uns dos outros, quer na mesma linha, quer em linhas adjacentes. Se organizar as chaves das linhas de modo que as linhas com partes de dados idênticas estejam umas ao lado das outras, os dados podem ser comprimidos de forma eficiente.
  • O Bigtable comprime valores com um tamanho máximo de 1 MiB. Se armazenar valores superiores a 1 MiB, comprima-os antes de os escrever no Bigtable para poder poupar ciclos da CPU, memória do servidor e largura de banda da rede.

Durabilidade dos dados

Quando usa o Bigtable, os seus dados são armazenados no Colossus, o sistema de ficheiros interno e altamente duradouro da Google, através de dispositivos de armazenamento nos centros de dados da Google. Não precisa de executar um cluster HDFS nem qualquer outro sistema de ficheiros para usar o Bigtable. Nos bastidores, a Google usa métodos de armazenamento proprietários para alcançar a durabilidade dos dados acima e além do que é fornecido pela replicação tripla padrão do HDFS.

A durabilidade é ainda mais melhorada quando usa a replicação. O Bigtable mantém uma cópia separada dos seus dados na localização que selecionar para cada cluster de uma instância replicada.

Modelo de consistência

As instâncias do Bigtable de cluster único oferecem uma forte consistência. Por predefinição, as instâncias que têm mais do que um cluster oferecem consistência eventual, mas, para alguns exemplos de utilização, podem ser configuradas para oferecer consistência de leitura das suas escritas ou consistência forte, consoante as definições do perfil da app e da carga de trabalho.

Segurança

O acesso às suas tabelas do Bigtable é controlado pelo seu Google Cloud projeto e pelas funções de gestão de identidade e de acesso (IAM) que atribui aos utilizadores. Por exemplo, pode atribuir funções do IAM que impeçam utilizadores individuais de lerem tabelas, escreverem em tabelas ou criarem novas instâncias. Se alguém não tiver acesso ao seu projeto ou não tiver uma função do IAM com as autorizações adequadas para o Bigtable, não pode aceder a nenhuma das suas tabelas.

Também pode controlar o acesso aos dados da tabela criando uma vista autorizada de uma tabela que representa um subconjunto dos dados da tabela. Em seguida, pode conceder autorizações autorizadas ao nível da visualização de propriedade a alguns utilizadores sem lhes conceder autorizações ao nível da tabela.

Pode gerir a segurança ao nível do projeto, da instância, da tabela ou das vistas autorizadas. O Bigtable não suporta restrições de segurança ao nível da linha, da coluna ou da célula.

Encriptação

Por predefinição, todos os dados armazenados no Google Cloud, incluindo os dados nas tabelas do Bigtable, são encriptados em repouso através dos mesmos sistemas de gestão de chaves reforçados que usamos para os nossos próprios dados encriptados.

Se quiser ter mais controlo sobre as chaves usadas para encriptar os seus dados do Bigtable em repouso, pode usar chaves de encriptação geridas pelo cliente (CMEK).

Cópias de segurança

As cópias de segurança do Bigtable permitem-lhe guardar uma cópia do esquema e dos dados de uma tabela e, em seguida, restaurá-los para uma nova tabela mais tarde. Com as cópias de segurança, pode fazer o restauro para uma nova tabela em qualquer região ou projeto onde tenha uma instância do Bigtable, independentemente da localização da tabela de origem.

Alterar captura de dados

O Bigtable fornece a captura de dados de alterações (CDC) sob a forma de streams de alterações. As streams de alterações permitem-lhe capturar e transmitir alterações de dados para uma tabela à medida que ocorrem. Pode ler uma stream de alterações através de um serviço como o Dataflow para suportar exemplos de utilização, incluindo estatísticas de dados, auditorias, requisitos de arquivo e acionamento da lógica de aplicação a jusante. Para mais informações, consulte a Vista geral dos fluxos de alterações.

Encaminhamento de pedidos com perfis de apps

As políticas de encaminhamento do perfil da app permitem-lhe controlar que clusters processam os pedidos recebidos das suas aplicações. As opções para políticas de encaminhamento incluem o seguinte:

  • Encaminhamento de cluster único: envia todos os pedidos para um único cluster.
  • Encaminhamento multicluster para qualquer cluster: envia pedidos para o cluster disponível mais próximo numa instância, incluindo as seguintes opções:
    • Qualquer cluster: qualquer cluster na instância pode receber pedidos.
    • Encaminhamento de grupos de clusters: um grupo especificado de clusters na instância pode receber pedidos.

Outras opções de armazenamento e base de dados

O Bigtable não é uma base de dados relacional tradicional. Embora seja compatível com consultas SQL, determinados exemplos de utilização podem ser mais adequados para outra opção de base de dados.

  • Se precisar de consultas interativas num sistema de processamento analítico online (OLAP), considere o BigQuery.
  • Se tiver de armazenar objetos altamente estruturados numa base de dados de documentos, com suporte para transações ACID e consultas semelhantes a SQL, considere usar o Firestore.
  • Para o armazenamento de dados na memória com baixa latência, considere usar o Memorystore.
  • Para sincronizar dados entre utilizadores em tempo real, considere a Firebase Realtime Database.

Para mais informações sobre outras opções de base de dados, consulte a vista geral dos serviços de base de dados. Google Cloud também tem várias opções de armazenamento.

O que se segue?