Bigtable para usuários do DynamoDB

Este documento destina-se a desenvolvedores e bancos de dados do DynamoDB que querem migrar ou criar aplicativos para uso com o Bigtable como repositório de dados. Antes de ler documento, leia a Visão geral do Bigtable.

O Bigtable e o DynamoDB são armazenamentos de chave-valor distribuídos milhões de consultas por segundo (QPS), fornecem armazenamento que escalona verticalmente até petabytes de dados e toleram falhas em nós.

Embora os conjuntos de recursos desses serviços de banco de dados sejam semelhantes, as arquiteturas subjacentes e os detalhes de interação diferem de maneira importante entender antes de iniciar uma migração. Neste documento, destacamos as semelhanças e diferenças entre os dois sistemas de banco de dados.

Plano de controle

No DynamoDB e no Bigtable, o plano de controle permite configurar sua capacidade e configura e gerencia recursos. O DynamoDB é um produto sem servidor e o nível mais alto de interação com o DynamoDB é o nível da tabela. Em modo de capacidade provisionada, em que você provisiona seus arquivos de leitura e solicitar unidades, selecionar regiões e replicação, e gerenciar backups. O Bigtable não é um produto sem servidor. é preciso criar uma instância com um ou mais clusters, cuja capacidade é determinada pelo número de nós que eles têm. Para detalhes sobre esses recursos, consulte Instâncias, clusters e nós.

A tabela a seguir compara os recursos do plano de controle para o DynamoDB e Bigtable.

DynamoDB Bigtable
Tabela : uma coleção de itens com um valor principal definido de dados. As tabelas têm configurações para backups, replicação e capacidade. Instância: um grupo de clusters do Bigtable em diferentes zonas ou regiões do Google Cloud, onde a replicação e o roteamento de conexões. As políticas de replicação são definidas no nível da instância.

Cluster: um grupo de nós na mesma região geográfica Zona do Google Cloud, idealmente coberta com seu aplicativo servidor por motivos de latência e replicação. A capacidade é gerenciada por ajustando o número de nós em cada cluster.

Tabela: uma organização lógica de valores que indexado por chave de linha.

Os backups são controlados no nível da tabela.
Unidade de capacidade de leitura (RCU) e unidade de capacidade de gravação (WCU): Unidades que permitem leituras ou gravações por segundo com ao tamanho do payload. Você é cobrado por unidades de leitura ou gravação com tamanhos de payload maiores.

Operações UpdateItem consomem a capacidade de gravação usada para maior tamanho de um item atualizado, antes ou depois da atualização, mesmo que a atualização envolva um subconjunto dos atributos do item.		 Nó: um recurso de computação virtual responsável por leitura e gravação de dados. o número de nós que um cluster tem se traduz em limites de capacidade para leituras, gravações e verificações. Você pode ajustar o número de nós, dependendo da combinação de suas metas de latência, contagem de solicitações e tamanho do payload.

Os nós SSD oferecem a mesma capacidade para leituras e gravações, ao contrário a diferença significativa entre RCU e WCU. Para mais informações, consulte Desempenho em cargas de trabalho típicas.
Partição: um bloco de linhas contíguas, apoiado por unidades de estado sólido (SSDs) colocadas com nós.

Cada partição está sujeita a um limite absoluto de 1.000 WCUs, 3.000 RCUs, e 10 GB de dados.		 Bloco: um bloco de linhas contíguas apoiadas pelo meio de armazenamento preferido (SSD ou HDD).

As tabelas são fragmentadas em tablets para equilibrar a carga de trabalho. Tablets são que não são armazenadas em nós do Bigtable, distribuído, que permite uma rápida redistribuição dos dados ao escalonar e que fornece durabilidade adicional ao manter várias cópias.
Tabelas globais: uma maneira de aumentar a disponibilidade e durabilidade dos seus dados propagando automaticamente as alterações de dados em várias regiões. Replicação: uma maneira de aumentar a disponibilidade e durabilidade dos seus dados propagando automaticamente as alterações de dados em várias regiões ou zonas dentro da mesma região.
Não relevante (N/A) Perfil de aplicativo: configurações que indicam Bigtable como rotear uma chamada de API do cliente para o cluster apropriado na instância. Também é possível usar um perfil de aplicativo como uma tag para segmentar métricas para atribuição.

Replicação geográfica

A replicação é usada para atender aos requisitos do cliente em:

  • Alta disponibilidade para continuidade dos negócios no caso de uma zona falha regional.
  • Colocar os dados do serviço perto dos usuários finais para com baixa latência onde quer que estejam.
  • Isolamento da carga de trabalho quando é preciso implementar uma carga de trabalho em lote e depender da replicação para disponibilizar clusters.

O Bigtable oferece suporte a clusters replicados em quantas zonas disponíveis em até oito regiões do Google Cloud em que O Bigtable está disponível. A maioria das regiões tem três zonas. O Bigtable replica os dados automaticamente nos clusters em uma topologia multiprimária, o que significa que é possível ler e gravar em qualquer cluster. A replicação do Bigtable tem consistência posterior. Para mais detalhes, consulte as Visão geral da replicação.

O DynamoDB oferece tabelas globais para dar suporte à replicação de tabelas em várias regiões. As tabelas globais são multiprimários e replicar automaticamente entre regiões. A replicação é consistentes eventualmente.

A tabela a seguir lista os conceitos de replicação e descreve a disponibilidade deles no DynamoDB e no Bigtable.

Propriedade DynamoDB Bigtable
Replicação multiprimária Sim.

Você pode ler e gravar em qualquer tabela global.		 Sim.

É possível ler e gravar em qualquer cluster do Bigtable.
Modelo de consistência Consistência posterior.

Consistência na leitura das gravações no nível regional para tabelas.		 Consistência posterior.

Consistência na leitura das gravações no nível do cluster para todos desde que enviem leituras e gravações ao mesmo cluster.
Latência de replicação Sem contrato de nível de serviço (SLA).

Segundos		 Sem SLA.

Segundos
Granularidade de configuração Nível da tabela. Nível da instância.

Uma instância pode conter várias tabelas.
Implementação Criar uma tabela global com uma réplica de tabela em cada uma região.

Nível regional.

Replicação automática entre réplicas convertendo uma tabela em um tabela global.

As tabelas precisam ter o DynamoDB Streams ativado, com o stream que contêm a imagem nova e a antiga do item.

Exclua uma região para remover a tabela global nela.		 Criar uma instância com mais de um cluster.
A replicação é automática nos clusters da instância.

Nível zonal.

Adicionar e remover clusters de um Bigtable instância.
Opções de replicação Por tabela. Por instância.
Roteamento de tráfego e disponibilidade Tráfego roteado para a réplica geográfica mais próxima.

Em caso de falha, você aplica uma lógica de negócios personalizada para determinar e quando redirecionar solicitações para outras regiões.		 Use perfis de aplicativo para configurar políticas de roteamento de tráfego do cluster.

Use o roteamento de vários clusters para rotear o tráfego automaticamente para o cluster íntegro mais próximo.

Em caso de falha, o Bigtable oferece suporte a failover entre clusters para alta disponibilidade.
Escalonamento A capacidade de gravação em unidades de solicitação de gravação replicada (R-WRU, na sigla em inglês) é: são sincronizados entre as réplicas.

A capacidade de leitura em unidades de capacidade de leitura replicadas (R-RCU) é por réplica.		 É possível escalonar clusters de maneira independente adicionando ou removendo nós cada cluster replicado conforme necessário.
Custo Os R-WRUs custam 50% mais do que os WRUs normais. A cobrança é feita pelos nós e pelo armazenamento de cada cluster.
Não há custos de replicação de rede para replicação regional entre zonas.
Os custos são incorridos quando a replicação ocorre entre regiões ou continentes.
SLA 99,999% 99,999%

Plano de dados

A tabela a seguir compara conceitos de modelo de dados para o DynamoDB e o Bigtable. Cada linha da tabela descreve atributos semelhantes. Por exemplo, um item no DynamoDB é semelhante a uma linha no Bigtable.

DynamoDB Bigtable
Item: um grupo de atributos exclusivos. identificável entre todos os outros itens por sua chave primária. Máximo tamanho permitido é 400 KB. Linha: uma única entidade identificada pela chave de linha. O tamanho máximo permitido é de 256 MB.
N/A Grupo de colunas: um namespace especificado pelo usuário que agrupa colunas.
Atributo: um agrupamento de um nome e um valor. Um O valor do atributo pode ser um tipo escalar, de conjunto ou de documento. Não há um limite explícito de tamanho do atributo. No entanto, como cada item é limitado a 400 KB, para um item que só tem um atributo, o pode ter até 400 KB menos o tamanho ocupado pelo nome do atributo. Qualificador de coluna : o identificador exclusivo em uma grupo de colunas de uma coluna. O identificador completo de uma coluna expresso como column-family:column-qualifier. Os qualificadores de coluna são classificado lexicograficamente dentro do grupo de colunas.

O tamanho máximo permitido para um qualificador de coluna é 16 KB.


Célula:uma célula contém os dados de uma determinada linha, coluna, e carimbo de data/hora. Uma célula contém um valor de até 100 MB.
Chave primária: um identificador exclusivo para um item em um tabela. Pode ser uma chave de partição ou uma chave composta.

Chave de partição: uma chave primária simples, composta por um . Isso determina a partição física em que o item está localizado. O tamanho máximo permitido é de 2 KB.

Chave de classificação: uma chave que determina a ordem das linhas. em uma partição. O tamanho máximo permitido é de 1 KB.

Chave composta: uma chave primária composta de duas a chave de partição e um atributo de chave de classificação ou de intervalo.		 Chave de linha : um identificador exclusivo para um item em uma tabela. Normalmente representado por uma concatenação de valores e delimitadores. O tamanho máximo permitido é 4 KB.

Os qualificadores de coluna podem ser usados para fornecer comportamento equivalente à da chave de classificação do DynamoDB.

Chaves compostas podem ser criadas usando linhas concatenadas chaves e qualificadores de coluna.

Para mais detalhes, consulte o exemplo de conversão do esquema na tabela de design deste documento.
Time to live : os carimbos de data/hora por item determinam quando uma não é mais necessário. Após a data e a hora especificadas carimbo de data/hora, o item é excluído da tabela sem consumir e a capacidade de gravação. Coleta de lixo : os carimbos de data/hora por célula determinam quando um item não é mais necessário. As exclusões de coleta de lixo expiraram durante um processo de segundo plano chamado compactação. Lixo de coleta de dados são definidas no nível do grupo de colunas e podem excluir não só com base em sua idade, mas também de acordo com o número de que o usuário quer manter. Você não precisa acomodar capacidade para compactação e dimensionar seus clusters.

Operações

As operações do plano de dados permitem criar, ler, atualizar e excluir (CRUD, na sigla em inglês) ações nos dados de uma tabela. A tabela a seguir compara um plano de dados semelhante para o DynamoDB e o Bigtable.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
O Bigtable trata operações de gravação como upserts.
UpdateItem
  • Gravação condicional
  • Aumento e diminuição
. O Bigtable trata operações de gravação como upserts.
GetItem
BatchGetItem, Query e Scan		 `ReadRow`
`ReadRows` (intervalo, prefixo, verificação reversa)
O Bigtable oferece suporte à verificação eficiente por prefixo de chave de linha, padrão de expressão regular ou intervalochave de linhaa para frente ou para trás.

Tipos de dados

O Bigtable e o DynamoDB não têm esquemas. É possível definir colunas no momento de gravação sem restrições em toda a tabela para existência de colunas ou dados tipos Da mesma forma, uma determinada coluna ou tipo de dados de atributo pode diferir de uma linha ou item a outro. No entanto, as APIs do DynamoDB e do Bigtable com tipos de dados de diferentes maneiras.

Cada solicitação de gravação do DynamoDB inclui uma definição de tipo para cada atributo, que é retornado com a resposta para solicitações de leitura.

O Bigtable trata tudo como bytes e espera que o código do cliente saber o tipo e a codificação para que o cliente possa analisar as respostas corretamente. Uma exceção é incremento operações, que interpretam os valores como números inteiros com sinal big-endian de 64 bits.

A tabela a seguir compara as diferenças nos tipos de dados entre o DynamoDB e o Bigtable.

DynamoDB Bigtable
Tipos escalares : retornados como tipo de dados. descritor na resposta do servidor. Bytes: bytes são transmitidos para os tipos pretendidos no cliente para o aplicativo.

Increment interpreta o valor como Número inteiro com sinal big-endian de 64 bits
Conjunto : uma coleção não classificada de objetos os elementos. Grupo de colunas: é possível usar os qualificadores de coluna conforme definido membros e, para cada um, forneça um único byte zero como a célula . Os membros do conjunto são classificados lexicograficamente dentro de suas colunas família.
Mapa : uma coleção não classificada de pares de chave-valor com chaves exclusivas. Grupo de colunas
Use o qualificador de coluna como chave do mapa e valor da célula para o valor. Chaves do mapa são classificados lexicograficamente.
Lista : é uma coleção classificada de itens. Qualificador de coluna
Use o carimbo de data/hora de inserção para conseguir o equivalente a list_append. comportamento inverso da inserção de carimbo de data/hora para o prefixo.

Design de esquema

Uma consideração importante no design do esquema é como os dados são armazenados. Entre as as principais diferenças entre o Bigtable e o DynamoDB são a forma como eles lidam o seguinte:

  • Atualizações para valores únicos
  • Classificação de dados
  • Controle de versão de dados
  • Armazenamento de grandes valores

Atualizações para valores únicos

As operações UpdateItem no DynamoDB consomem a capacidade de gravação da o "antes" e "depois" de itens de linha, mesmo que a atualização envolva um subconjunto atributos do item. Isso significa que, no DynamoDB, você pode colocar atualizações frequentes colunas em linhas separadas, mesmo que logicamente elas pertençam à mesma linha com outras colunas.

O Bigtable atualiza uma célula com a mesma eficiência, seja ela a única coluna em uma determinada linha ou uma entre muitos milhares. Para mais detalhes, consulte Gravações simples.

Classificação de dados

do DynamoDB e distribui aleatoriamente as chaves de partição, enquanto O Bigtable armazena linhas em ordem lexicográfica por chave de linha e deixa qualquer hash para o usuário.

A distribuição aleatória de chaves não é ideal para todos os padrões de acesso. Ela reduz a risco de intervalos de linhas quentes, mas ele cria padrões de acesso que envolvem verificações entre partições, é caro e ineficiente. Essas verificações ilimitadas são comuns, especialmente para casos de uso que têm uma dimensão de tempo.

Tratamento desse tipo de padrão de acesso: verificações que passam de partições diferentes limites — requer um índice secundário no DynamoDB, mas O Bigtable processa isso sem a necessidade de um índice secundário. Da mesma forma, no DynamoDB, as operações de consulta e verificação são limitadas a 1 MB de dados verificado, exigindo paginação além desse limite. O Bigtable não tem para atingir esse limite.

Apesar das chaves de partição distribuídas aleatoriamente, o DynamoDB ainda pode ter chaves quentes partições diferentes se uma chave de partição escolhida não distribuir de maneira uniforme o tráfego que está afetando negativamente a capacidade de processamento. Para resolver esse problema, o DynamoDB fragmentação de gravação, com a divisão aleatória das gravações em várias partições lógicas chaves-valor.

Para aplicar esse padrão de design, é preciso criar um número aleatório (por exemplo, 1 a 10) e usar esse número como a partição lógica de dados. Como você está randomizando a chave de partição, as gravações na tabela são de maneira uniforme entre todos os valores das chaves de partição.

O Bigtable se refere a esse procedimento como salgar a chave, e pode ser uma maneira eficaz de evitar tablets quentes.

Controle de versão de dados

Cada célula do Bigtable tem um carimbo de data/hora e o mais recente é sempre o valor padrão de qualquer coluna. Um caso de uso comum para carimbos de data/hora é o controle de versão, ou seja, gravando uma nova célula em uma coluna difere das versões anteriores dos dados para aquela linha e coluna por seus carimbo de data/hora.

O DynamoDB não tem esse conceito e exige designs de esquemas complexos para dar suporte ao controle de versões. Essa abordagem envolve a criação de duas cópias de cada item: uma cópia com um prefixo de número de versão igual a zero, como v0_, no início da chave de classificação e outra com um prefixo de número de versão de um, como v1_. Sempre que o item for atualizado, você usará o próximo prefixo de versão mais alto em a chave de classificação da versão atualizada e copiar o conteúdo atualizado no item com o prefixo de versão zero. Isso garante que a versão mais recente de qualquer item possa usando o prefixo zero. Essa estratégia não só exige manter a lógica do lado do aplicativo, mas também torna as gravações de dados muito caras e lento, porque cada gravação requer uma leitura do valor anterior mais dois gravações.

Comparação entre transações de várias linhas e capacidade de linhas grandes

O Bigtable não oferece suporte a transações de várias linhas. No entanto, como permite que você armazene linhas muito maiores do que os itens podem estar DynamoDB, muitas vezes é possível conseguir a transacionalidade pretendida criar esquemas para agrupar itens relevantes em uma chave de linha compartilhada. Para um exemplo que ilustra essa abordagem, consulte Design de tabela única padrão.

Como armazenar valores grandes

Como um item do DynamoDB, análogo a uma linha do Bigtable, é limitado a 400 KB, armazenar grandes valores requer a divisão do valor em itens ou armazenar em outras mídias, como S3: Ambos dessas abordagens aumentam a complexidade do aplicativo. Por outro lado, A célula do Bigtable pode armazenar até 100 MB, e uma podem ter até 256 MB.

Exemplos de conversão de esquema

Os exemplos nesta seção convertem esquemas do DynamoDB para Bigtable pensando nas principais diferenças no design de esquemas.

Como migrar esquemas básicos

Os catálogos de produtos são um bom exemplo para demonstrar o padrão básico de chave-valor. Veja a seguir um esquema desse tipo no DynamoDB.

Chave primária Atributos
Chave de partição Chave de classificação Descrição Preço Miniatura
chapéus fedoras#marcaA Feito com lã premium... 30 https://storage…
chapéus fedoras#marcaB Tela durável resistente à água feita para... 28 https://storage…
chapéus newsboy#brandB Dê um charme vintage ao visual do seu dia a dia. 25 https://storage…
sapatos sneakers#brandA Saia com estilo e conforto com... 40 https://storage…
sapatos sneakers#brandB Elementos clássicos com materiais contemporâneos... 50 https://storage…

Nesta tabela, o mapeamento do DynamoDB para o Bigtable é direto: você converte a chave primária composta do DynamoDB em uma Chave de linha do Bigtable. Você cria um grupo de colunas (SKU) que contém o mesmo conjunto de colunas.

SKU
Chave de linha Descrição Preço Miniatura
hats#fedoras#brandA Feito com lã premium... 30 https://storage…
hats#fedoras#brandB Tela durável resistente à água feita para... 28 https://storage…
hats#newsboy#brandB Dê um charme vintage ao visual do seu dia a dia. 25 https://storage…
sapatos#tênis#marcaA Saia com estilo e conforto com... 40 https://storage…
sapatos#tênis#marcaB Elementos clássicos com materiais contemporâneos... 50 https://storage…

Padrão de design de tabela única

Um único padrão de design de tabela reúne o que seriam várias tabelas em um banco de dados relacional em uma única tabela no DynamoDB. Você pode adotar a abordagem no exemplo anterior e duplique esse esquema como está em Bigtable. No entanto, é melhor resolver os problemas do esquema o processo.

Neste esquema, a chave de partição contém o ID exclusivo de um vídeo, que ajuda a colocar todos os atributos relacionados ao vídeo para um acesso mais rápido. Dado Limitações de tamanho do item do DynamoDB, não é possível colocar um número ilimitado de textos livres comentários em uma única linha. Portanto, uma chave de classificação com o padrão VideoComment#reverse-timestamp é usado para tornar cada comentário uma linha separada. na partição, classificados em ordem cronológica inversa.

Suponha que este vídeo tenha 500 comentários e o proprietário queira remover o vídeo. Isso significa que todos os comentários e atributos de vídeo também precisam ser excluídos. Para fazer isso no DynamoDB, você precisa verificar todas as chaves dentro da partição e em seguida, emitir várias solicitações de exclusão, iterando em cada uma delas. O DynamoDB suporta transações de várias linhas, mas essa solicitação de exclusão é muito grande para ser feita em uma única transação.

Chave primária Atributos
Chave de partição Chave de classificação UploadDate Formatos
0123 Vídeo 2023-09-10T15:21:48 {"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage..."}
Comentário sobre o vídeo#98765481 Conteúdo
Eu gosto muito disso. Os efeitos especiais são incríveis.
Comentário sobre o vídeo#86751345 Conteúdo
Parece que há uma falha de áudio em 1:05.
VideoStatsLikes Count
3
VideoStatsViews Count
156
0124 Vídeo 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
Comentário do vídeo#97531849 Conteúdo
Compartilhei isto com todos os meus amigos.
Comentário sobre o vídeo#87616471 Conteúdo
O estilo me lembra de um diretor de filme, mas não consigo colocar o dedo reimplantá-lo.
VideoStats ViewCount
45

Modifique esse esquema durante a migração para simplificar o código e as solicitações de dados de maneira rápida e econômica. As linhas do Bigtable têm linhas do que os itens do DynamoDB e podem lidar com um grande número de comentários. Para um caso em que um vídeo recebe milhões de comentários, você pode definir um resíduo política de coleta para manter apenas uma o número de comentários mais recentes.

Como os contadores podem ser atualizados sem a sobrecarga de atualizar toda também não será necessário dividi-los. Não é necessário usar uma UploadDate coluna ou calcular um carimbo de data/hora reverso e tornar a chave de classificação porque os carimbos de data/hora do Bigtable mostram comentários ordenados automaticamente. Isso simplifica significativamente o esquema e, se um vídeo é removido, você pode remover a linha do vídeo de forma transacional, incluindo todos os comentários em uma única solicitação.

Por último, como as colunas no Bigtable são ordenadas lexicograficamente, como otimização, é possível renomear as colunas de uma forma que permite uma verificação rápida do intervalo, das propriedades do vídeo às N mais recentes comentários em uma única solicitação de leitura, que é o que você faria quando o vídeo é carregado. Mais tarde, você pode percorrer os outros comentários o usuário rola a tela.

Atributos
Chave de linha Formatos Marcações "Gostei" visualizações UserComments
0123 {"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48 3 156 Eu gosto muito disso. Os efeitos especiais são incríveis. em 2023-09-10T19:01:15
Parece que há uma falha de áudio em 1:05. em 10-09-2023T16:30:42
0124 {"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21 45 O estilo me lembra de um diretor de filme, mas não consigo colocar o dedo reimplantá-lo. @2023-10-12T07:08:51

Padrão de design da lista de adjacente

Considere uma versão um pouco diferente desse design, que o DynamoDB muitas vezes refere-se ao padrão de design da lista de contingências.

Chave primária Atributos
Chave de partição Chave de classificação DateCreated Detalhes
Invoice-0123 Invoice-0123 2023-09-10T15:21:48 {"discount": 0.10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
Payment-0680 2023-09-10T15:21:40 {"amount_usd": 120, "bill_to":"João...",
"address":"123 Abc St..."}
Payment-0789 2023-09-10T15:21:31 {"amount_usd": 120, "bill_to":"Jane...",
"address":"13 Xyz St..."}
Invoice-0124 Invoice-0124 2023-09-09T10:11:28 {"discount": 0.20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
Payment-0327 2023-09-09T10:11:10 {"amount_usd": 180, "bill_to":"Bob...",
"address":"321 Cba St..."}
Payment-0275 2023-09-09T10:11:03 {"amount_usd": 70, "bill_to":"Kate...",
"address":"21 Zyx St..."}

Nesta tabela, as chaves de classificação não são baseadas no horário, mas nos IDs de pagamento. Assim, você pode usar um padrão diferente de colunas largas e separar esses IDs colunas no Bigtable, com benefícios semelhantes aos exemplo.

Fatura Pagamento
chave de linha Detalhes 0680 0789 (link em inglês)
0123 {"discount": 0.10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
em 10-09-2023T15:21:48		 {"amount_usd": 120, "bill_to":"João...",
"address":"123 Abc St..."} @ 2023-09-10T15:21:40		 {"amount_usd": 120, "bill_to":"Jane...",
"address":"13 Xyz St..."}
em 10-09-2023T15:21:31
chave de linha Detalhes 0275 (link em inglês) 0327
0124 {"discount": 0.20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
em 09-09-2023T10:11:28		 {"amount_usd": 70, "bill_to":"Kate...",
"address":"21 Zyx St..."}
em 09-09-2023T10:11:03		 {"amount_usd": 180, "bill_to":"Bob...",
"address":"321 Cba St..."}
em 09-09-2023T10:11:10

Como mostrado nos exemplos anteriores, com o design de esquema correto, O modelo de colunas largas do Bigtable pode ser bastante potente e fornecer muitos casos de uso que exigiriam caras transações de várias linhas, indexação ou exclusão em cascata em outros bancos de dados.

A seguir