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 detalles de interacción difieren en formas que es importante 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 recursos. DynamoDB es un producto sin servidores, y el nivel más alto de interacción con DynamoDB es el nivel de la tabla. En el modo de capacidad aprovisionada, es aquí donde aprovisionas tus unidades de solicitudes de lectura y escritura, seleccionas tus regiones y replicación, y administras las copias de seguridad. Bigtable no es un producto sin servidor. Debes crear una instancia con uno o más clústeres, cuya capacidad se determina según la cantidad de nodos que tienen. Para obtener detalles sobre estos recursos, consulta Instancias, clústeres y nodos.

En la siguiente tabla, se comparan los recursos del plano de control de DynamoDB y Bigtable.

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

Clúster: Es un grupo de nodos en la misma zona geográfica de Google Cloud, que se usa para reducir los problemas de latencia y replicación. Para administrar la capacidad, se ajusta 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 leer y escribir datos. La cantidad de nodos que tiene un clúster se traduce en límites de capacidad de procesamiento para las 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: Es un bloque de filas contiguas, respaldado por unidades de estado sólido (SSD) ubicadas junto con los nodos.

Cada partición está sujeta a un límite estricto de 1,000 WCUs, 3,000 RCUs y 10 GB de datos.		 Tableta: Es un bloque de filas contiguas respaldadas por el medio de almacenamiento que elijas (SSD o HDD).

Las tablas se fragmentan en tablets para equilibrar la carga de trabajo. Las tablets no se almacenan en nodos de Bigtable, sino en el sistema de archivos distribuido de Google, que permite la redistribución rápida de los datos cuando se escala y proporciona durabilidad adicional, ya que mantiene 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 de atribución.

Replicación geográfica

La replicación se usa para satisfacer los requisitos de los clientes en los siguientes casos:

  • 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 cargas de trabajo cuando necesitas implementar una carga de trabajo por lotes en un clúster y depender de la replicación para entregar clústeres.

Bigtable admite clústeres replicados en tantas zonas como estén disponibles en hasta 8 regiones de Google Cloud en las que Bigtable esté disponible. La mayoría de las regiones tienen tres zonas. Bigtable replica automáticamente los datos en los clústeres en una topología multiprincipal, 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 tiene 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 Tiene 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 tabla. Nivel de la instancia.

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

Nivel regional.

Replicación automática entre réplicas mediante la conversión de una tabla en una tabla global.

Las tablas deben tener habilitadas las transmisiones de DynamoDB, y la transmisión debe contener las imágenes nuevas y las anteriores del elemento.

Borra una región para quitar la tabla global en esa región.		 Crea 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 una instancia de Bigtable.
Opciones de replicación Por tabla. Por instancia.
Disponibilidad y enrutamiento del tráfico Tráfico enrutado 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.
Los costos se generan cuando la replicación se realiza en regiones o continentes.
ANS 99.999% 99.999%

Plano de datos

En la siguiente tabla, se comparan los conceptos de modelos de datos de 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 de manera inequívoca. identificable entre todos los demás elementos por su clave primaria. El tamaño máximo permitido es de 400 KB. Fila: Es una sola entidad 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 una familia de columnas para una columna. El identificador completo de una columna se expresa como familia-de-columnas:calificador-de-columna. 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 y marca de tiempo determinadas. Una celda contiene un valor que puede ser de hasta 100 MB.
Clave primaria: Es un identificador único para un elemento en una tabla. 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 en la que se encuentra el elemento. 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 con una concatenación de valores y delimitadores. El tamaño máximo permitido es de 4 KB.

Los calificadores de columnas se pueden usar para entregar un comportamiento equivalente al de la clave de ordenamiento de DynamoDB.

Las claves compuestas se pueden crear con claves de fila concatenadas y calificadores de columna.

Para obtener más detalles, consulta el ejemplo de traducción de esquemas en la sección Diseño de esquemas de este documento.
Tiempo de vida: Las marcas de tiempo de cada elemento determinan cuándo ya no se necesita un elemento. 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 cuándo ya no se necesita un elemento. Venció la recolección de elementos no utilizados elementos durante un proceso en segundo plano llamado compactación. Las políticas de recolección de elementos no utilizados se establecen en el nivel de familia de columnas y pueden borrar elementos no solo en función de su antigüedad, sino también según la cantidad de versiones que el usuario desea mantener. No es necesario que adaptes la capacidad para la compactación mientras ajustas el tamaño de tus clústeres.

Operaciones

Las operaciones del plano de datos te permiten realizar acciones de creación, lectura, actualización y eliminación (CRUD) 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, 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, un tipo de datos de columna o atributo determinado puede diferir de una fila o un elemento a otro. Sin embargo, las APIs de DynamoDB y Bigtable manejan los tipos de datos de diferentes maneras.

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

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

En la siguiente tabla, se comparan las diferencias en los tipos de datos entre DynamoDB y Bigtable.

DynamoDB Bigtable
Tipos escalares: Se muestran como tokens de descriptor de tipo de datos 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: Es una colección sin ordenar de elementos únicos. 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 su familia de columnas.
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 cómo se almacenan los datos. Entre las diferencias clave entre Bigtable y DynamoDB, se encuentra 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 tamaño más grande del elemento “antes” y “después”, incluso si la actualización involucra un subconjunto de los atributos del elemento. 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 que sea la única columna en una fila determinada o una entre miles. Para obtener más información, consulta Escritura simple.

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 sin límites son comunes, en especial 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 administra sin la necesidad de usar un índice secundario. De manera similar, en DynamoDB, las operaciones de consulta y análisis se limitan a 1 MB de datos analizados, lo que requiere paginación más allá de este límite. Bigtable no tiene ese 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, debes crear un número aleatorio a partir de un conjunto fijo (por ejemplo, de 1 a 10) y, luego, usar este número como clave de partición lógica. Debido a que estás aleatorizando la clave de partición, las operaciones de escritura en la tabla se distribuyen de manera uniforme entre todos los valores de la 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 más reciente siempre es el valor predeterminado de cualquier columna determinada. Un caso de uso común para las marcas de tiempo es el control de versiones: escribir una celda nueva en una columna que se diferencia de las versiones anteriores de los datos de esa fila y columna por su 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, debes usar el siguiente prefijo de versión superior en la clave de orden de la versión actualizada y copiar el contenido actualizado en el elemento con el prefijo de versión cero. Esto garantiza que se pueda encontrar la versión más reciente de cualquier elemento con el prefijo cero. Esta estrategia no solo requiere que se mantenga la lógica del lado de la aplicación, sino que también hace que las operaciones de escritura de datos sean muy costosas y lentas, ya que cada operación de escritura requiere una lectura del valor anterior más dos operaciones de escritura.

Transacciones de varias filas en comparación con la capacidad de filas grandes

Bigtable no admite transacciones de varias filas. Sin embargo, como te permite almacenar filas mucho más grandes que los elementos en DynamoDB, a menudo puedes obtener la capacidad de transacción deseada si diseñas 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.

Almacenamiento de valores grandes

Dado que un elemento de DynamoDB, que es análogo a una fila de Bigtable, se limita a 400 KB, el almacenamiento de valores grandes requiere dividir el valor entre los elementos o almacenarlo 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

En los ejemplos de esta sección, se traducen esquemas de DynamoDB a Bigtable teniendo en cuenta las diferencias clave en el diseño de esquemas.

Cómo migrar 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 cómo se vería un esquema de este tipo en DynamoDB.

Clave primaria Atributos
Clave de partición Clave de clasificación Descripción Precio Miniatura
sombreros sombreros#marcaA Elaborada con lana de primera calidad... 30 https://storage…
sombreros sombreros#marcaB Lona duradera y resistente al agua fabricada con... 28 https://storage…
sombreros periodista#marcaB 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…

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

SKU
Clave de fila Descripción Precio Miniatura
sombreros#fedoras#marcaA Hechos de lana premium… 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#zapatillas#marcaA Sal a la calle 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 tabla única reúne lo que serían varias tablas en una base de datos relacional en una sola tabla en DynamoDB. Puedes seguir el enfoque del ejemplo anterior y duplicar este esquema tal como está en Bigtable. Sin embargo, es mejor abordar los problemas del esquema en el proceso.

En este esquema, la clave de partición contiene el ID único de un video, lo que ayuda a ubicar 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 un número ilimitado de texto libre. comentarios en una sola fila. Por lo tanto, se usa una clave de orden con el patrón VideoComment#reverse-timestamp para hacer que cada comentario sea una fila independiente dentro de la partición, ordenada en orden cronológico inverso.

Supongamos que este video tiene 500 comentarios y el propietario quiere quitarlo. Esto significa que también se deben borrar todos los comentarios y atributos de video. Para hacerlo en DynamoDB, debes analizar todas las claves de esta partición y, luego, emitir varias solicitudes de eliminación, iterando por cada una. DynamoDB admite transacciones de varias filas, pero esta solicitud de eliminación es demasiado grande para realizarla 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..."}
VideoComment#98765481 Contenido
Realmente me gusta esto. Los efectos especiales son increíbles.
Comentario del video#86751345 Contenido
Parece que hay un error de audio en el minuto 1:05.
VideoStatsLikes Recuento
3
VideoStatsViews Recuento
156
0124 Video 2023-09-10T17:03:21 {"480": "https://storage…", "720": "https://storage…"}
VideoComment#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 manejar un caso en el que un video recibe millones de comentarios, puedes establecer una política de recolección de basura para conservar solo una cantidad fija de los comentarios más recientes.

Dado que los contadores se pueden actualizar sin la sobrecarga de actualizar toda la fila, tampoco tienes que dividirlos. Tampoco tienes que usar una columna UploadDate ni calcular una marca de tiempo inversa y establecerla como clave de orden, ya que las marcas de tiempo de Bigtable te proporcionan los comentarios ordenados de forma cronológica inversa automáticamente. Esto simplifica significativamente el esquema y, si se quita un video, puedes quitar de forma transaccional la fila del video, incluidos todos los comentarios, en una sola solicitud.

Por último, como las columnas de Bigtable están ordenadas lexicológicamente, como optimización, puedes cambiar el nombre de las columnas de una manera que permita un análisis de rango rápido (desde las propiedades de video hasta los N comentarios más recientes) en una sola solicitud de lectura, que es lo que te gustaría hacer cuando se carga 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 Me gusta mucho. Los efectos especiales son increíbles. @ 2023-09-10T19:01:15
Parece que hay un error de audio en el minuto 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 identificarlo. @2023-10-12T07:08:51

Patrón de diseño de lista de adyacentes

Considera una versión ligeramente diferente de este diseño, a la que DynamoDB a menudo se refiere como el patrón de diseño de lista de adyacencia.

Clave primaria Atributos
Clave de partición Clave de clasificación DateCreated Detalles
Factura-0123 Factura-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 Factura-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. por lo que puedes usar un patrón de columna ancha diferente y hacer que esos IDs columnas en Bigtable, con beneficios similares a los que ejemplo.

Factura Pago
clave de fila Detalles 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…"} @ 2023-09-10T15:21:40		 {"amount_usd": 120, "bill_to":"Jane…",
"address":"13 Xyz St…"}
@ 2023-09-10T15: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?