Bigtable para usuarios de DynamoDB

Este documento está dirigido a desarrolladores de DynamoDB y administradores de bases de datos que deseen migrar o diseñar aplicaciones para usarlas 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), proporcionar almacenamiento que escala verticalmente hasta petabytes de datos y tolerar fallas de nodos.

Si bien los conjuntos de atributos de estos servicios de bases de datos son similares, sus arquitecturas subyacentes y detalles de interacción difieren en formas que es importante entender antes de comenzar una migración. En este documento, se destacan las similitudes y diferencias entre los dos sistemas de bases de datos.

Plano de control

En DynamoDB y Bigtable, el plano de control te permite configurar la capacidad, así como 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 tabla. En el modo de capacidad aprovisionada, aquí es donde aprovisionas las unidades de solicitud de lectura y escritura, seleccionas las regiones y la replicación, y administras las copias de seguridad. Bigtable no es un producto sin servidores; debes crear una instancia con uno o más clústeres, cuya capacidad depende de la cantidad de nodos que tengan. 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 una clave primaria definida. Las tablas tienen 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 los que se producen la replicación y el enrutamiento de conexión. Las políticas de replicación se establecen a nivel de la instancia.

Clúster: Es un grupo de nodos en la misma zona geográfica de Google Cloud, ubicado idealmente con tu servidor de aplicaciones por motivos de latencia y replicación. La capacidad se administra ajustando la cantidad de nodos en cada clúster.

Tabla: Una organización lógica de los valores que se indexan 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): Son unidades que permiten operaciones de lectura o escritura por segundo con un tamaño de carga útil fijo. Se te cobra por las unidades de lectura o escritura por cada operación con cargas útiles 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 los 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 los límites de capacidad de procesamiento para las operaciones de lectura, escritura y análisis. Puedes ajustar la cantidad de nodos según la combinación de tus objetivos de latencia, el recuento de solicitudes y el tamaño de la carga útil.

Los nodos de SSD entregan la misma capacidad de procesamiento para las operaciones de lectura y escritura, a diferencia de la diferencia significativa entre RCU y WCU. Si deseas obtener más información, consulta Rendimiento de cargas de trabajo típicas.
Partición: Es un bloque de filas contiguas, respaldado por unidades de estado sólido (SSD) ubicadas con nodos.

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

Las tablas se fragmentan en tablets para balancear la carga de trabajo. Las tablets no se almacenan en los nodos de Bigtable, sino en el sistema de archivos distribuidos de Google, que permite una redistribución rápida de los datos durante el escalamiento y proporciona durabilidad adicional a través del mantenimiento de varias copias.
Tablas globales: Una forma de aumentar la disponibilidad y durabilidad de los datos mediante la propagación automática de los cambios de datos en varias regiones. Replicación: Es una forma de aumentar la disponibilidad y la durabilidad de los datos mediante la propagación automática de los cambios de datos en varias regiones o varias zonas dentro de la misma región.
No aplicable (N/A) Perfil de aplicación: Configuración que le indica a Bigtable cómo enrutar una llamada a la API del cliente al clúster apropiado en la instancia. También puedes usar un perfil de app como etiqueta para segmentar las métricas de atribución.

Replicación geográfica

La replicación se usa para satisfacer los requisitos del cliente en cuanto a lo siguiente:

  • Alta disponibilidad para la continuidad del negocio en caso de una falla zonal o regional
  • Colocar los datos del servicio cerca de los usuarios finales para entregar entregas de latencia baja en cualquier lugar del mundo
  • Aislamiento de la carga de trabajo cuando necesitas implementar una carga de trabajo por lotes en un clúster y depender de la replicación en los clústeres de entrega

Bigtable admite clústeres replicados en tantas zonas que estén disponibles en un máximo de 8 regiones de Google Cloud en las que Bigtable esté disponible. La mayoría de las regiones tiene tres zonas. Bigtable replica de forma automática los datos entre los clústeres en una topología principal múltiple, lo que significa que puedes leer y escribir en cualquier clúster. La replicación de Bigtable tiene coherencia eventual. Para obtener más detalles, consulta la 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 principales múltiples y se replican automáticamente en todas las 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 Coherencia eventual.

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

Coherencia en la lectura de tus escrituras a nivel regional para todas las tablas.
Latencia de replicación No hay acuerdo de nivel de servicio (ANS).

Segundos		 Sin ANS.

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

Una instancia puede contener varias tablas.
Implementación Crear una tabla global con una réplica de 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 el flujo debe contener las imágenes nuevas y las antiguas 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 en 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.
Enrutamiento del tráfico y disponibilidad El tráfico se enruta a la réplica geográfica más cercana.

En caso de que se produzca una falla, aplicas una lógica empresarial personalizada para determinar cuándo redireccionar las solicitudes a otras regiones.		 Usa perfiles de aplicaciones 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 de forma automática al clúster en buen estado más cercano.

En caso de falla, Bigtable admite la conmutación por error automática entre clústeres para la alta disponibilidad.
Escalamiento La capacidad de escritura en las unidades de solicitud de escritura replicadas (R-WRU) se sincroniza entre réplicas.

La capacidad de lectura en unidades de capacidad de lectura replicadas (R-RCU) es por réplica.		 Puedes escalar los 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 se aplican costos de replicación de redes 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 de DynamoDB y Bigtable. Cada fila de la tabla describe atributos análogos. Por ejemplo, un elemento en DynamoDB es similar a una fila en Bigtable.

DynamoDB Bigtable
Elemento: grupo de atributos que se puede identificar de manera única entre todos los demás elementos por su clave primaria. El tamaño máximo permitido es de 400 KB. Fila: es una entidad única identificada por la clave de fila. El tamaño máximo permitido es 256 MB.
No disponible Familia de columnas: Es un espacio de nombres especificado por el usuario que agrupa columnas.
Atributo: Es una agrupación de un nombre y un valor. El valor del atributo puede ser un escalar, un conjunto o un tipo de documento. No hay límite explícito en el tamaño del atributo en sí. Sin embargo, debido a que cada elemento tiene un límite de 400 KB, en el caso de un elemento que solo tiene un atributo, el atributo puede ser de hasta 400 KB menos el tamaño ocupado por el nombre del atributo. Calificador de columnas: Es el identificador único dentro de una familia de columnas para una columna. El identificador completo de una columna se expresa como column-family:column-qualifier. Los calificadores de columnas se ordenan de manera 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: Un identificador único para un elemento en una tabla. Puede ser una clave de partición o una clave compuesta.

Clave de partición: Es una clave primaria simple compuesta por un atributo. 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 orden: 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 una clave de orden o atributo de rango.		 Clave de fila: Un identificador único para un elemento en 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.

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

Las claves compuestas se pueden compilar mediante claves de fila concatenadas y calificadores de columnas.

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 actividad: Las marcas de tiempo por elemento determinan cuándo ya no se necesita un elemento. Después de la fecha y hora de la marca de tiempo especificada, el elemento se borra de la tabla sin consumir ninguna capacidad de procesamiento de escritura. Recolección de elementos no utilizados: las marcas de tiempo por celda determinan cuándo un elemento ya no es necesario. La recolección de elementos no utilizados borra los elementos vencidos durante un proceso en segundo plano llamado compactación. Las políticas de recolección de elementos no utilizados se establecen a nivel de familia de columnas y pueden borrar elementos no solo según su antigüedad, sino también según la cantidad de versiones que el usuario desea mantener. No necesitas adaptar la capacidad de compactación mientras ajustas el tamaño de los clústeres.

Operaciones

Las operaciones de 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 comparan las operaciones del plano de datos similares para DynamoDB y Bigtable.

DynamoDB Bigtable
CreateTable CreateTable
PutItem
BatchWriteItem		 MutateRow
MutateRows
Bigtable trata las operaciones de escritura como inserciones y actualizaciones.
UpdateItem
  • Escritura condicional
  • Incremento y disminución
Bigtable trata las operaciones de escritura como actualizaciones.
GetItem
BatchGetItem, Query y Scan		 “ReadRow”
“ReadRows” (rango, prefijo, análisis inverso)
Bigtable admite el 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 esquemas. Las columnas se pueden definir en el momento de la escritura sin ninguna aplicación forzosa en toda la tabla para la existencia de la columna o los tipos de datos. Del mismo modo, un tipo de datos de columna o atributo determinado puede diferir de una fila o elemento a otro. Sin embargo, las APIs de DynamoDB y Bigtable manejan los tipos de datos de maneras diferentes.

Cada solicitud de escritura de DynamoDB incluye una definición de tipo para cada atributo, que se muestra con la respuesta para 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 el cliente pueda analizar las respuestas de forma correcta. Una excepción son las operaciones de incremento, que interpretan los valores como números enteros firmados de big-endian de 64 bits.

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 la aplicación cliente.

Increment interpreta el valor como un número entero de 64 bits con firma y big-endian.
Conjunto: es una colección sin ordenar de elementos únicos. Familia de columnas: Puedes usar calificadores de columnas como nombres de miembros establecidos y, para cada uno, proporcionar un solo byte 0 como valor de celda. Los miembros del conjunto se ordenan de manera lexicográfica dentro de su familia de columnas.
Mapa: es un conjunto 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. Las claves de mapa 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 del comportamiento list_append, en orden inverso 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. Una de las diferencias clave entre Bigtable y DynamoDB es cómo manejan lo siguiente:

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

Actualizaciones a valores únicos

Las operaciones UpdateItem en DynamoDB consumen la capacidad de escritura para los tamaños de elementos "antes" y "después" más grandes, incluso si la actualización involucra un subconjunto de los atributos del elemento. Esto significa que en DynamoDB, puedes colocar columnas que se actualizan con frecuencia en filas separadas, incluso si lógicamente pertenecen 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 dada o una entre miles de columnas. Para obtener más detalles, consulta Escrituras simples.

Ordenación de datos

DynamoDB genera hashes y distribuye 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 usuario realice el hash.

La distribución aleatoria de claves no es óptima para todos los patrones de acceso. Reduce el riesgo de rangos de filas calientes, pero hace que los patrones de acceso que implican análisis que cruzan los límites de partición sean ineficientes y costosos. Estos análisis no delimitados son comunes, en especial para casos de uso que tienen una dimensión de tiempo.

El manejo de este tipo de patrón de acceso (análisis que analiza los límites de particiones cruzadas) requiere un índice secundario en DynamoDB, pero Bigtable lo controla sin la necesidad de un índice secundario. De manera similar, en DynamoDB, las operaciones de consulta y análisis se limitan a 1 MB de datos analizados, por lo que se requiere una paginación que supere este límite. Bigtable no tiene ese límite.

A pesar de las claves de partición distribuidas de forma aleatoria, DynamoDB aún puede tener particiones activas si la clave de partición elegida no distribuye de manera uniforme el tráfico que afecta la capacidad de procesamiento de forma negativa. Para solucionar este problema, DynamoDB recomienda realizar la fragmentación de escritura, mediante la división aleatoria de las escrituras en varios valores de claves de partición lógica.

Para aplicar este patrón de diseño, debes crear un número al azar a partir de un conjunto fijo (por ejemplo, del 1 al 10) y, luego, usarlo como la clave de partición lógica. Debido a que aleatorizas la clave de partición, las escrituras en la tabla se distribuyen de manera uniforme entre todos los valores de clave de partición.

Bigtable se refiere a este procedimiento como salud de claves, y puede ser una forma eficaz de evitar las tablets 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 de cualquier columna. Un caso de uso común para las marcas de tiempo es el control de versiones, es decir, 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 esquema complejos para admitir el control de versiones. Este enfoque implica crear dos copias de cada elemento: una con un prefijo de número de versión de cero, como v0_, al comienzo de la clave de clasificación, y otra con un prefijo de número de versión de uno, como v1_. Cada vez que se actualice el elemento, usarás el siguiente prefijo de versión más alto en la clave de clasificación de la versión actualizada y copiarás el contenido actualizado en el elemento con el prefijo de versión cero. Esto garantiza que la versión más reciente de cualquier elemento se pueda encontrar con el prefijo cero. Esta estrategia no solo requiere mantener la lógica de la aplicación, sino que también hace que las escrituras de datos sean muy costosas y lentas, ya que cada escritura requiere una lectura del valor anterior más dos escrituras.

Transacciones de varias filas en comparación con la capacidad de fila grande

Bigtable no admite transacciones de varias filas. Sin embargo, debido a que te permite almacenar filas mucho más grandes que los elementos que pueden tener DynamoDB, a menudo puedes obtener la transaccionalidad deseada si diseñas tus esquemas para agrupar elementos relevantes en una clave de fila compartida. Para ver un ejemplo que ilustre este enfoque, consulta Patrón de diseño de tabla única.

Almacena valores grandes

Dado que un elemento de DynamoDB, que es análogo a una fila de Bigtable, está limitado a 400 KB, el almacenamiento de valores grandes requiere dividir el valor entre los elementos o almacenarlo en otros medios como S3. Ambos enfoques agregan complejidad a tu aplicación. Por el contrario, una celda de Bigtable puede almacenar hasta 100 MB, y una fila de Bigtable puede admitir 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 de diseño de esquema clave.

Migra esquemas básicos

Los catálogos de productos son un buen ejemplo para demostrar el patrón básico de par clave-valor. A continuación, se muestra cómo podría verse ese esquema en DynamoDB.

Clave primaria Atributos
Clave de partición Ordenar por clave Descripción Price Miniatura
sombreros sombreros de fieltro#marcaA Elaborado con lana de primera... 30 https://storage…
sombreros sombreros de fieltro#marcaB Lienzo resistente al agua diseñado para... 28 https://storage…
sombreros reportaje#marcaB Agrega un toque de encanto vintage a tu look diario. 25 https://storage…
zapatos calzado deportivo#marcaA Sal con estilo y comodidad con... 40 https://storage…
zapatos calzado deportivo#marcaB Características clásicas con materiales contemporáneos... 50 https://storage…

Para esta tabla, la asignación de DynamoDB a Bigtable es sencilla: 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 Price Miniatura
sombreros#sombreros#marcaA Elaborado con lana de primera... 30 https://storage…
sombreros#sombreros#marcaB Lienzo resistente al agua diseñado para... 28 https://storage…
sombreros#mujer#marcaB Agrega un toque de encanto vintage a tu look diario. 25 https://storage…
zapatos#zapatillas#marcaA Sal con estilo y comodidad con... 40 https://storage…
zapatos#zapatillas#marcaB Características clásicas con materiales contemporáneos... 50 https://storage…

Patrón de diseño de tabla única

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 usar 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, que ayuda a colocar todos los atributos relacionados con ese video para un acceso más rápido. Dadas las limitaciones de tamaño de elementos de DynamoDB, no puedes colocar una cantidad ilimitada de comentarios de texto libre 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 separada dentro de la partición, ordenada en orden cronológico inverso.

Supongamos que este video tiene 500 comentarios y el propietario quiere eliminarlo. Esto significa que también se deben borrar todos los comentarios y atributos de video. Para hacerlo en DynamoDB, debes analizar todas las claves dentro de esta partición y, luego, emitir varias solicitudes de eliminación, iterando a través de cada una. DynamoDB admite transacciones de varias filas, pero esta solicitud de eliminación es demasiado grande para hacerlo en una sola transacción.

Clave primaria Atributos
Clave de partición Ordenar por clave UploadDate Formatos
0123 Video 2023-09-10T15:21:48 {"480": "https://storage...", "720": "https://storage...", "1080p": "https://storage..."}
Comentario en el video#98765481 Contenido
Esto me gusta mucho. Los efectos especiales son asombrosos.
Comentario en el video#86751345 Contenido
Parece que hay una falla 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 en el video#97531849 Contenido
Compartí esto con todos mis amigos.
Comentario en el video#87616471 Contenido
El estilo me recuerda al director de una película, pero no lo puedo identificar.
VideoStats ViewCount
45

Modifica este esquema a medida que migres para que puedas simplificar tu código y hacer que las solicitudes de datos sean más rápidas y económicas. Las filas de Bigtable tienen una capacidad mucho mayor 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 elementos no utilizados para mantener solo una cantidad fija de comentarios más recientes.

Debido a que los contadores se pueden actualizar sin la sobrecarga de actualizar toda la fila, tampoco tienes que dividirlos. Tampoco necesitas usar una columna UploadDate o calcular una marca de tiempo inversa ni hacer esa clave de orden, ya que las marcas de tiempo de Bigtable te proporcionan de forma automática los comentarios ordenados cronológicamente de forma inversa. Esto simplifica en gran medida 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, debido a que las columnas en Bigtable están ordenadas lexicográficamente, como optimización, puedes cambiar el nombre de las columnas de una manera que permita un análisis de rango rápido, desde propiedades de video hasta los N comentarios principales más recientes, en una sola solicitud de lectura, que es lo que deseas hacer cuando se carga el video. Luego, puedes hojear el resto de los comentarios a medida que el usuario se desplaza.

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 Esto me gusta mucho. Los efectos especiales son asombrosos. @ 2023-09-10T19:01:15
Parece haber una falla 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 al director de una película, pero no lo puedo identificar. @2023-10-12T07:08:51

Patrón de diseño de la lista de adyacentes

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

Clave primaria Atributos
Clave de partición Ordenar por clave 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":"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..."}

En esta tabla, las claves de orden no se basan en el tiempo, sino en los ID de pago, por lo que puedes usar un patrón de columnas anchas diferente y hacer que esos ID separen columnas en Bigtable, con beneficios similares a los del ejemplo anterior.

Facturas Pago
tecla de fila Detalles 0680 789
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 2275 322
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 columna ancha de Bigtable puede ser bastante potente y entregar muchos casos prácticos que requerirían transacciones costosas de varias filas, indexación secundaria o un comportamiento en cascada de eliminación en otras bases de datos.

¿Qué sigue?