Migre do DynamoDB para o Bigtable

O Bigtable e o DynamoDB são armazenamentos de chave-valor distribuídos que podem suportar milhões de consultas por segundo (CPS), oferecer armazenamento que é dimensionado até petabytes de dados e tolerar falhas de nós.

Este documento destina-se a programadores do DynamoDB e administradores de bases de dados que pretendem migrar para o Bigtable. Também é útil quando quer criar aplicações para utilização com o Bigtable como um repositório de dados.

Para começar, use uma ferramenta de migração fornecida pela Google que lhe permite migrar do DynamoDB para o Bigtable. Esta página descreve a ferramenta de migração, compara os dois sistemas de base de dados e descreve a arquitetura subjacente e os detalhes de interação que diferem e que são importantes compreender antes da migração.

Comece a usar a ferramenta de migração do DynamoDB para o Bigtable

A Google Cloud Professional Services disponibiliza uma ferramenta de migração de código aberto para simplificar a migração de dados do DynamoDB para o Bigtable. A ferramenta automatiza o processo de importação dos seus dados para o Google Cloud e, em seguida, carrega-os para o Bigtable.

Com a ferramenta, exporta a sua tabela do DynamoDB e, em seguida, transfere-a para o Cloud Storage. A ferramenta lê os ficheiros exportados do seu contentor do Cloud Storage e usa um modelo do Dataflow para transformar os dados de modo a serem compatíveis com o Bigtable. Esta transformação inclui o mapeamento de atributos do DynamoDB para linhas do Bigtable. Em seguida, a tarefa do Dataflow escreve os dados transformados na sua tabela do Bigtable.

Para mais informações ou para começar, consulte o artigo Utilitário de migração do DynamoDB para o Bigtable.

Comparação entre o DynamoDB e o Bigtable

Esta secção examina as semelhanças e as diferenças entre o DynamoDB e o Bigtable.

Plano de controlo

No DynamoDB e no Bigtable, o plano de controlo permite-lhe configurar a capacidade e configurar e gerir recursos. O DynamoDB é um produto sem servidor e o nível mais elevado de interação com o DynamoDB é o nível da tabela. No modo de capacidade aprovisionada, é aqui que aprovisiona as unidades de pedido de leitura e escrita, seleciona as regiões e a replicação, e gere as cópias de segurança. O Bigtable não é um produto sem servidor. Tem de criar uma instância com um ou mais clusters, cuja capacidade é determinada pelo número de nós que têm. Para ver detalhes sobre estes recursos, consulte o artigo Instâncias, clusters e nós.

A tabela seguinte compara os recursos do plano de controlo do DynamoDB e do Bigtable.

DynamoDB	Bigtable
Tabela: uma coleção de itens com uma chave principal definida. As tabelas têm definições para cópias de segurança, replicação e capacidade.	Instância: um grupo de clusters do Bigtable em diferentes Google Cloud zonas ou regiões, entre os quais ocorre a replicação e o encaminhamento de ligações. As políticas de replicação são definidas ao nível da instância. Cluster: um grupo de nós na mesma zona geográfica, idealmente colocados com o servidor da sua aplicação por motivos de latência e replicação.Google Cloud A capacidade é gerida através do ajuste do número de nós em cada cluster. Tabela: uma organização lógica de valores indexados pela chave da linha. As cópias de segurança são controladas ao nível da tabela.
Unidade de capacidade de leitura (RCU) e unidade de capacidade de escrita (WCU): unidades que permitem leituras ou escritas por segundo com um tamanho de carga útil fixo. São-lhe cobradas unidades de leitura ou escrita por cada operação com tamanhos de carga útil maiores. As operações UpdateItem consomem a capacidade de escrita usada para o tamanho máximo 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 ler e escrever dados. O número de nós que um cluster tem traduz-se em limites de débito para leituras, escritas e análises. Pode ajustar o número de nós, consoante a combinação dos seus objetivos de latência, contagem de pedidos e tamanho da carga útil. Os nós SSD oferecem o mesmo débito para leituras e escritas, ao contrário da diferença significativa entre RCU e WCU. Para mais informações, consulte o artigo Desempenho para cargas de trabalho típicas.
Partição: um bloco de linhas contíguas, suportado por unidades de estado sólido (SSDs) localizadas com nós. Cada partição está sujeita a um limite rígido de 1000 WCUs, 3000 RCUs e 10 GB de dados.	Tabela: um bloco de linhas contíguas suportado pelo meio de armazenamento à sua escolha (SSD ou HDD). As tabelas são divididas em fragmentos para equilibrar a carga de trabalho. As tabelas não são armazenadas em nós no Bigtable, mas sim no sistema de ficheiros distribuído da Google, o que permite uma redistribuição rápida dos dados ao dimensionar e oferece uma durabilidade adicional através da manutenção de várias cópias.
Tabelas globais: uma forma de aumentar a disponibilidade e a durabilidade dos seus dados propagando automaticamente as alterações de dados em várias regiões.	Replicação: uma forma de aumentar a disponibilidade e a durabilidade dos seus dados propagando automaticamente as alterações de dados em várias regiões ou várias zonas na mesma região.
Não aplicável (N/A)	Perfil da aplicação: definições que indicam ao Bigtable como encaminhar uma chamada API do cliente para o cluster adequado na instância. Também pode usar um perfil de app como uma etiqueta para segmentar métricas para atribuição.

Replicação geográfica

A replicação é usada para dar resposta aos requisitos dos clientes para o seguinte:

• Elevada disponibilidade para a continuidade do negócio em caso de falha zonal ou regional.
• Colocar os dados do seu serviço perto dos utilizadores finais para uma publicação de baixa latência, onde quer que estejam no mundo.
• Isolamento da carga de trabalho quando precisa de implementar uma carga de trabalho em lote num cluster e depender da replicação para clusters de serviço.

O Bigtable suporta clusters replicados em tantas zonas quantas estiverem disponíveis em até 8 Google Cloud regiões onde o Bigtable está disponível. A maioria das regiões tem três zonas. Para mais informações, consulte o artigo Regiões e zonas.

O Bigtable replica automaticamente os dados em clusters numa topologia de vários nós principais, o que significa que pode ler e escrever em qualquer cluster. A replicação do Bigtable acaba por ser consistente. Para ver detalhes, consulte a Vista geral da replicação.

O DynamoDB fornece tabelas globais para suportar a replicação de tabelas em várias regiões. As tabelas globais são multi-primárias e replicam-se automaticamente entre regiões. A replicação acaba por ser consistente.

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

Propriedade	DynamoDB	Bigtable
Replicação multiprimária	Sim. Pode ler e escrever em qualquer tabela global.	Sim. Pode ler e escrever em qualquer cluster do Bigtable.
Modelo de consistência	Eventualmente consistente. Consistência de leitura das suas próprias escritas ao nível regional para tabelas globais.	Eventualmente consistente. Consistência de leitura das suas escritas ao nível do cluster para todas as tabelas, desde que envie leituras e escritas para o mesmo cluster.
Latência de replicação	Não existe contrato de nível de serviço (SLA). segundos	Sem SLA. segundos
Nível de detalhe da configuração	Nível da tabela.	Nível da instância. Uma instância pode conter várias tabelas.
Implementação	Crie uma tabela global com uma réplica da tabela em cada região selecionada. Nível regional. Replicação automática em todas as réplicas através da conversão de uma tabela numa tabela global. As tabelas têm de ter o DynamoDB Streams ativado, com a stream a conter as imagens novas e antigas do artigo. Elimine uma região para remover a tabela global nessa região.	Crie uma instância com mais de um cluster. A replicação é automática em todos os clusters nessa instância. Nível zonal. Adicione e remova clusters de uma instância do Bigtable.
Opções de replicação	Por tabela.	Por instância.
Encaminhamento e disponibilidade do tráfego	Tráfego encaminhado para a réplica geográfica mais próxima. Em caso de falha, aplica uma lógica de negócio personalizada para determinar quando redirecionar pedidos para outras regiões.	Use perfis de aplicações para configurar políticas de encaminhamento de tráfego de clusters. Use o encaminhamento de vários clusters para encaminhar automaticamente o tráfego para o cluster em bom estado mais próximo. Em caso de falha, o Bigtable suporta a comutação por falha automática entre clusters para HA.
Dimensionamento	A capacidade de escrita em unidades de pedido de escrita replicadas (R-WRU) é sincronizada entre réplicas. A capacidade de leitura em unidades de capacidade de leitura replicadas (R-RCU) é por réplica.	Pode dimensionar clusters de forma independente adicionando ou removendo nós de cada cluster replicado conforme necessário.
Custo	As WRUs de reserva custam 50% mais do que as WRUs normais.	A faturação é feita pelos nós e pelo armazenamento de cada cluster. Não existem custos de replicação de rede para a replicação regional em várias zonas. Os custos são incorridos quando a replicação é feita entre regiões ou continentes.
SLA	99,999%	99,999%

Plano de dados

A tabela seguinte compara os conceitos do modelo de dados para o DynamoDB e o Bigtable. Cada linha na tabela descreve funcionalidades análogas. Por exemplo, um item no DynamoDB é semelhante a uma linha no Bigtable.

DynamoDB	Bigtable
Item: um grupo de atributos que é identificável de forma exclusiva entre todos os outros itens pela respetiva chave principal. O tamanho máximo permitido é de 400 KB.	Linha: uma única entidade identificada pela chave da linha. O tamanho máximo permitido é de 256 MB.
N/A	Família de colunas: um espaço de nomes especificado pelo utilizador que agrupa colunas.
Atributo: uma agrupamento de um nome e um valor. Um valor de atributo pode ser um tipo escalar, definido ou de documento. Não existe um limite explícito no tamanho do atributo em si. No entanto, uma vez que cada item está limitado a 400 KB, para um item que só tenha um atributo, o atributo pode ter até 400 KB menos o tamanho ocupado pelo nome do atributo.	Qualificador de coluna: o identificador exclusivo numa família de colunas para uma coluna. O identificador completo de uma coluna é expresso como família-de-colunas:qualificador-de-colunas. Os qualificadores de colunas são ordenados lexicograficamente na família de colunas. O tamanho máximo permitido para um qualificador de coluna é de 16 KB. Célula: uma célula contém os dados de uma determinada linha, coluna e data/hora. Uma célula contém um valor que pode ter até 100 MB.
Chave primária: um identificador exclusivo de um artigo numa tabela. Pode ser uma chave de partição ou uma chave composta. Chave de partição: uma chave principal simples, composta por um atributo. Isto determina a partição física onde o artigo está localizado. O tamanho máximo permitido é de 2 KB. Chave de ordenação: uma chave que determina a ordem das linhas numa partição. O tamanho máximo permitido é de 1 KB. Chave composta: uma chave principal composta por duas propriedades, a chave de partição e uma chave de ordenação ou um atributo de intervalo.	Chave da linha: um identificador exclusivo de um item numa tabela. Normalmente, é representado por uma concatenação de valores e delimitadores. O tamanho máximo permitido é de 4 KB. Os qualificadores de colunas podem ser usados para fornecer um comportamento equivalente ao da chave de ordenação do DynamoDB. As chaves compostas podem ser criadas usando chaves de linhas concatenadas e qualificadores de colunas. Para mais detalhes, consulte o exemplo de tradução de esquemas na secção de design de esquemas deste documento.
Tempo de vida: as datas/horas de cada artigo determinam quando um artigo deixa de ser necessário. Após a data e a hora da data/hora especificada, o item é eliminado da sua tabela sem consumir qualquer débito de gravação.	Recolha de lixo: as datas/horas de cada célula determinam quando um item já não é necessário. A recolha de lixo elimina itens expirados durante um processo em segundo plano denominado compactação. As políticas de recolha de lixo são definidas ao nível da família de colunas e podem eliminar itens não só com base na respetiva antiguidade, mas também de acordo com o número de versões que o utilizador quer manter. Não precisa de ter em conta a capacidade de compactação ao dimensionar os clusters.
Índice secundário global: uma tabela que contém atributos selecionados da tabela base, organizada por uma chave principal que é diferente da da tabela. A chave de índice não tem de incluir nenhum dos atributos de chave da tabela. Nem sequer tem de ter o mesmo esquema de chaves que a tabela.	Índice secundário assíncrono: para consultar os mesmos dados usando diferentes padrões de pesquisa ou atributos, pode usar vistas materializadas contínuas como índices secundários assíncronos para tabelas. Para mais informações, consulte Crie um índice secundário assíncrono.

Operações

As operações do plano de dados permitem-lhe realizar ações de criação, leitura, atualização e eliminação (CRUD) em dados numa tabela. A tabela seguinte compara operações semelhantes do plano de dados para o DynamoDB e o Bigtable.

DynamoDB	Bigtable
CreateTable	CreateTable
PutItem BatchWriteItem	MutateRow MutateRows O Bigtable trata as operações de escrita como inserções/atualizações.
UpdateItem Escrita condicional Incrementar e decrementar	CheckAndMutateRow ReadModifyWriteRow O Bigtable trata as operações de escrita como inserções/atualizações.
GetItem BatchGetItem, Query, Scan	`ReadRow` `ReadRows` (intervalo, prefixo, análise inversa) O Bigtable suporta a análise eficiente por prefixo da chave da linha, padrão de expressão regular ou intervalo da chave da linha para a frente ou para trás.

Tipos de dados

O Bigtable e o DynamoDB não têm esquemas. As colunas podem ser definidas no momento da escrita sem aplicação de regras ao nível da tabela para a existência de colunas ou tipos de dados. Da mesma forma, um determinado tipo de dados de coluna ou atributo pode diferir de uma linha ou de um item para outro. No entanto, as APIs DynamoDB e Bigtable lidam com os tipos de dados de formas diferentes.

Cada pedido de gravação do DynamoDB inclui uma definição de tipo para cada atributo, que é devolvida com a resposta para pedidos de leitura.

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

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

DynamoDB	Bigtable
Tipos escalares: devolvidos como tokens descritores de tipo de dados na resposta do servidor.	Bytes: os bytes são convertidos nos tipos pretendidos na aplicação cliente. Increment interpreta o valor como um número inteiro com sinal de 64 bits em formato big-endian
Definir: uma coleção não ordenada de elementos únicos.	Família de colunas: pode usar qualificadores de colunas como nomes de membros do conjunto e, para cada um, fornecer um único byte 0 como o valor da célula. Os membros do conjunto são ordenados lexicograficamente na respetiva família de colunas.
Map: uma coleção não ordenada de pares de chave-valor com chaves únicas.	Família de colunas Use o qualificador de coluna como chave do mapa e o valor da célula para o valor. As chaves do mapa são ordenadas lexicograficamente.
Lista: uma coleção ordenada de itens.	Qualificador de coluna Use a data/hora de inserção para alcançar o equivalente ao comportamento list_append, o inverso da data/hora de inserção para prepend.

Design de esquemas

Uma consideração importante na conceção do esquema é a forma como os dados são armazenados. Entre as principais diferenças entre o Bigtable e o DynamoDB, destacam-se a forma como processam o seguinte:

• Atualizações a valores únicos
• Ordenação de dados
• Controlo de versões de dados
• Armazenamento de valores grandes

Atualizações a valores únicos

As operações UpdateItem no DynamoDB consomem a capacidade de escrita para o maior dos tamanhos dos itens "antes" e "depois", mesmo que a atualização envolva um subconjunto dos atributos do item. Isto significa que, no DynamoDB, pode colocar colunas atualizadas com frequência em linhas separadas, mesmo que, logicamente, pertençam à mesma linha com outras colunas.

O Bigtable pode atualizar uma célula com a mesma eficiência, quer seja a única coluna numa determinada linha ou uma entre muitos milhares. Para obter detalhes, consulte a secção Gravações simples.

Ordenação de dados

O DynamoDB aplica hash e distribui aleatoriamente as chaves de partição, enquanto o Bigtable armazena linhas por ordem lexicográfica por chave de linha e deixa qualquer aplicação de hash ao utilizador.

A distribuição aleatória de chaves não é ideal para todos os padrões de acesso. Reduz o risco de intervalos de linhas frequentes, mas torna os padrões de acesso que envolvem análises que atravessam limites de partições dispendiosos e ineficientes. Estas leituras ilimitadas são comuns, especialmente para exemplos de utilização que têm uma dimensão de tempo.

O processamento deste tipo de padrão de acesso, ou seja, as análises que atravessam os limites das partições, requer um índice secundário no DynamoDB, mas não no Bigtable. Embora possa conceber a chave de linha lexicográfica no Bigtable para processar muitos padrões de leitura de forma eficiente, o Bigtable também suporta índices secundários assíncronos que implementa como vistas materializadas contínuas para fornecer pesquisas eficientes e, eventualmente, consistentes para padrões de consulta alternativos. Da mesma forma, no DynamoDB, as operações de consulta e análise estão limitadas a 1 MB de dados analisados, o que requer paginação além deste limite. O Bigtable não tem esse limite.

Apesar das chaves de partição distribuídas aleatoriamente, o DynamoDB pode continuar a ter partições frequentes se uma chave de partição escolhida não distribuir uniformemente o tráfego, o que afeta negativamente a taxa de transferência. Para resolver este problema, o DynamoDB recomenda a divisão de gravações, dividindo aleatoriamente as gravações em vários valores de chave de partição lógica.

Para aplicar este padrão de design, tem de criar um número aleatório a partir de um conjunto fixo (por exemplo, de 1 a 10) e, em seguida, usar este número como a chave de partição lógica. Uma vez que está a aleatorizar a chave de partição, as gravações na tabela são distribuídas uniformemente por todos os valores da chave de partição.

O Bigtable refere-se a este procedimento como adição de sal às chaves, e pode ser uma forma eficaz de evitar tabelas ativas.

Controlo de versões de dados

Cada célula do Bigtable tem um carimbo de data/hora e o carimbo de data/hora mais recente é sempre o valor predefinido para qualquer coluna específica. Um exemplo de utilização comum das datas/horas é o controlo de versões: escrever uma nova célula numa coluna que se diferencia das versões anteriores dos dados dessa linha e coluna pela respetiva data/hora.

O DynamoDB não tem esse conceito e requer designs de esquemas complexos para suportar o controlo de versões. Esta abordagem envolve a criação de duas cópias de cada item: uma cópia com um prefixo de número de versão de zero, como v0_, no início da chave de ordenação, e outra cópia com um prefixo de número de versão de um, como v1_. Sempre que o item é atualizado, usa o prefixo de versão seguinte mais elevado na chave de ordenação da versão atualizada e copia o conteúdo atualizado para o item com o prefixo de versão zero. Isto garante que a versão mais recente de qualquer artigo pode ser localizada através do prefixo zero. Esta estratégia não só requer lógica do lado da aplicação para manter, como também torna as escritas de dados muito caras e lentas, porque cada escrita requer uma leitura do valor anterior mais duas escritas.

Transações de várias linhas vs. capacidade de linhas grande

O Bigtable não suporta transações de várias linhas. No entanto, uma vez que permite armazenar linhas muito maiores do que os itens podem ser no DynamoDB, pode, muitas vezes, obter a transacionalidade pretendida ao estruturar os seus esquemas para agrupar itens relevantes numa chave de linha partilhada. Para ver um exemplo que ilustra esta abordagem, consulte o padrão de design de tabela única.

Armazenar valores grandes

Uma vez que um item do DynamoDB, que é análogo a uma linha do Bigtable, está limitado a 400 KB, o armazenamento de valores grandes requer a divisão do valor em vários itens ou o armazenamento noutros suportes, como o S3. Ambas estas abordagens adicionam complexidade à sua aplicação. Por outro lado, uma célula do Bigtable pode armazenar até 100 MB e uma linha do Bigtable pode suportar até 256 MB.

Exemplos de tradução de esquemas

Os exemplos nesta secção traduzem esquemas do DynamoDB para o Bigtable tendo em conta as principais diferenças de design de esquemas.

Migrar esquemas básicos

Os catálogos de produtos são um bom exemplo para demonstrar o padrão básico de chave-valor. Segue-se um exemplo de como um esquema deste tipo pode ser apresentado no DynamoDB.

Chave principal		Atributos
Chave de partição	Chave de ordenação	Descrição	Preço	Miniatura
chapéus	fedoras#brandA	Concebida em lã premium…	30	https://storage…
chapéus	fedoras#brandB	Tela resistente à água duradoura concebida para…	28	https://storage…
chapéus	newsboy#brandB	Adicione um toque de charme vintage ao seu visual do dia a dia.	25	https://storage…
sapatos	sneakers#brandA	Saia com estilo e conforto com…	40	https://storage…
sapatos	sneakers#brandB	Funcionalidades clássicas com materiais contemporâneos…	50	https://storage…

Para esta tabela, o mapeamento do DynamoDB para o Bigtable é simples: converte a chave primária composta do DynamoDB numa chave de linha composta do Bigtable. Cria uma família de colunas (SKU) que contém o mesmo conjunto de colunas.

Nota: cada valor no Bigtable também tem um carimbo de data/hora , que não é apresentado na tabela para simplificar.

	SKU
Chave da linha	Descrição	Preço	Miniatura
hats#fedoras#brandA	Concebida em lã premium…	30	https://storage…
hats#fedoras#brandB	Tela resistente à água duradoura concebida para…	28	https://storage…
hats#newsboy#brandB	Adicione um toque de charme vintage ao seu visual do dia a dia.	25	https://storage…
shoes#sneakers#brandA	Saia com estilo e conforto com…	40	https://storage…
shoes#sneakers#brandB	Funcionalidades clássicas com materiais contemporâneos…	50	https://storage…

Padrão de design de tabela única

Um padrão de design de tabela única reúne o que seriam várias tabelas numa base de dados relacional numa única tabela no DynamoDB. Pode adotar a abordagem do exemplo anterior e duplicar este esquema tal como está no Bigtable. No entanto, é melhor resolver os problemas do esquema durante o processo.

Neste esquema, a chave de partição contém o ID exclusivo de um vídeo, o que ajuda a colocar todos os atributos relacionados com esse vídeo para um acesso mais rápido. Dadas as limitações de tamanho dos itens do DynamoDB, não pode colocar um número ilimitado de comentários de texto livre numa única linha. Por conseguinte, é usada uma chave de ordenação com o padrão VideoComment#reverse-timestamp para tornar cada comentário numa linha separada na partição, ordenada por ordem cronológica inversa.

Suponhamos que este vídeo tem 500 comentários e o proprietário quer removê-lo. Isto significa que todos os comentários e atributos do vídeo também têm de ser eliminados. Para o fazer no DynamoDB, tem de analisar todas as chaves nesta partição e, em seguida, emitir vários pedidos de eliminação, iterando através de cada uma. O DynamoDB suporta transações de várias linhas, mas este pedido de eliminação é demasiado grande para ser feito numa única transação.

Chave principal		Atributos
Chave de partição	Chave de ordenação	UploadDate	Formatos
0123	Vídeo	2023-09-10T15:21:48	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
	VideoComment#98765481	Conteúdo
		Gosto muito disto. Os efeitos especiais são incríveis.
	VideoComment#86751345	Conteúdo
		Existe uma falha de áudio aos 1:05.
	VideoStatsLikes	Contagem
		3
	VideoStatsViews	Contagem
		156
0124	Vídeo	2023-09-10T17:03:21	{"480": "https://storage…", "720": "https://storage…"}
	VideoComment#97531849	Conteúdo
		Partilhei isto com todos os meus amigos.
	VideoComment#87616471	Conteúdo
		O estilo lembra-me o de um realizador de cinema, mas não consigo identificar quem é.
	VideoStats	ViewCount
		45

Modifique este esquema à medida que migra para poder simplificar o seu código e fazer pedidos de dados mais rápidos e baratos. As linhas do Bigtable têm uma capacidade muito maior do que os itens do DynamoDB e podem processar um grande número de comentários. Para gerir um caso em que um vídeo recebe milhões de comentários, pode definir uma política de recolha de lixo para manter apenas um número fixo dos comentários mais recentes.

Como os contadores podem ser atualizados sem a sobrecarga de atualizar toda a linha, também não tem de os dividir. Também não tem de usar uma coluna UploadDate nem calcular uma data/hora invertida e torná-la a sua chave de ordenação, porque as datas/horas do Bigtable dão-lhe automaticamente os comentários ordenados cronologicamente de forma inversa. Isto simplifica significativamente o esquema e, se um vídeo for removido, pode remover transacionalmente a linha do vídeo, incluindo todos os comentários, num único pedido.

Por último, uma vez que as colunas no Bigtable estão ordenadas lexicograficamente, como otimização, pode mudar o nome das colunas de forma a permitir uma análise rápida do intervalo, desde as propriedades do vídeo aos N principais comentários mais recentes, num único pedido de leitura, que é o que quer fazer quando o vídeo é carregado. Posteriormente, pode percorrer os restantes comentários à medida que o visitante desloca a página.

	Atributos
Chave da linha	Formatos	Gostos	Visualizações	UserComments
0123	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48	3	156	Gosto muito disto. Os efeitos especiais são incríveis. @ 2023-09-10T19:01:15 Parece haver uma falha de áudio aos 1:05. @ 2023-09-10T16:30:42
0124	{"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21		45	O estilo lembra-me o de um realizador de cinema, mas não consigo identificar quem é. @2023-10-12T07:08:51

Padrão de design de lista de adjacências

Considere uma versão ligeiramente diferente deste design, que o DynamoDB refere-se frequentemente como o padrão de design de lista de adjacências.

Chave principal		Atributos
Chave de partição	Chave de ordenaçã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":"John…", "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 ordenação não se baseiam no tempo, mas sim nos IDs de pagamento. Por isso, pode usar um padrão de colunas largas diferente e tornar essas colunas de IDs separadas no Bigtable, com vantagens semelhantes ao exemplo anterior.

	Fatura	Pagamento
chave da linha	Detalhes	0680	0789
0123	{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} @ 2023-09-10T15:21:48	{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"} a 2023-09-10T15:21:40	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"} @ 2023-09-10T15:21:31
chave da linha	Detalhes	0275	0327
0124	{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} @ 2023-09-09T10:11:28	{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"} @ 2023-09-09T10:11:03	{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"} @ 2023-09-09T10:11:10

Como pode ver nos exemplos anteriores, com o design de esquema certo, o modelo de colunas largas do Bigtable pode ser bastante eficaz e oferecer muitos exemplos de utilização que exigiriam transações de várias linhas dispendiosas, indexação secundária ou comportamento em cascata na eliminação noutras bases de dados.

O que se segue?

• Leia acerca do design do esquema do Bigtable.
• Saiba mais sobre o emulador do Bigtable.
• Explore arquiteturas de referência, diagramas e práticas recomendadas sobre Google Cloud. Consulte o nosso Centro de arquitetura na nuvem.