Bigtable para usuários do DynamoDB
Este documento é destinado a desenvolvedores do DynamoDB e administradores de banco de dados que querem migrar ou projetar aplicativos para uso com o Bigtable como um armazenamento de dados. Antes de ler este documento, leia a visão geral do Bigtable.
O Bigtable e o DynamoDB são armazenamentos de chave-valor distribuídos que suportam milhões de consultas por segundo (QPS), fornecem armazenamento que escalona até petabytes de dados e toleram falhas de nó.
Os conjuntos de recursos desses serviços de banco de dados são semelhantes, mas as arquiteturas subjacentes e os detalhes de interação diferem de maneiras que são importantes de entender antes de iniciar uma migração. Este documento destaca 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 configurar e gerenciar recursos. O DynamoDB é um produto sem servidor, e o nível mais alto de interação com ele é no nível da tabela. No modo de capacidade provisionada, é aqui que você provisiona suas unidades de solicitação de leitura e gravação, seleciona suas regiões e replicação e gerencia backups. O Bigtable não é um produto sem servidor. Você precisa 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 do DynamoDB e do Bigtable.
| DynamoDB | Bigtable |
|---|---|
| Tabela : uma coleção de itens com uma chave primária definida. 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, entre as quais a replicação e o roteamento de conexão ocorrem. As políticas de replicação são definidas no
nível da instância. Cluster: um grupo de nós na mesma zona geográfica do Google Cloud, idealmente localizado com seu servidor de aplicativos por motivos de latência e replicação. A capacidade é gerenciada pelo ajuste do número de nós em cada cluster. Tabela: uma organização lógica de valores indexados 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, na sigla em inglês):
unidades que permitem leituras ou gravações por segundo com tamanho de payload
fixo. Você é cobrado por unidades de leitura ou gravação para cada
operação com tamanhos de payload maiores. As operações UpdateItem consomem a capacidade de gravação usada para o
maior tamanho de um item atualizado, antes ou depois da atualização,
mesmo que ela envolva um subconjunto dos atributos do item. |
Nó:um recurso de computação virtual responsável por
ler e gravar dados. O número de nós que um cluster é convertido em limites de capacidade para leituras, gravações e verificações. É possível
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 da 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 rígido de 1.000 WCUs, 3.000 RCUs e 10 GB de dados. |
Tablet: um bloco de linhas contíguas apoiado pelo meio de armazenamento de sua escolha (SSD ou HDD). As tabelas são fragmentadas em tablets para equilibrar a carga de trabalho. Eles não são armazenados em nós no Bigtable, mas no sistema de arquivos distribuído do Google, o que permite redistribuição rápida dos dados durante o escalonamento e que fornece durabilidade adicional ao manter várias cópias. |
| Tabelas globais: uma maneira de aumentar a disponibilidade e a durabilidade dos dados propagando automaticamente as alterações de dados por várias regiões. | Replicação: uma maneira de aumentar a disponibilidade e a durabilidade dos dados, propagando automaticamente as alterações de dados por várias regiões ou várias zonas dentro da mesma região. |
| Não relevante (N/A) | Perfil do aplicativo: configurações que instruem o Bigtable a rotear uma chamada de API do cliente para o cluster apropriado na instância. Você também pode usar um perfil de aplicativo como tag para segmentar métricas para atribuição. |
Replicação geográfica
A replicação é usada para dar suporte aos requisitos do cliente para o seguinte:
- Alta disponibilidade para continuidade dos negócios no caso de uma falha zonal ou regional.
- Colocar os dados de serviço mais próximos dos usuários finais para disponibilização de baixa latência em qualquer lugar do mundo.
- Isolamento de carga de trabalho quando você precisa implementar uma carga de trabalho em lote em um cluster e depender da replicação para exibir clusters.
O Bigtable aceita clusters replicados em quantas zonas estão 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 automaticamente os dados 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 a Visão geral da replicação.
O DynamoDB fornece tabelas globais para dar suporte à replicação de tabelas em várias regiões. As tabelas globais são multiprimárias e replicam automaticamente entre as regiões. A replicação tem consistência posterior.
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 globais. |
Consistência posterior. Consistência na leitura das gravações no nível regional para todas as tabelas. |
| Latência de replicação | Nenhum 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 | Crie uma tabela global com uma réplica de tabela em cada região selecionada. Nível regional. Replicação automática entre réplicas convertendo uma tabela em uma tabela global. As tabelas precisam ter o DynamoDB Streams ativado, com o stream contendo as imagens novas e antigas 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 dessa instância. Nível zonal. Adicionar e remover clusters de uma instância do Bigtable. |
| 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, aplique a lógica de negócios personalizada para determinar quando redirecionar solicitações para outras regiões. |
Use perfis de aplicativo para configurar
políticas de roteamento de tráfego de 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 aceita failover automático entre clusters para alta disponibilidade. |
| Escalonamento | A capacidade de gravação em unidades de solicitação de gravação replicadas (R-WRU, na sigla em inglês) é sincronizada entre as réplicas. A capacidade de leitura em unidades de capacidade de leitura replicadas (R-RCU, na sigla em inglês) é por réplica. |
É possível escalonar clusters de maneira independente adicionando ou removendo nós de cada cluster replicado, conforme necessário. |
| Custo | Os R-WRUs custam 50% a mais do que os WRUs comuns. | A cobrança é feita com base nos nós e no armazenamento de cada cluster. Não há custos de replicação de rede para replicação regional entre zonas. Os custos são gerados 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 análogos. Por exemplo, um item no DynamoDB é semelhante a uma linha no Bigtable.
| DynamoDB | Bigtable |
|---|---|
| Item : um grupo de atributos exclusivamente identificáveis entre todos os outros itens pela chave primária. O tamanho máximo 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. O valor do atributo pode ser um tipo escalar, de conjunto ou de documento. Não há limite explícito no tamanho do atributo em si. No entanto, como cada item está limitado a 400 KB, para um item que tenha apenas um atributo, o atributo pode ter até 400 KB menos o tamanho ocupado pelo nome do atributo. | Qualificador de coluna: o identificador exclusivo em um
grupo de colunas de uma coluna. O identificador completo de uma coluna é expresso como column-family:column-qualifier. Os qualificadores de coluna são
classificados 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 que pode ser de até 100 MB. |
| Chave primária : um identificador exclusivo para um item em uma tabela. Pode ser uma chave de partição ou uma chave composta. Chave de partição: uma chave primária simples, composta por um atributo. Isso determina a partição física em que o item está localizado. O tamanho máximo permitido é 2 KB. Chave de classificação: uma chave que determina a ordem das linhas em uma partição. O tamanho máximo permitido é 1 KB. Chave composta: uma chave primária composta por duas propriedades, a chave de partição e uma chave de classificação ou um atributo de intervalo. |
Chave de linha : identificador exclusivo de 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 um comportamento equivalente ao da chave de classificação do DynamoDB. Chaves compostas podem ser criadas usando chaves de linha concatenadas e qualificadores de coluna. Para mais detalhes, consulte o exemplo de conversão de esquema na seção de design de esquema deste documento. |
| Time to live : os carimbos de data/hora por item determinam quando um item não é mais necessário. Após a data e a hora do carimbo de data/hora especificado, o item é excluído da tabela sem consumir nenhuma capacidade de gravação. | Coleta de lixo : os carimbos de data/hora por célula determinam quando um item não é mais necessário. A coleta de lixo exclui itens expirados durante um processo em segundo plano chamado compactação. As políticas de coleta de lixo são definidas no nível do grupo de colunas e podem excluir itens não apenas com base na idade, mas também de acordo com o número de versões que o usuário quer manter. Não é necessário acomodar a capacidade de compactação ao dimensionar os clusters. |
Operações
Com as operações do plano de dados, é possível executar ações de criação, leitura, atualização e exclusão (CRUD, na sigla em inglês) nos dados de uma tabela. A tabela a seguir compara operações de plano de dados semelhantes para o DynamoDB e o Bigtable.
| DynamoDB | Bigtable |
|---|---|
CreateTable |
CreateTable |
PutItemBatchWriteItem |
MutateRow MutateRowsO Bigtable trata das operações de gravação como upserts. |
UpdateItem
|
O Bigtable trata as operações de gravação como upserts. |
GetItemBatchGetItem, Query e Scan |
"ReadRow"" ReadRows" (intervalo, prefixo, verificação reversa)O Bigtable aceita verificação eficiente por prefixo de chave de linha, padrão de expressão regular ou intervalo de chaves de linha para frente ou para trás. |
Tipos de dados
Tanto o Bigtable quanto o DynamoDB não têm esquemas. As colunas podem ser definidas no momento da gravação sem qualquer imposição em toda a tabela para a existência da coluna 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 tipos de dados de maneiras diferentes.
Cada solicitação de gravação do DynamoDB inclui uma definição de tipo para cada atributo, que é retornada com a resposta para solicitações 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 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 de escalar: retornados como tokens de descritor de tipo de dados na resposta do servidor. | Bytes: os bytes são convertidos para os tipos pretendidos no aplicativo
cliente. Increment interpreta o valor como um número inteiro com sinal big-endian de 64 bits |
| Conjunto : uma coleção não classificada de elementos exclusivos. | Grupo de colunas: é possível usar qualificadores de coluna como nomes de membros definidos e, para cada um, fornecer um único byte 0 como o valor da célula. Os membros do conjunto são classificados lexicograficamente no grupo de colunas. |
| 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 de mapa e valor de célula para valor. As chaves de mapa são classificadas lexicograficamente. |
| Lista : uma coleção ordenada de itens. | Qualificador de coluna Use o carimbo de data/hora de inserção para alcançar o comportamento equivalente do comportamento list_append, invertendo o carimbo de data/hora de inserção para anexar. |
Design de esquema
Uma consideração importante no design de esquemas é a forma como os dados são armazenados. Entre as principais diferenças entre o Bigtable e o DynamoDB estão a maneira de lidar com os seguintes itens:
- Atualizações para valores únicos
- Classificação de dados
- Controle de versões de dados
- Armazenamento de grandes valores
Atualizações para valores únicos
As operações UpdateItem no DynamoDB consomem a capacidade de gravação para os
tamanhos de item "antes" e "depois" que são maiores, mesmo que a atualização envolva um subconjunto dos
atributos do item. Isso significa que, no DynamoDB, você pode colocar colunas atualizadas com frequência em linhas separadas, mesmo que logicamente elas pertençam à mesma linha com outras colunas.
O Bigtable pode atualizar 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
O DynamoDB gera hashes e distribui chaves de partição aleatoriamente, enquanto o Bigtable armazena linhas em ordem lexicográfica por chave de linha e deixa qualquer hash para o usuário.
A distribuição de chaves aleatória não é ideal para todos os padrões de acesso. Isso reduz o risco de intervalos de linhas quentes, mas cria padrões de acesso que envolvem verificações que cruzam limites de partição caros e ineficientes. Essas verificações ilimitadas são comuns, especialmente para casos de uso que têm uma dimensão de tempo.
O processamento desse tipo de padrão de acesso (verificações que cruzam limites de partição) 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 verificados, o que exige paginação além desse limite. O Bigtable não tem esse limite.
Apesar das chaves de partição distribuídas aleatoriamente, o DynamoDB ainda pode ter partições quentes se uma chave de partição escolhida não distribuir de maneira uniforme o tráfego que afeta negativamente a capacidade. Para resolver esse problema, o DynamoDB recomenda a fragmentação de gravação, que divide as gravações aleatoriamente em vários valores de chave de partição lógica.
Para aplicar esse padrão de projeto, é necessário criar um número aleatório a partir de um conjunto fixo (por exemplo, de 1 a 10) e usar esse número como a chave de partição lógica. Como você está randomizando a chave de partição, as gravações na tabela são distribuídas uniformemente por todos os valores das chaves de partição.
O Bigtable se refere a esse procedimento como sal de chave e pode ser uma maneira eficaz de evitar tablets quentes.
Controle 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 padrão de qualquer coluna. Um caso de uso comum de carimbos de data/hora é o controle de versões: gravar uma nova célula em uma coluna que difere de versões anteriores dos dados dessa linha e coluna pelo carimbo de data/hora.
O DynamoDB não tem esse conceito e requer designs de esquema complexos para oferecer 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 zero, como v0_, no início
da chave de classificação, e outra com o prefixo de número de versão 1, como
v1_. Sempre que o item for atualizado, use o próximo prefixo de versão superior na chave de classificação da versão atualizada e copie 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
ser localizada usando o prefixo zero. Essa estratégia não apenas requer
a manutenção da lógica do lado do aplicativo, mas também torna as gravações de dados muito caras e
lentas, porque cada gravação exige uma leitura do valor anterior mais duas
gravações.
Transações de várias linhas versus grande capacidade de linhas
O Bigtable não aceita transações de várias linhas. No entanto, como ele permite armazenar linhas muito maiores do que os itens podem estar no DynamoDB, muitas vezes é possível conseguir a transacionalidade pretendida ao projetar seus esquemas para agrupar itens relevantes em uma chave de linha compartilhada. Para ver um exemplo que ilustra essa abordagem, consulte Padrão de design de tabela única.
Como armazenar valores grandes
Como um item do DynamoDB, que é análogo a uma linha do Bigtable, é limitado a 400 KB, armazenar valores grandes requer a divisão do valor entre itens ou o armazenamento em outra mídia, como a S3. Ambas as abordagens aumentam a complexidade do aplicativo. Por outro lado, uma célula do Bigtable pode armazenar até 100 MB, e uma linha do Bigtable aceita até 256 MB.
Exemplos de conversão de esquema
Nos exemplos desta seção, os esquemas do DynamoDB são convertidos para o Bigtable, tendo em mente as principais diferenças de projeto de esquema.
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 como esse esquema pode ficar no DynamoDB.
| Chave primária | Atributos | |||
|---|---|---|---|---|
| Chave de partição | Chave de classificação | Descrição | Price | Miniatura |
| chapéus | fedoras#marcaA | Criado com lã premium... | 30 | https://storage… |
| chapéus | fedoras#marcaB | Tela durável e resistente à água criada para... | 28 | https://storage… |
| chapéus | jornalista#marcaB | Dê um toque vintage ao seu visual. | 25 | https://storage… |
| calçados | tênis#marcaA | Saia com estilo e conforto com... | 40 | https://storage… |
| calçados | tênis#marcaB | Recursos clássicos com materiais contemporâneos... | 50 | https://storage… |
Para esta tabela, o mapeamento do DynamoDB para o Bigtable é direto: você converte a chave primária composta do DynamoDB em uma chave de linha composta do Bigtable. Você cria um grupo de colunas (SKU) que contém o mesmo conjunto de colunas.
| SKU | |||
|---|---|---|---|
| Chave de linha | Descrição | Price | Miniatura |
| chapéus#fedoras#brandA | Criado com lã premium... | 30 | https://storage… |
| chapéus#fedoras#brandB | Tela durável e resistente à água criada para... | 28 | https://storage… |
| chapéus#noticias#marcaB | Dê um toque vintage ao seu visual. | 25 | https://storage… |
| calçados#tênis#marcaA | Saia com estilo e conforto com... | 40 | https://storage… |
| calçados#tênis#marcaB | Recursos 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. Use a abordagem do exemplo anterior e duplique esse esquema no estado em que se encontra no Bigtable. No entanto, é melhor resolver os problemas do esquema no processo.
Nesse esquema, a chave de partição contém o ID exclusivo de um vídeo, que
ajuda a posicionar todos os atributos relacionados a esse vídeo para um acesso mais rápido. Dadas as limitações de tamanho de item do DynamoDB, não é possível colocar um número ilimitado de comentários de texto livre em uma única linha. Portanto, uma chave de classificação com o padrão VideoComment#reverse-timestamp é usada para fazer de cada comentário uma linha separada na partição, classificada 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 do vídeo também precisam ser excluídos. Para fazer isso no DynamoDB, você precisa verificar todas as chaves dentro dessa partição e emitir várias solicitações de exclusão, iterando cada uma delas. O DynamoDB oferece suporte a transações de várias linhas, mas a 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 do vídeo no 98765481 | Conteúdo | |||
| Gosto muito disso. Os efeitos especiais são incríveis. | ||||
| Comentário sobre vídeo 86751345 | Conteúdo | |||
| Parece que há uma falha no á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 isso com todos os meus amigos. | ||||
| Comentário sobre vídeo 87616471 | Conteúdo | |||
| O estilo me lembra um diretor de cinema, mas não consigo colocar o dedo nele. | ||||
| VideoStats | ViewCount | |||
| 45 | ||||
Modifique esse esquema durante a migração para simplificar o código e fazer solicitações de dados de maneira mais rápida e econômica. As linhas do Bigtable têm capacidade muito maior que os itens do DynamoDB e podem lidar com um grande número de comentários. Para lidar com um caso em que um vídeo recebe milhões de comentários, defina uma política de coleta de lixo para manter apenas um número fixo de comentários mais recentes.
Como os contadores podem ser atualizados sem a sobrecarga da atualização de toda a linha, você também não precisa dividi-los. Você não precisa usar a coluna UploadDate ou calcular um carimbo de data/hora inverso e tornar essa chave de classificação, porque os carimbos de data/hora do Bigtable oferecem os comentários em ordem cronológica inversa automaticamente. Isso simplifica significativamente o esquema e, se um vídeo for removido, você poderá remover de maneira transacional a linha do vídeo, incluindo todos os comentários, em uma única solicitação.
Por fim, como as colunas no Bigtable são ordenadas lexicograficamente, como uma otimização, é possível renomeá-las de uma maneira que permita uma verificação de intervalo rápido, de propriedades de vídeo aos N comentários mais recentes, em uma única solicitação de leitura, que é o que você faria quando o vídeo fosse carregado. Mais tarde, você poderá navegar pelos outros comentários à medida que o espectador rolar 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 | Gosto muito disso. Os efeitos especiais são incríveis. @
10-09-2023T19:01:15 Parece que há uma falha no áudio em 1:05. a 10-09-2023T16:30:42 |
| 0124 | {"480": "https://storage...", "720":"https://storage..."} @2023-09-10T17:03:21 | 45 | O estilo me lembra um diretor de cinema, mas não consigo colocar o dedo nele. @2023-10-12T07:08:51 | |
Padrão de design da lista de vulnerabilidades
Considere uma versão um pouco diferente desse design, que o DynamoDB costuma chamar de padrão de design de lista de distinções.
| 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 em IDs de pagamento, portanto, é possível usar um padrão de colunas largas diferente e tornar esses IDs separados em colunas no Bigtable, com benefícios semelhantes ao exemplo anterior.
| Fatura | Pagamento | |||
|---|---|---|---|---|
| chave de linha | Detalhes | 0680. | 0789 | |
| 0123 | {"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} @ 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..."} @ 2023-09-10T15:21:31 |
|
| chave de linha | Detalhes | 0275 | 0327. | |
| 0124 | {"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} @ 09-09-2023T10: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 mostrado nos exemplos anteriores, com o design de esquema correto, o modelo de colunas largas do Bigtable pode ser bastante poderoso e fornecer muitos casos de uso que exigiriam transações caras com várias linhas, indexação secundária ou comportamento em cascata da exclusão em outros bancos de dados.
A seguir
- Leia sobre o design do esquema do Bigtable.
- Saiba mais sobre o emulador do Bigtable.
- Confira arquiteturas de referência, diagramas e práticas recomendadas sobre o Google Cloud. Confira o Centro de arquitetura do Cloud.