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 usar con Bigtable como almacén de datos. Antes de leer este documento, lee la descripción general de Bigtable.

Bigtable y DynamoDB son almacenes de pares clave-valor distribuidos que pueden admitir millones de consultas por segundo (QPS), proporcionar almacenamiento que escala hasta petabytes de datos y tolerar fallas de 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 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 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: Es una colección de elementos con una clave primaria definida. 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 la 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: Es una organización lógica de valores que 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): Son unidades que permiten operaciones de lectura o escritura por segundo con un tamaño de carga útil fijo. Se te cobran unidades de lectura o escritura por cada operación 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 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 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 SSD proporcionan la misma capacidad de procesamiento para las operaciones de lectura y escritura, a diferencia de la diferencia significativa entre la RCU y la 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 tablas 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: Son una forma de aumentar la disponibilidad y durabilidad de tus datos, ya que propagan automáticamente los cambios de datos en varias regiones. Replicación: Es una forma de aumentar la disponibilidad y la durabilidad de tus datos, ya que propaga automáticamente los cambios de datos en varias regiones o en varias zonas dentro de la misma región.
No aplicable (N/A) Perfil de aplicación: Es la configuración que le indica a Bigtable cómo enrutar una llamada a la API de 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 del negocio en caso de una falla regional o zonal.
  • Colocar los datos de tu servicio cerca de los usuarios finales para la entrega de baja latencia dondequiera que estén en el 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. Para obtener más información, consulta Regiones y 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 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 multiprincipales 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 varios primarios 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 tablas globales.		 Tiene coherencia eventual.

Coherencia en la lectura de tus escrituras a nivel del clúster para todas las tablas, siempre que envíes las operaciones de lectura y escritura al mismo clúster.
Latencia de replicación No hay un 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.

La replicación automática entre réplicas se realiza convirtiendo 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 antiguas del elemento.

Borra una región para quitar la tabla global de esa región.		 Crea una instancia con más de un clúster.
La replicación es automática en todos 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, aplicas una lógica empresarial personalizada para determinar cuándo redireccionar las solicitudes a otras regiones.		 Usa 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 falla, Bigtable admite la conmutación por error automática entre clústeres para la HA.
Escalamiento La capacidad de escritura en las unidades de solicitud de escritura replicadas (R-WRU) se sincroniza entre las 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 agregando o quitando 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 características análogas. Por ejemplo, un elemento en DynamoDB es similar a una fila en Bigtable.

DynamoDB Bigtable
Elemento: Es un grupo de atributos que se puede identificar de forma única 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: Es un espacio de nombres especificado por el usuario que agrupa columnas.
Atributo: Es una agrupación de un nombre y un valor. Un valor de atributo puede ser un tipo escalar, de conjunto o de documento. No hay un límite explícito para el tamaño del atributo. Sin embargo, como cada elemento está limitado a 400 KB, en el caso de un elemento que solo tiene un atributo, este puede tener hasta 400 KB menos el tamaño que ocupa el 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 se ordenan lexicográficamente dentro de la familia de columnas.

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


Celda: Es una celda que 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: 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: 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: Es una clave primaria compuesta por dos propiedades: la clave de partición y una clave de orden o un atributo de rango.		 Clave de fila: Es un identificador único para un elemento en 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 la hora de la marca de tiempo especificada, el elemento se borra de tu tabla sin consumir ninguna capacidad de procesamiento de escritura. Recolección de elementos no utilizados: Las marcas de tiempo por celda determinan cuándo ya no se necesita un elemento. 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 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 comparan operaciones similares del plano de datos 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 inserciones y actualizaciones.
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 adelante 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 columnas o 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 de 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 transmiten a los tipos previstos en la aplicación cliente.

Increment interpreta el valor como un número entero de 64 bits firmado como un valor 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 la celda. Los miembros del conjunto se ordenan de manera lexicográfica dentro de su familia de columnas.
Mapa: Es una colección no ordenada de pares clave-valor con claves únicas. Familia de columnas
Usa el calificador de columna como clave de mapa y el valor de la celda para el valor. Las claves del mapa se ordenan de manera lexicográfica.
Lista: Es una colección ordenada de elementos. Cualificador de columna
Usa la marca de tiempo de inserción para lograr el comportamiento equivalente de list_append, el inverso de la marca de tiempo de inserción para agregar al principio.

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 individuales
  • Ordenación de datos
  • Control de versiones de datos
  • Almacenamiento de valores grandes

Actualizaciones de valores individuales

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, 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 determinada o una entre miles. Para obtener más información, consulta Escritura simple.

Ordenación de datos

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

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

La administración de este tipo de patrón de acceso (análisis que cruzan los límites de la partición) requiere un índice secundario en DynamoDB, pero Bigtable lo controla sin necesidad de un índice secundario. Del mismo modo, 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 puede tener particiones activas si una clave de partición elegida no distribuye de forma uniforme el tráfico que afecta negativamente el rendimiento. Para abordar este problema, DynamoDB recomienda el fragmentación de escritura, que divide las operaciones de escritura de forma aleatoria en varios valores de clave de partición lógica.

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 saladura de claves, y puede ser una forma eficaz de evitar las tablets activas.

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 orden y otra copia con un prefijo de número de versión de uno, como v1_. Cada vez que se actualiza el elemento, debes usar el siguiente prefijo de versión más alto 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 ver un ejemplo que ilustre este enfoque, consulta Patrón de diseño de tabla única.

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. Ambos enfoques aumentan la complejidad de tu aplicación. En cambio, 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 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 par 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 Hechos de lana de primera calidad… 30 https://storage…
sombreros sombreros#marcaB Lona duradera y resistente al agua diseñada para… 28 https://storage…
sombreros 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 zapatillas#marcaB Elementos clásicos 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 de primera calidad… 30 https://storage…
sombreros#fedoras#marcaB Lona duradera y resistente al agua diseñada para… 28 https://storage…
sombreros#gorros gatsby#marcaB Agrega un toque de encanto vintage a tu estilo diario. 25 https://storage…
zapatos#zapatillas#marcaA Luce con estilo y comodidad con… 40 https://storage…
zapatos#zapatillas deportivas#marcaB Elementos clásicos 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 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. Debido a las limitaciones de tamaño de los elementos de DynamoDB, no puedes ingresar 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 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
Me gusta mucho. Los efectos especiales son increíbles.
VideoComment#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
Lo compartí con todos mis amigos.
VideoComment#87616471 Contenido
El estilo me recuerda a un director de cine, pero no puedo identificarlo.
VideoStats ViewCount
45

Modifica este esquema a medida que realices la migración para 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 más grande que los elementos de DynamoDB y pueden controlar 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 desplazarte por 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 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. @ 2023-09-10T16: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 adyacencia

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
Invoice-0123 Invoice-0123 2023-09-10T15:21:48 {"discount": 0.10,
"sales_tax_usd":"8",
"due_date":"2023-10-03.."}
Payment-0680 2023-09-10T15:21:40 {"amount_usd": 120, "bill_to":"John…",
"address":"123 Abc St…"}
Payment-0789 2023-09-10T15:21:31 {"amount_usd": 120, "bill_to":"Jane…",
"address":"13 Xyz St…"}
Invoice-0124 Invoice-0124 2023-09-09T10:11:28 {"discount": 0.20,
"sales_tax_usd":"11",
"due_date":"2023-10-03.."}
Payment-0327 2023-09-09T10:11:10 {"amount_usd": 180, "bill_to":"Bob…",
"address":"321 Cba St…"}
Payment-0275 2023-09-09T10:11:03 {"amount_usd": 70, "bill_to":"Kate…",
"address":"21 Zyx St…"}

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 separen columnas en Bigtable, con beneficios similares al ejemplo anterior.

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 muchos casos de uso que requerirían transacciones costosas de varias filas, indexación secundaria o comportamiento en cascada de eliminación en otras bases de datos.

¿Qué sigue?