Práticas recomendadas de design de esquemas

Esta página contém informações sobre a conceção do esquema do Bigtable. Antes de ler esta página, deve conhecer a vista geral do Bigtable. Esta página aborda os seguintes tópicos:

Conceitos gerais

A conceção de um esquema do Bigtable é diferente da conceção de um esquema para uma base de dados relacional. Um esquema do Bigtable é definido pela lógica da aplicação, em vez de um objeto ou um ficheiro de definição de esquema. Pode adicionar famílias de colunas a uma tabela quando cria ou atualiza a tabela, mas as colunas e os padrões de chaves de linhas são definidos pelos dados que escreve na tabela.

No Bigtable, um esquema é um projeto ou um modelo de uma tabela, incluindo a estrutura dos seguintes componentes da tabela:

  • Chaves de linhas
  • Famílias de colunas, incluindo as respetivas políticas de recolha de lixo
  • Colunas

No Bigtable, a conceção do esquema é determinada principalmente pelas consultas, ou pedidos de leitura, que planeia enviar para a tabela. Uma vez que ler um intervalo de linhas é a forma mais rápida de ler os seus dados do Bigtable, as recomendações nesta página foram concebidas para ajudar a otimizar as leituras de intervalos de linhas. Na maioria dos casos, isto significa enviar uma consulta com base em prefixos de chaves de linhas.

Uma consideração secundária é a evitação de pontos críticos. Para evitar pontos críticos, tem de considerar padrões de escrita e como pode evitar aceder a um pequeno espaço de chaves num curto período de tempo.

Os seguintes conceitos gerais aplicam-se à conceção do esquema do Bigtable:

  • O Bigtable é um armazenamento de chave/valor e não um armazenamento relacional. Não suporta junções e as transações só são suportadas numa única linha.
  • Cada tabela tem um índice: a chave da linha. Cada chave de linha tem de ser exclusiva. Para criar um índice secundário, use uma vista materializada contínua. Para mais informações, consulte o artigo Crie um índice secundário assíncrono.
  • As chaves de linhas ordenam as linhas lexicograficamente da string de bytes mais baixa para a mais alta. Esta ordem é big-endian (por vezes, denominada ordem de bytes de rede), o equivalente binário da ordem alfabética.
  • As famílias de colunas não são armazenadas por nenhuma ordem específica.
  • As colunas são agrupadas por família de colunas e ordenadas por ordem lexicográfica na família de colunas. Por exemplo, numa família de colunas denominada SysMonitor com qualificadores de colunas de ProcessName, User, %CPU, ID, Memory, DiskRead e Priority, o Bigtable armazena as colunas nesta ordem:
SysMonitor
%CPU DiskRead ID Memória Prioridade ProcessName Utilizador
  • A interseção de uma linha e uma coluna pode conter várias células com indicação de data/hora. Cada célula contém uma versão única com data/hora dos dados dessa linha e coluna.
  • As famílias de colunas agregadas contêm células agregadas. Pode criar famílias de colunas que contenham apenas células agregadas. Uma agregação permite-lhe unir novos dados com dados já existentes na célula.
  • Todas as operações são atómicas ao nível da linha. Uma operação afeta uma linha inteira ou nenhuma parte da linha.
  • Idealmente, as leituras e as escritas devem ser distribuídas uniformemente pelo espaço de linhas de uma tabela.
  • As tabelas do Bigtable são esparsas. Uma coluna não ocupa espaço numa linha que não usa a coluna.

Práticas recomendadas

Um bom esquema resulta num excelente desempenho e escalabilidade, e um esquema mal concebido pode levar a um sistema com um desempenho fraco. Cada exemplo de utilização é diferente e requer o seu próprio design, mas as seguintes práticas recomendadas aplicam-se à maioria dos exemplos de utilização. As exceções são indicadas.

Começando ao nível da tabela e avançando para o nível da chave da linha, as secções seguintes descrevem as práticas recomendadas para a conceção do esquema:

Todos os elementos da tabela, especialmente as chaves de linhas, devem ser concebidos tendo em conta os pedidos de leitura planeados. Verifique as quotas e os limites recomendados e os limites de tamanho rígidos para todos os elementos da tabela.

Uma vez que todas as tabelas numa instância são armazenadas nos mesmos tablets, uma estrutura do esquema que resulte em pontos críticos numa tabela pode afetar a latência de outras tabelas na mesma instância. Os pontos ativos são causados pelo acesso frequente a uma parte da tabela num curto período de tempo.

Tabelas

Armazene conjuntos de dados com esquemas semelhantes na mesma tabela, em vez de em tabelas separadas.

Noutros sistemas de base de dados, pode optar por armazenar dados em várias tabelas com base no assunto e no número de colunas. No entanto, no Bigtable, é geralmente melhor armazenar todos os dados numa tabela. Pode atribuir um prefixo de chave de linha exclusivo para usar em cada conjunto de dados, para que o Bigtable armazene os dados relacionados num intervalo contíguo de linhas que pode consultar por prefixo de chave de linha.

O Bigtable tem um limite de 1000 tabelas por instância, mas recomendamos que evite criar um grande número de tabelas pelos seguintes motivos:

  • O envio de pedidos para muitas tabelas diferentes pode aumentar a sobrecarga da ligação de back-end, o que resulta num aumento da latência final.
  • A criação de mais tabelas não melhora o equilíbrio de carga e pode aumentar os custos gerais de gestão.

Pode querer justificadamente uma tabela separada para um exemplo de utilização diferente que exija um esquema diferente, mas não deve usar tabelas separadas para dados semelhantes. Por exemplo, não deve criar uma nova tabela porque é um novo ano ou tem um novo cliente.

Famílias de colunas

Coloque colunas relacionadas na mesma família de colunas. Quando uma linha contém vários valores relacionados entre si, é uma boa prática agrupar as colunas que contêm esses valores na mesma família de colunas. Agrupe os dados o mais próximo possível para evitar ter de criar filtros complexos e para obter apenas as informações de que precisa, mas não mais, nos seus pedidos de leitura mais frequentes.

Crie até cerca de 100 famílias de colunas por tabela. A criação de mais de 100 famílias de colunas pode causar uma degradação do desempenho.

Escolha nomes curtos para as suas famílias de colunas. Os nomes estão incluídos nos dados transferidos para cada pedido.

Coloque colunas com diferentes necessidades de retenção de dados em diferentes famílias de colunas. Esta prática é importante se quiser limitar os custos de armazenamento. As políticas de recolha de lixo são definidas ao nível da família de colunas e não ao nível da coluna. Por exemplo, se só precisar de manter a versão mais recente de um determinado dado, não o armazene numa família de colunas definida para armazenar 1000 versões de outra coisa. Caso contrário, está a pagar para armazenar 999 células de dados de que não precisa.

Colunas

Crie tantas colunas quantas precisar na tabela. As tabelas do Bigtable são esparsas e não existe penalização de espaço para uma coluna que não seja usada numa linha. Pode ter milhões de colunas numa tabela, desde que nenhuma linha exceda o limite máximo de 256 MB por linha.

Evite usar demasiadas colunas numa única linha. Embora uma tabela possa ter milhões de colunas, uma linha não deve ter. Existem alguns fatores que contribuem para esta prática recomendada:

  • O Bigtable demora algum tempo a processar cada célula numa linha.
  • Cada célula adiciona alguma sobrecarga à quantidade de dados armazenados na tabela e enviados através da rede. Por exemplo, se estiver a armazenar 1 KB (1024 bytes) de dados, é muito mais eficiente em termos de espaço armazenar esses dados numa única célula, em vez de distribuir os dados por 1024 células que contêm 1 byte cada.

Se o seu conjunto de dados exigir logicamente mais colunas por linha do que o Bigtable consegue processar de forma eficiente, considere armazenar os dados como um protobuf numa única coluna.

Opcionalmente, pode tratar os qualificadores de colunas como dados. Uma vez que tem de armazenar um qualificador de coluna para cada coluna, pode poupar espaço ao dar um nome à coluna com um valor. Por exemplo, considere uma tabela que armazena dados sobre amizades numa Friendsfamília de colunas. Cada linha representa uma pessoa e todas as suas amizades. Cada qualificador de coluna pode ser o ID de um amigo. Em seguida, o valor de cada coluna nessa linha pode ser o círculo social em que o amigo está. Neste exemplo, as linhas podem ter o seguinte aspeto:

Chave da linha Frederico Gabriel Hiroshi Seo Yoon Jakob
Jose book-club trabalho ténis
Sófia trabalho escola chess-club

Contraste este esquema com um esquema para os mesmos dados que não trata os qualificadores de colunas como dados e, em vez disso, tem as mesmas colunas em todas as linhas:

Chave da linha Amigo Círculo
Jose#1 Frederico book-club
Jose#2 Gabriel trabalho
Jose#3 Hiroshi ténis
Sofia#1 Hiroshi trabalho
Sofia#2 Seo Yoon escola
Sofia#3 Jakob chess-club

O segundo design do esquema faz com que a tabela cresça muito mais rapidamente.

Se estiver a usar qualificadores de colunas para armazenar dados, atribua aos qualificadores de colunas nomes curtos, mas significativos. Esta abordagem permite-lhe reduzir a quantidade de dados transferidos para cada pedido. O tamanho máximo é de 16 KB.

Linhas

Mantenha o tamanho de todos os valores numa única linha abaixo de 100 MB. Certifique-se de que os dados numa única linha não excedem 256 MB. As linhas que excedem este limite podem resultar numa redução do desempenho de leitura.

Mantenha todas as informações de uma entidade numa única linha. Para a maioria dos exemplos de utilização, evite armazenar dados que tem de ler de forma atómica ou tudo de uma vez em mais do que uma linha para evitar inconsistências. Por exemplo, se atualizar duas linhas numa tabela, é possível que uma linha seja atualizada com êxito e a outra atualização falhe. Certifique-se de que o seu esquema não requer a atualização de mais do que uma linha em simultâneo para que os dados relacionados sejam precisos. Esta prática garante que, se parte de um pedido de gravação falhar ou tiver de ser enviado novamente, esse conjunto de dados não fica temporariamente incompleto.

Exceção: se manter uma entidade numa única linha resultar em linhas com centenas de MB, deve dividir os dados em várias linhas.

Armazene entidades relacionadas em linhas adjacentes para tornar as leituras mais eficientes.

Células

Não armazene mais de 10 MB de dados numa única célula. Lembre-se de que uma célula é o dado armazenado para uma determinada linha e coluna com uma data/hora única e que podem ser armazenadas várias células na interseção dessa linha e coluna. O número de células retidas numa coluna é regido pela política de recolha de lixo que define para a família de colunas que contém essa coluna.

Use células agregadas para armazenar e atualizar dados agregados. Se só se preocupar com o valor agregado dos eventos de uma entidade, como a soma mensal das vendas por funcionário numa loja de retalho, pode usar agregações. Para mais informações, consulte o artigo Agregue valores no momento da gravação.

Chaves de linhas

Estruture a chave da linha com base nas consultas que vai usar para obter os dados. As chaves de linhas bem concebidas permitem tirar o máximo partido do Bigtable. As consultas do Bigtable mais eficientes obtêm dados através de um dos seguintes métodos:

  • Chave da linha
  • Prefixo da chave da linha
  • Intervalo de linhas definido pelas chaves de linhas inicial e final

Outros tipos de consultas acionam uma análise completa da tabela, que é muito menos eficiente. Se escolher a chave da linha correta agora, pode evitar um processo de migração de dados difícil mais tarde.

Mantenha as chaves de linhas curtas. Uma chave de linha tem de ter 4 KB ou menos. As chaves de linhas longas ocupam memória e armazenamento adicionais, e aumentam o tempo necessário para receber respostas do servidor do Bigtable.

Armazenar vários valores delimitados em cada chave de linha. Uma vez que a melhor forma de consultar o Bigtable de forma eficiente é através da chave da linha, é frequentemente útil incluir vários identificadores na chave da linha. Quando a chave da linha inclui vários valores, é especialmente importante ter uma compreensão clara de como usa os seus dados.

Os segmentos de chaves de linhas são normalmente separados por um delimitador, como dois pontos, uma barra ou um símbolo de hash. O primeiro segmento ou conjunto de segmentos contíguos é o prefixo da chave da linha e o último segmento ou conjunto de segmentos contíguos é o sufixo da chave da linha.

Exemplo de chave da linha

Os prefixos de chaves de linhas bem planeados permitem-lhe tirar partido da ordem de ordenação incorporada do Bigtable para armazenar dados relacionados em linhas contíguas. Armazenar dados relacionados em linhas contíguas permite-lhe aceder a dados relacionados como um intervalo de linhas, em vez de executar análises de tabelas ineficientes.

Se os seus dados incluírem números inteiros que quer armazenar ou ordenar numericamente, preencha os números inteiros com zeros à esquerda. O Bigtable armazena dados lexicograficamente. Por exemplo, lexicograficamente, 3 > 20, mas 20 > 03. O preenchimento do 3 com um zero inicial garante que os números são ordenados numericamente. Esta tática é importante para as indicações de tempo em que são usadas consultas baseadas em intervalos.

É importante criar uma chave de linha que permita obter um intervalo de linhas bem definido. Caso contrário, a sua consulta requer uma análise da tabela, que é muito mais lenta do que a obtenção de linhas específicas.

Por exemplo, se a sua aplicação monitorizar dados de dispositivos móveis, pode ter uma chave de linha que consista no tipo de dispositivo, no ID do dispositivo e no dia em que os dados são registados. As chaves de linhas para estes dados podem ter o seguinte aspeto:

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

Este design de chave de linha permite-lhe obter dados com um único pedido para:

  • Um tipo de dispositivo
  • Uma combinação do tipo de dispositivo e do ID do dispositivo

Este design de chave de linha não seria ideal se quisesse obter todos os dados de um determinado dia. Uma vez que o dia está armazenado no terceiro segmento ou no sufixo da chave da linha, não pode pedir apenas um intervalo de linhas com base no sufixo ou num segmento intermédio da chave da linha. Em alternativa, tem de enviar um pedido de leitura com um filtro que analise toda a tabela à procura do valor do dia.

Use valores de strings legíveis por humanos nas chaves de linhas sempre que possível. Esta prática facilita a utilização da ferramenta Key Visualizer para resolver problemas com o Bigtable.

Muitas vezes, deve criar chaves de linhas que comecem com um valor comum e terminem com um valor detalhado. Por exemplo, se a chave da linha incluir um continente, um país e uma cidade, pode criar chaves da linha com o seguinte aspeto para que sejam automaticamente ordenadas primeiro por valores com uma cardinalidade mais baixa:

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

Chaves de linhas estruturadas

Se planear consultar a sua tabela através de SQL, pode definir chaves de linhas estruturadas, que lhe permitem aceder aos seus dados do Bigtable através de chaves de várias partes, semelhantes às chaves compostas em bases de dados relacionais. A definição de chaves de linhas estruturadas para uma tabela permite-lhe aceder a segmentos específicos das chaves de linhas através do GoogleSQL para consultas do Bigtable.

As chaves de linhas estruturadas são criadas automaticamente quando cria uma vista materializada contínua. Para implementar chaves de linhas estruturadas para uma tabela do Bigtable, pode criar um esquema de chaves de linhas que defina o tipo de dados e a codificação de cada segmento da chave de linha. O Bigtable armazena as chaves das linhas como bytes ordenados lexicograficamente, e o esquema de chaves das linhas indica ao GoogleSQL para Bigtable como descodificar e interpretar esses bytes.

Os esquemas de chaves de linhas são ignorados quando consulta a tabela através do método ReadRows da API Google Cloud Data com uma biblioteca cliente do Google Cloud Bigtable.

Para mais informações, consulte os artigos Faça a gestão de esquemas de chaves de linhas e Consultas de chaves de linhas estruturadas.

Chaves de linhas a evitar

Alguns tipos de chaves de linhas podem dificultar a consulta dos seus dados e alguns resultam num mau desempenho. Esta secção descreve alguns tipos de chaves de linhas que deve evitar usar no Bigtable.

Chaves de linhas que começam com uma indicação de tempo. Este padrão faz com que as escritas sequenciais sejam enviadas para um único nó, criando um ponto crítico. Se colocar uma data/hora numa chave de linha, preceda-a com um valor de elevada cardinalidade, como um ID do utilizador, para evitar pontos críticos.

Chaves de linhas que fazem com que os dados relacionados não sejam agrupados. Evite chaves de linhas que façam com que os dados relacionados sejam armazenados em intervalos de linhas não contíguos, que são ineficientes para ler em conjunto.

IDs numéricos sequenciais. Suponha que o seu sistema atribui um ID numérico a cada um dos utilizadores da sua aplicação. Pode ser tentador usar o ID numérico do utilizador como a chave da linha para a sua tabela. No entanto, uma vez que os novos utilizadores têm maior probabilidade de serem utilizadores ativos, é provável que esta abordagem direcione a maior parte do seu tráfego para um pequeno número de nós.

Uma abordagem mais segura é usar uma versão invertida do ID numérico do utilizador, que distribui o tráfego de forma mais uniforme por todos os nós da sua tabela do Bigtable.

Identificadores atualizados com frequência. Evite usar uma única chave de linha para identificar um valor que tem de ser atualizado com frequência. Por exemplo, se armazenar dados de utilização de memória para vários dispositivos uma vez por segundo, não use uma única chave de linha para cada dispositivo composta pelo ID do dispositivo e pela métrica que está a ser armazenada, como 4c410523#memusage, e atualize a linha repetidamente. Este tipo de operação sobrecarrega o tablet que armazena a linha usada com frequência. Também pode fazer com que uma linha exceda o respetivo limite de tamanho, uma vez que os valores anteriores de uma coluna ocupam espaço até as células serem removidas durante a recolha de lixo.

Em vez disso, armazene cada nova leitura numa nova linha. Usando o exemplo de utilização de memória, cada chave de linha pode conter o ID do dispositivo, o tipo de métrica e uma data/hora, pelo que as chaves de linha são semelhantes a 4c410523#memusage#1423523569918. Esta estratégia é eficiente porque, no Bigtable, a criação de uma nova linha não demora mais tempo do que a criação de uma nova célula. Além disso, esta estratégia permite-lhe ler rapidamente os dados de um intervalo de datas específico calculando as chaves de início e fim adequadas.

Para valores que mudam com frequência, como um contador que é atualizado centenas de vezes por minuto, é melhor manter os dados na memória, na camada de aplicação, e escrever novas linhas no Bigtable periodicamente.

Valores com hash. A aplicação de hash a uma chave de linha impede que tire partido da ordem de ordenação natural do Bigtable, o que impossibilita o armazenamento de linhas de uma forma otimizada para consultas. Pelo mesmo motivo, a aplicação de hash aos valores torna difícil usar a ferramenta Key Visualizer para resolver problemas com o Bigtable. Use valores legíveis em vez de valores com hash.

Valores expressos como bytes não processados, em vez de strings legíveis. Os bytes não processados são adequados para valores de colunas, mas, para facilitar a leitura e a resolução de problemas, use valores de string nas chaves das linhas.

Exemplos de utilização especiais

Pode ter um conjunto de dados único que requer consideração especial ao criar um esquema para o armazenar no Bigtable. Esta secção descreve alguns, mas não todos, os diferentes tipos de dados do Bigtable e algumas táticas sugeridas para os armazenar da forma mais otimizada.

Dados baseados no tempo

Se aceder frequentemente a dados com base na hora em que foram registados, pode incluir uma data/hora como parte da chave da linha.

Por exemplo, a sua aplicação pode registar dados relacionados com o desempenho, como a utilização da CPU e da memória, uma vez por segundo para muitas máquinas. A chave de linha para estes dados pode combinar um identificador para a máquina com uma data/hora para os dados (por exemplo, machine_4223421#1425330757685). Tenha em atenção que as chaves de linha são ordenadas lexicograficamente.

Se incluir indicações de tempo na chave da linha, não use uma indicação de tempo isoladamente nem no início de uma chave da linha. Este padrão faz com que as escritas sequenciais sejam enviadas para um único nó, criando um ponto crítico.

Se costuma obter os registos mais recentes primeiro nas suas consultas, uma opção a considerar é usar datas/horas invertidas na chave da linha. Este padrão faz com que as linhas sejam ordenadas da mais recente para a menos recente, pelo que os dados mais recentes aparecem mais cedo na tabela. Tal como acontece com qualquer indicação de tempo, evite começar uma chave da linha com uma indicação de tempo invertida para não causar hotspots.

Pode obter uma data/hora invertida subtraindo a data/hora ao valor máximo do seu idioma de programação para números inteiros longos (em Java, java.lang.Long.MAX_VALUE).

Para obter informações específicas sobre como trabalhar com dados de séries cronológicas, consulte o artigo Estrutura de esquemas para dados de séries cronológicas.

Multitenancy

Os prefixos de chaves de linhas oferecem uma solução escalável para um exemplo de utilização de "multi-tenancy", um cenário em que armazena dados semelhantes, usando o mesmo modelo de dados, em nome de vários clientes. A utilização de uma tabela para todos os inquilinos é a forma mais eficiente de armazenar e aceder a dados multi-inquilinos.

Por exemplo, suponhamos que armazena e acompanha os históricos de compras em nome de muitas empresas. Pode usar o ID exclusivo de cada empresa como um prefixo de chave de linha. Todos os dados de um inquilino são armazenados em linhas contíguas na mesma tabela, e pode consultar ou filtrar através do prefixo da chave da linha. Em seguida, quando uma empresa deixa de ser sua cliente e tem de eliminar os dados do histórico de compras que estava a armazenar para a empresa, pode eliminar o intervalo de linhas que usam o prefixo da chave da linha desse cliente.

Por exemplo, se estiver a armazenar dados de dispositivos móveis para clientes altostrat e examplepetstore, pode criar chaves de linhas como as seguintes. Em seguida, se altostrat já não for seu cliente, elimine todas as linhas com o prefixo da chave da linha altostrat.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

Por outro lado, se armazenar dados em nome de cada empresa na respetiva tabela, pode ter problemas de desempenho e escalabilidade. Também é mais provável que atinja inadvertidamente o limite de 1000 tabelas por instância do Bigtable. Depois de uma instância atingir este limite, o Bigtable impede a criação de mais tabelas na instância.

Privacidade

A menos que o seu exemplo de utilização o exija, evite usar informações de identificação pessoal (IIP) ou dados do utilizador em chaves de linhas ou IDs de famílias de colunas. Os valores nas chaves de linhas e nas famílias de colunas são dados de clientes e dados de serviços, e as aplicações que os usam, como a encriptação ou o registo, podem expô-los inadvertidamente a utilizadores que não devem ter acesso a dados privados.

Para mais informações sobre como os dados de serviço são tratados, consulte o Google Cloud Aviso de Privacidade.

Nomes de domínio

Pode armazenar nomes de domínios como dados do Bigtable.

Vasta gama de nomes de domínio

Se estiver a armazenar dados sobre entidades que podem ser representadas como nomes de domínios, considere usar um nome de domínio inverso (por exemplo, com.company.product) como a chave da linha. A utilização de um nome de domínio inverso é uma ideia especialmente boa se os dados de cada linha tenderem a sobrepor-se às linhas adjacentes. Neste caso, o Bigtable pode comprimir os seus dados de forma mais eficiente.

Por outro lado, os nomes de domínio padrão que não são invertidos podem fazer com que as linhas sejam ordenadas de forma que os dados relacionados não sejam agrupados num único local, o que pode resultar numa compressão menos eficiente e leituras menos eficientes.

Esta abordagem funciona melhor quando os seus dados estão distribuídos por muitos nomes de domínio invertidos diferentes.

Para ilustrar este ponto, considere os seguintes nomes de domínio, ordenados automaticamente por ordem lexicográfica pelo Bigtable:

      drive.google.com
      en.wikipedia.org
      maps.google.com

Isto é indesejável para o exemplo de utilização em que quer consultar todas as linhas para o google.com. Em contraste, considere as mesmas linhas em que os nomes dos domínios foram invertidos:

      com.google.drive
      com.google.maps
      org.wikipedia.en

No segundo exemplo, as linhas relacionadas são ordenadas automaticamente de forma a facilitar a respetiva obtenção como um intervalo de linhas.

Poucos nomes de domínio

Se espera armazenar muitos dados apenas para um ou um pequeno número de nomes de domínio, considere outros valores para a chave da linha. Caso contrário, pode enviar gravações para um único nó no cluster, o que resulta em pontos críticos, ou as linhas podem ficar demasiado grandes.

Consultas variáveis ou incertas

Se nem sempre executar as mesmas consultas nos seus dados ou não tiver a certeza de quais serão as suas consultas, uma opção é armazenar todos os dados de uma linha numa coluna em vez de em várias colunas. Com esta abordagem, usa um formato que torna menos difícil extrair os valores individuais mais tarde, como o formato binário protocol buffer ou um ficheiro JSON.

A chave da linha continua a ser cuidadosamente concebida para garantir que pode obter os dados de que precisa, mas cada linha tem normalmente apenas uma coluna que contém todos os dados da linha num único protobuf.

Armazenar dados como uma mensagem protobuf numa coluna em vez de distribuir os dados por várias colunas tem vantagens e desvantagens. As vantagens incluem o seguinte:

  • Os dados ocupam menos espaço, pelo que o custo do armazenamento é inferior.
  • Mantém um certo grau de flexibilidade ao não se comprometer com famílias de colunas e qualificadores de colunas.
  • A sua aplicação de leitura não precisa de "saber" qual é o esquema da tabela.

Seguem-se algumas desvantagens:

  • Tem de desserializar as mensagens protobuf depois de serem lidas do Bigtable.
  • Perde a opção de consultar os dados em mensagens protobuf através de filtros.
  • Não pode usar o BigQuery para executar consultas federadas em campos dentro de mensagens protobuf depois de os ler a partir do Bigtable.

O que se segue?