Bigtable para usuarios de DynamoDB

Este documento está dirigido a desarrolladores y a la base de datos de DynamoDB los administradores que quieren migrar o diseñar para usar con Bigtable como almacén de datos. Antes de leer este documento, consulta la descripción general de Bigtable.

Bigtable y DynamoDB son almacenes de clave-valor distribuidos que pueden admitir millones de consultas por segundo (QPS), proporcionan almacenamiento que escala verticalmente hasta petabytes de datos y toleran fallas en los nodos.

Si bien los conjuntos de atributos de estos servicios de base de datos son similares, sus arquitecturas subyacentes y los detalles de interacción difieren en formas que que debe comprender antes de comenzar una migración. En este documento se destaca y las similitudes y diferencias entre ambos sistemas de base de datos.

Plano de control

En DynamoDB y Bigtable, el plano de control te permite configurar tu capacidad y configurar y administrar los recursos. DynamoDB es un producto sin servidores, y el mayor nivel de interacción con DynamoDB es el nivel de la tabla. En modo de capacidad aprovisionada, aquí es donde aprovisionas las operaciones de lectura y escritura solicitar unidades, seleccionar las regiones y la replicación, y administrar las copias de seguridad. Bigtable no es un producto sin servidores. debes crear una instancia con uno o más clústeres, cuya capacidad se determina por la cantidad de nodos que tienen. Para obtener detalles sobre estos recursos, consulta Instancias, clústeres y nodos.

La siguiente tabla compara los recursos del plano de control de DynamoDB y en Bigtable.

DynamoDB Bigtable
Tabla: Una colección de elementos con un principal definido . Las tablas tienen configuración para las copias de seguridad, replicación y capacidad. Instancia: Un grupo de clústeres de Bigtable en zonas o regiones diferentes de Google Cloud, entre qué tipos de y se produce el enrutamiento de conexiones. Las políticas de replicación se establecen a nivel de instancia.

Clúster: Es un grupo de nodos en la misma ubicación geográfica. Zona de Google Cloud, ubicada idealmente junto a tu aplicación por motivos de latencia y replicación. La capacidad es administrada por ajustando la cantidad de nodos en cada clúster.

Tabla: Una organización lógica de los valores se indexa por clave de fila.

Las copias de seguridad se controlan a nivel de la tabla.
Unidad de capacidad de lectura (RCU) y unidad de capacidad de escritura (WCU): Las unidades que permiten lecturas o escrituras por segundo con el tamaño de la carga útil. Se cobra por las unidades de lectura o escritura de cada con tamaños de carga útil más grandes.

Las operaciones UpdateItem consumen la capacidad de escritura que se usa para el tamaño más grande de un elemento actualizado, ya sea antes o después de la actualización, incluso si la actualización involucra un subconjunto de atributos del elemento.		 Nodo: Es un recurso de procesamiento virtual responsable de en la lectura y escritura de datos. Cantidad de nodos que tiene un clúster se traduce en límites de capacidad de procesamiento para operaciones de lectura, escritura y análisis. Puedes ajusta la cantidad de nodos según la combinación de tus los objetivos de latencia, el recuento de solicitudes y el tamaño de la carga útil.

Los nodos SSD ofrecen la misma capacidad de procesamiento para lecturas y escrituras, a diferencia de la diferencia significativa entre RCU y WCU. Para obtener más información, consulta Rendimiento de las cargas de trabajo típicas.
Partición: Un bloque de filas contiguas, respaldadas por unidades de estado sólido (SSD) con nodos locales.

Cada partición está sujeta a un límite estricto de 1,000 WCU, 3,000 RCU y 10 GB de datos.		 Tablet: Un bloque de filas contiguas respaldadas por medio de almacenamiento preferido (SSD o HDD).

Las tablas se fragmentan en tablets para equilibrar la carga de trabajo. Las tabletas son no se almacenan en nodos en Bigtable, sino en un sistema de archivos distribuido, que permite la redistribución rápida de los datos cuando se escala, y cuál proporciona durabilidad adicional manteniendo varias copias.
Tablas globales: Es una forma de aumentar la disponibilidad y la durabilidad de tus datos con la propagación automática de los cambios en múltiples regiones. Replicación: Es una forma de aumentar la disponibilidad. la durabilidad de tus datos con la propagación automática de los cambios en varias regiones o en varias zonas dentro de la misma región.
No aplicable (N/A) Perfil de aplicación: Configuración que indica Bigtable sobre cómo enrutar una llamada a la API del cliente al clúster adecuado en la instancia. También puedes usar un perfil de app como una etiqueta para segmentar las métricas para la atribución.

Replicación geográfica

La replicación se usa para cumplir con los requisitos del cliente en relación con lo siguiente:

  • Alta disponibilidad para la continuidad empresarial en el caso de una zona falla regional.
  • Colocar los datos de tu servicio cerca de los usuarios finales para y baja latencia en cualquier parte del mundo.
  • Aislamiento de la carga de trabajo cuando necesitas implementar una carga de trabajo por lotes en un solo y dependen de la replicación para los clústeres de entrega.

Bigtable admite clústeres replicados en tantas zonas que están disponibles en hasta 8 regiones de Google Cloud Bigtable está disponible. La mayoría de las regiones tienen tres zonas. Bigtable replica automáticamente los datos de los clústeres multi-principal, lo que significa que puedes leer y escribir en cualquier clúster. La replicación de Bigtable tiene coherencia eventual. Para obtener más información, consulta el Descripción general de la replicación.

DynamoDB proporciona tablas globales para admitir la replicación de tablas en varias regiones. Las tablas globales son y replican automáticamente entre regiones. La replicación es coherencia eventual.

En la siguiente tabla, se enumeran los conceptos de replicación y se describe su disponibilidad en DynamoDB y Bigtable.

Propiedad DynamoDB Bigtable
Replicación de instancias principales múltiples Sí.

Puedes leer y escribir en cualquier tabla global.		 Sí.

Puedes leer y escribir en cualquier clúster de Bigtable.
Modelo de coherencia Coherencia eventual.

Coherencia en la lectura de tus escrituras a nivel regional para las operaciones globales tablas.		 Coherencia eventual.

Coherencia de lectura y escritura a nivel del clúster para todos siempre que envíes operaciones de lectura y escritura al mismo clúster.
Latencia de replicación Sin Acuerdo de Nivel de Servicio (ANS).

Segundos		 Sin ANS.

Segundos
Nivel de detalle de la configuración Nivel de la tabla. Nivel de instancia.

Una instancia puede contener varias tablas.
Implementación Crear una tabla global con una réplica de tabla en cada selección región.

Nivel regional.

Replicación automática en réplicas cuando convierte una tabla en tabla global.

Las tablas deben tener habilitadas las transmisiones de DynamoDB, con la transmisión que contiene las imágenes nuevas y antiguas del artículo.

Borra una región para quitar la tabla global en esa región.		 Crear una instancia con más de un clúster.
La replicación es automática entre los clústeres de esa instancia.

Nivel zonal.

Agrega y quita clústeres de Bigtable instancia.
Opciones de replicación Por tabla. Por instancia.
Enrutamiento y disponibilidad del tráfico El tráfico se enruta a la réplica geográfica más cercana.

En caso de falla, aplica una lógica empresarial personalizada para determinar y cuándo redireccionar solicitudes a otras regiones.		 Usa los perfiles de aplicación para configurar las políticas de enrutamiento de tráfico del clúster.

Usa el enrutamiento de varios clústeres para enrutar el tráfico automáticamente al clúster en buen estado más cercano.

En caso de que se produzca una falla, Bigtable admite las actualizaciones conmutación por error entre clústeres para alta disponibilidad.
Escalamiento La capacidad de escritura en las unidades de solicitud de escritura replicadas (R-WRU) es sincronizada entre réplicas.

La capacidad de lectura en unidades de capacidad de lectura replicadas (R-RCU) es por réplica.		 Puedes escalar clústeres de forma independiente si agregas o quitas nodos de cada clúster replicado según sea necesario.
Costo Las R-WRU cuestan un 50% más que las WRU normales. Se te factura por los nodos y el almacenamiento de cada clúster.
No hay costos de replicación de red para la replicación regional entre zonas.
Se generan costos cuando la replicación se realiza entre regiones o continentes.
ANS 99.999% 99.999%

Plano de datos

En la siguiente tabla, se comparan los conceptos de modelos de datos para DynamoDB y Bigtable. Cada fila de la tabla describe funciones análogas. Por ejemplo, un elemento en DynamoDB es similar a una fila en Bigtable.

DynamoDB Bigtable
Artículo: Es un grupo de atributos que es inequívoco. identificable entre todos los demás elementos por su clave primaria. Máxima el tamaño permitido es de 400 KB. Fila: Es una entidad única identificada por la clave de fila. El tamaño máximo permitido es de 256 MB.
N/A Familia de columnas: Un espacio de nombres especificado por el usuario que grupos de columnas.
Atributo: Es una agrupación de un nombre y un valor. Los el valor del atributo puede ser un tipo escalar, conjunto o de documento. No hay tiene un límite explícito en el tamaño de los atributos. Sin embargo, debido a que cada elemento está limitado a 400 KB. Para un artículo que solo tiene un atributo, el puede ser de hasta 400 KB menos el tamaño que ocupa la nombre del atributo. Calificador de columna: es el identificador único dentro de para la familia de columnas de una columna. El identificador completo de una columna es expresada como Column-family:column-qualifier. Los calificadores de columnas son de forma lexicográfica dentro de la familia de columnas.

El tamaño máximo permitido para un calificador de columna es de 16 KB.


Celda: Una celda contiene los datos de una fila, columna determinada. y marca de tiempo. Una celda contiene un valor que puede ser de hasta 100 MB.
Clave primaria: es un identificador único para un elemento de una desde una tabla de particiones. Puede ser una clave de partición o una clave compuesta.

Clave de partición: una clave primaria simple, compuesta por una . Esto determina la partición física donde se encuentra el elemento ubicado. El tamaño máximo permitido es de 2 KB.

Clave de ordenación: Es una clave que determina el orden de las filas. dentro de una partición. El tamaño máximo permitido es de 1 KB.

Clave compuesta: Una clave primaria compuesta por dos propiedades, la clave de partición y un atributo de rango o clave de orden.		 Clave de fila: Es un identificador único para un elemento de una tabla. Por lo general, se representa mediante una concatenación de valores y delimitadores. El tamaño máximo permitido es de 4 KB.

Se pueden usar calificadores de columnas para proporcionar equivalente a la clave de ordenamiento de DynamoDB.

Las claves compuestas se pueden compilar usando filas concatenadas y calificadores de columnas.

Para obtener más detalles, consulta el ejemplo de traducción de esquemas en la página Esquema. sección de diseño de este documento.
Tiempo de actividad: Las marcas de tiempo por elemento determinan el momento ya no es necesario el artículo. Después de la fecha y hora de la fecha y hora marca de tiempo, el elemento se borra de la tabla sin consumir ningún de escritura y escritura. Recolección de elementos no utilizados: Las marcas de tiempo por celda determinan cuando un artículo ya no es necesario. Venció la recolección de elementos no utilizados elementos durante un proceso en segundo plano llamado compactación. Basura las políticas de recopilación se establecen a nivel de la familia de columnas y pueden borrar artículos no solo según su edad, sino también según el número de versiones que el usuario desea mantener. No es necesario admitir para la compactación y ajusta el tamaño de los clústeres.

Operaciones

Las operaciones del plano de datos te permiten realizar operaciones de creación, lectura, actualización y eliminación (CRUD) acciones en los datos de una tabla. En la siguiente tabla, se compara un plano de datos similar para DynamoDB y Bigtable.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable trata las operaciones de escritura como actualizaciones o inserciones.
UpdateItem
  • Escritura condicional
  • Incremento y disminución
Bigtable trata las operaciones de escritura como actualizaciones o inserciones.
GetItem
BatchGetItem, Query y Scan		 `ReadRow`
`ReadRows` (rango, prefijo, análisis inverso)
Bigtable admite un análisis eficiente por prefijo de clave de fila, patrón de expresión regular o rango de clave de fila hacia delante o hacia atrás.

Tipos de datos

Tanto Bigtable como DynamoDB no tienen esquema. Se pueden definir las columnas en el momento de la escritura sin ninguna aplicación forzosa en toda la tabla para la existencia de una columna o sus datos de tipos de datos. Del mismo modo, una columna o un tipo de datos de atributo determinados pueden diferir de una fila o un elemento a otro. Sin embargo, las APIs de DynamoDB y Bigtable con los tipos de datos de diferentes maneras.

Cada solicitud de escritura de DynamoDB incluye una definición de tipo para cada atributo. que se devuelve con la respuesta para las solicitudes de lectura.

Bigtable trata todo como bytes y espera el código del cliente. conocer el tipo y la codificación para que el cliente pueda analizar las respuestas correctamente. Una excepción es incremento que interpretan los valores como números enteros con firma big-endian de 64 bits.

La siguiente tabla compara las diferencias de los tipos de datos entre DynamoDB y en Bigtable.

DynamoDB Bigtable
Tipos escalares: Se muestran como tipo de datos descriptor en la respuesta del servidor. Bytes: los bytes se convierten en los tipos deseados en el cliente. y mantener la integridad de su aplicación.

Increment interpreta el valor como Número entero con firma big-endian de 64 bits
Conjunto: Una colección sin ordenar de elementos o de terceros. Familia de columnas: Puedes usar calificadores de columnas como se muestra a continuación. de miembros y, para cada uno, proporciona un solo byte 0 como celda valor. Los miembros del conjunto se ordenan de manera lexicográfica dentro de la columna familia.
Mapa: una colección sin ordenar de pares clave-valor con claves únicas. Familia de columnas
Usa el calificador de columna como clave de asignación y valor de celda para el valor. Asignar claves se ordenan de manera lexicográfica.
Lista: Es una colección ordenada de elementos. Calificador de columna
Usa la marca de tiempo de inserción para lograr el equivalente de list_append en lugar de la marca de tiempo de inserción para anteponer.

Diseño de esquemas

Una consideración importante en el diseño de esquemas es la forma en que se almacenan los datos. Entre los Las diferencias clave entre Bigtable y DynamoDB es la forma en que manejan lo siguiente:

  • Actualizaciones de valores únicos
  • Ordenación de datos
  • Control de versiones de datos
  • Almacenamiento de valores grandes

Actualizaciones de valores únicos

Las operaciones UpdateItem en DynamoDB consumen la capacidad de escritura del valor mayor de el "antes" y "después" los tamaños de los elementos, incluso si la actualización involucra un subconjunto atributos del artículo. Esto significa que, en DynamoDB, podrías colocar actualizaciones en filas separadas, aunque, lógicamente, pertenezcan a la misma fila con otras columnas.

Bigtable puede actualizar una celda con la misma eficiencia, ya sea una sola columna en una fila determinada o una entre miles. Para obtener más información, consulta Escrituras simples.

Ordenación de datos

DynamoDB genera un hash y distribuye las claves de partición de forma aleatoria, mientras que Bigtable almacena las filas en orden lexicográfico por clave de fila y deja que el hash se encargue del usuario.

La distribución de claves aleatoria no es óptima para todos los patrones de acceso. Reduce el el riesgo de rangos de filas activas, pero genera patrones de acceso que implican análisis límites de partición son costosos y son ineficaces. Estos análisis no delimitados se comunes, especialmente para los casos de uso que tienen una dimensión de tiempo.

Control de este tipo de patrón de acceso: análisis que realizan particiones cruzadas límites: requiere un índice secundario en DynamoDB, pero Bigtable las maneja sin necesidad de usar un índice secundario. Del mismo modo, en DynamoDB, las operaciones de consulta y análisis están limitadas a 1 MB de datos. escaneados, lo que requiere una paginación superior a este límite. Bigtable no tiene límite.

A pesar de sus claves de partición distribuidas de forma aleatoria, DynamoDB aún puede tener datos particiones si una clave de partición elegida no distribuye de manera uniforme el tráfico que afecta negativamente la capacidad de procesamiento. Para abordar este problema, DynamoDB recomienda escritura-fragmentación, que divide las escrituras de forma aleatoria en múltiples particiones lógicas pares clave-valor.

Para aplicar este patrón de diseño, necesitas crear un número al azar a partir de un número establecer (por ejemplo, de 1 a 10) y, luego, usar este número como la partición lógica . Debido a que estás aleatorizando la clave de partición, las escrituras en la tabla se distribuida de manera uniforme entre todos los valores de clave de partición.

Bigtable se refiere a este procedimiento como alternamiento de claves, y puede ser una forma eficaz de evitar las tabletas calientes.

Control de versiones de datos

Cada celda de Bigtable tiene una marca de tiempo, y la marca de tiempo más reciente es siempre el valor predeterminado para cualquier columna. Un caso de uso común para las marcas de tiempo es el control de versiones: escribir una celda nueva en una columna diferenciada de versiones anteriores de los datos para esa fila y columna por su y marca de tiempo.

DynamoDB no tiene ese concepto y requiere diseños de esquemas complejos para admitir el control de versiones. Este enfoque implica crear dos copias de cada elemento: una copia con un prefijo de número de versión de cero, como v0_, al comienzo de la clave de clasificación y otra copia con el prefijo del número de versión uno, como v1_ Cada vez que se actualiza el elemento, se usa el siguiente prefijo de versión superior en la clave de orden de la versión actualizada y copia el contenido actualizado en el elemento con el prefijo de versión cero. Esto garantiza que la última versión de cualquier elemento pueda ubicarse con el prefijo cero. Esta estrategia no solo requiere la lógica de la aplicación para mantener, pero también hace que las escrituras de datos sean muy costosas y Lento, ya que cada escritura requiere una lectura del valor anterior más dos escrituras.

Transacciones de varias filas frente a capacidad de fila grande

Bigtable no admite transacciones de varias filas. Sin embargo, debido a que Te permite almacenar filas que son mucho más grandes que las de los elementos. Con DynamoDB, a menudo puedes obtener la transaccionalidad deseada diseñando tus esquemas para agrupar elementos relevantes en una clave de fila compartida Para un ejemplo que ilustre este enfoque; consulta Diseño de tabla única patrón.

Almacena valores grandes

Dado que un elemento de DynamoDB, que es análogo a una fila de Bigtable, se con un límite de 400 KB, para almacenar valores grandes, es necesario dividir entre elementos o almacenarlos en otros medios, como S3: Ambas opciones de estos enfoques agregan complejidad a tu aplicación. Por el contrario, un Una celda de Bigtable puede almacenar hasta 100 MB, admite hasta 256 MB.

Ejemplos de traducción de esquemas

Los ejemplos de esta sección traducen esquemas de DynamoDB a Bigtable con las diferencias clave en el diseño del esquema.

Migra esquemas básicos

Los catálogos de productos son un buen ejemplo para demostrar el patrón básico de clave-valor. A continuación, se muestra un esquema de este tipo en DynamoDB.

Clave primaria Atributos
Clave de partición Clave de clasificación Descripción Precio Miniatura
sombreros fedoras#marcaA Elaborada con lana de primera calidad... 30 https://storage…
sombreros fedora#marcaB Lona duradera y resistente al agua fabricada con... 28 https://storage…
sombreros newsboy#brandB Agrega un toque de encanto vintage a tu estilo diario. 25 https://storage…
zapatos sneakers#brandA Luce con estilo y comodidad con... 40 https://storage…
zapatos sneakers#brandB Funciones clásicas con materiales contemporáneos... 50 https://storage…

En esta tabla, la asignación de DynamoDB a Bigtable es sencillo: conviertes la clave primaria compuesta de DynamoDB en una compuesta Clave de fila de Bigtable. Creas una familia de columnas (SKU) que contenga el mismo conjunto de columnas.

SKU
Clave de fila Descripción Precio Miniatura
hats#fedoras#brandA Elaborada con lana de primera calidad... 30 https://storage…
hats#fedoras#brandB Lona duradera y resistente al agua fabricada con... 28 https://storage…
hats#newsboy#brandB Agrega un toque de encanto vintage a tu estilo diario. 25 https://storage…
zapatos#calzado deportivo#marcaA Luce con estilo y comodidad con... 40 https://storage…
zapatos#calzado deportivo#marcaB Funciones clásicas con materiales contemporáneos... 50 https://storage…

Patrón de diseño de una sola tabla

Un patrón de diseño de una sola tabla reúne lo que serían múltiples tablas en una base de datos relacional en una sola tabla en DynamoDB. Puedes adoptar el enfoque en el ejemplo anterior y duplicarlo tal como está en Bigtable. Sin embargo, es mejor abordar los problemas del esquema el proceso.

En este esquema, la clave de partición contiene el ID único de un video, el cual te ayuda a colocar todos los atributos relacionados con ese video para un acceso más rápido. Proporcionado Limitaciones de tamaño de los elementos de DynamoDB, no se puede incluir una cantidad ilimitada de texto libre. comentarios en una sola fila. Por lo tanto, una clave de ordenación con el patrón VideoComment#reverse-timestamp se usa para que cada comentario sea una fila independiente. dentro de la partición, en orden cronológico inverso.

Supongamos que este video tiene 500 comentarios y que el propietario quiere eliminar el video. Esto significa que también se deben borrar todos los comentarios y atributos del video. Para hacer esto en DynamoDB, debes escanear todas las claves dentro de esta partición y y, luego, envían varias solicitudes de eliminación y las iteran en cada una de ellas. DynamoDB admite transacciones de varias filas, pero esta solicitud de eliminación es demasiado grande para hacerla en una sola transacción.

Clave primaria Atributos
Clave de partición Clave de clasificación UploadDate Formatos
0123 Video 2023-09-10T15:21:48 {"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage..."}
Comentario del video n.o 98765481 Contenido
Realmente me gusta esto. Los efectos especiales son increíbles.
Comentario del video#86751345 Contenido
Se produjo un error de audio a la 1:05.
VideoStatsLikes Recuento
3
VideoStatsViews Recuento
156
0124 Video 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
Comentario del video#97531849 Contenido
Compartí esto con todos mis amigos.
Comentario del video#87616471 Contenido
El estilo me recuerda a un director de cine, pero no puedo explicarlo que la modifica.
VideoStats ViewCount
45

Modifica este esquema mientras migras para simplificar tu código y hacer solicitudes de datos de forma más rápida y económica. Las filas de Bigtable tienen un tamaño que los elementos de DynamoDB y pueden manejar una gran cantidad de comentarios. Para si un video recibe millones de comentarios, puedes configurar un contenido no utilizado política de recopilación para mantener solo una número de comentarios más recientes.

Porque los contadores se pueden actualizar sin la sobrecarga de actualizar toda la tampoco tienes que dividirlos. No es necesario usar UploadDate. o calcular una marca de tiempo inversa y hacer que tu clave de ordenación porque las marcas de tiempo de Bigtable te dan la opción comentarios ordenados automáticamente. Esto simplifica significativamente el esquema y, si se quita un video, puedes quitar de forma transaccional la fila del video, incluida la todos los comentarios en una sola solicitud.

Por último, debido a que las columnas en Bigtable se ordenan lexicográficamente, como optimización, puedes cambiar el nombre de las columnas de modo que permite un escaneo de rango rápido, desde propiedades de video hasta la N más alta de la más reciente comentarios, en una sola solicitud de lectura, que es lo que querrás hacer cuando se cargó el video. Luego, puedes revisar el resto de los comentarios se desplaza el visualizador.

Atributos
Clave de fila Formatos Me gusta Vistas UserComments
0123 {"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48 3 156 Realmente me gusta esto. Los efectos especiales son increíbles. @ 2023-09-10T19:01:15
Se produjo un error de audio a la 1:05. @ 10-09-2023T16:30:42
0124 {"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21 45 El estilo me recuerda a un director de cine, pero no puedo explicarlo que la modifica. @2023-10-12T07:08:51

Patrón de diseño de lista de adyacentes

Considera una versión ligeramente diferente de este diseño, que DynamoDB suele se refiere al patrón de diseño de lista de adjecencia.

Clave primaria Atributos
Clave de partición Clave de clasificación DateCreated Detalles
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":"Juan...",
“address":"St 123 Abc...}
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..."}

En esta tabla, las claves de orden no se basan en el tiempo, sino en los IDs de pago. así que puedes usar un patrón de columna ancha diferente y hacer que esos IDs en Bigtable, con beneficios similares a los anteriores ejemplo.

Factura Pago
clave de fila Detalles 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":"Juan...",
"address":"123 Abc St..."} a las 2023-09-10T15:21:40		 {"amount_usd": 120, "bill_to":"Jane...",
"address":"13 Xyz St..."}
@ 10-09-2023T15:21:31
clave de fila Detalles 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 puedes ver en los ejemplos anteriores, con el diseño de esquema correcto, El modelo de columnas anchas de Bigtable puede ser bastante potente y ofrecer que requerirían transacciones costosas de varias filas, la indexación o el comportamiento en cascada de otras bases de datos.

¿Qué sigue?