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 base de datos son similares, sus arquitecturas subyacentes y los 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 estos dos sistemas de base de datos.

Plano de control

En DynamoDB y Bigtable, el plano de control te permite configurar tu capacidad y establecer 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, debes aprovisionar las unidades de solicitud de lectura y escritura, 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.

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 configuración para las copias de seguridad, la replicación y la capacidad. Instancia: Es 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 conexiones. 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, ubicados idealmente con tu servidor de aplicaciones por motivos de latencia y replicación. La capacidad se administra mediante el ajuste de la cantidad de nodos en cada clúster.

Tabla: Es una organización lógica de valores que se indexan según la 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): Unidades que permiten lecturas o escrituras 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 tamaños de 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 esta implica un subconjunto de los atributos del elemento.		 Nodo: Es un recurso de procesamiento virtual responsable de la lectura y la escritura de datos. La 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 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 entregan 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 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 de elección (SSD o HDD).

Las tablas se fragmentan en tablets para equilibrar la carga de trabajo. Los tablets no se almacenan en nodos en 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 mediante el mantenimiento de varias copias.
Tablas globales: 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. 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 adecuado de la instancia. También puedes usar un perfil de app como 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 respecto de lo siguiente:

  • Alta disponibilidad para la continuidad empresarial en caso de falla zonal o regional
  • Coloca los datos de tu servicio cerca de los usuarios finales para entregar entregas de baja latencia 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 clústeres de entrega

Bigtable admite clústeres replicados en la mayor cantidad de zonas que estén disponibles hasta en 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 entre clústeres con 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 instancias principales múltiples y se replican de forma automática 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 las operaciones de lectura y escritura 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 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 región seleccionada

Nivel regional.

Convierte una tabla en una tabla global para la replicación automática en las réplicas.

Las tablas deben tener habilitadas las transmisiones de DynamoDB, que deben contener las imágenes nuevas y las antiguas del elemento.

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 una instancia de Bigtable.
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 la 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 de los clústeres.

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 el caso de una falla, Bigtable admite la conmutación por error automática entre clústeres para 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 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 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 los 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
Elemento: es un grupo de atributos que se identifica de manera inequívoca 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 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. El valor de un atributo puede ser de tipo escalar, conjunto o de documento. No hay un límite explícito para el tamaño del atributo en sí. Sin embargo, debido a que cada elemento está limitado a 400 KB, para un elemento que solo tiene un atributo, este puede ser de hasta 400 KB menos el tamaño que ocupa 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: Es un identificador único para un elemento de una tabla. Puede ser una clave de partición o una clave compuesta.

Clave de partición: una clave primaria simple compuesta por un atributo. Esto determina la partición física en la que se ubica 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: 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.

Los calificadores de columnas se pueden usar para proporcionar un comportamiento equivalente al de la clave de orden 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 un elemento ya no es necesario. 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 la 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 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 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. Las columnas se pueden definir en el momento de la escritura sin ninguna aplicación forzosa en toda la tabla para la existencia de columna o los tipos de datos. Del mismo modo, una columna o un tipo de datos de atributo determinados pueden diferir entre una fila o un elemento. Sin embargo, las APIs de DynamoDB y Bigtable trabajan con 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 junto 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 el cliente pueda analizar las respuestas correctamente. Una excepción son las operaciones de increment, que interpretan los valores como números enteros con firma big-endian de 64 bits.

En la siguiente tabla, se comparan las diferencias de 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 a los tipos previstos en la aplicación cliente.

Increment interpreta el valor como un número entero con firma big-endian de 64 bits.
Conjunto: Una colección sin ordenar de elementos únicos. Familia de columnas: puedes usar calificadores de columna 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: 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. 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 de list_append, en sentido inverso a 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 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 para el tamaño más grande de los elementos "antes" y "después", incluso si la actualización involucra un subconjunto de los atributos del elemento. Esto significa que, en DynamoDB, puedes colocar las 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 detalles, 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 usuario realice un hash.

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

Para controlar este tipo de patrón de acceso (análisis de límites de partición cruzada), se requiere un índice secundario en DynamoDB, pero Bigtable lo administra sin necesidad de un índice secundario. De manera similar, en DynamoDB, las operaciones de consulta y análisis están limitadas a 1 MB de datos analizados, por lo que se requiere una paginación superior a 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 particiones en caliente si una clave de partición elegida no distribuye de manera uniforme el tráfico que afecta negativamente la capacidad de procesamiento. Para solucionar este problema, DynamoDB recomienda la fragmentación de escritura, que consiste en dividir de forma aleatoria las escrituras 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, del 1 al 10) y, luego, usarlo como clave de partición lógica. Debido a que estás aleatorizando 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 saldo de claves, y puede ser una forma eficaz de evitar las tablets sobrecargadas.

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, es decir, escribir una celda nueva en una columna que se diferencia de las versiones anteriores de los datos para 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 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, se usa el siguiente prefijo de versión superior en la clave de clasificación de la versión actualizada y se copia 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 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 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 los elementos que pueden estar en 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, tiene un límite de 400 KB, el almacenamiento de valores grandes requiere dividir el valor entre los elementos o almacenarlos 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 los esquemas de DynamoDB a Bigtable teniendo en cuenta las diferencias de diseño de los esquemas clave.

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 Price 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 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…

En 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#fedora#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#noticias#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…

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 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, lo 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 los 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 que el propietario quiere eliminar el video. Esto significa que también se deben borrar todos los comentarios y atributos del video. Para hacerlo en DynamoDB, debes escanear 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 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.
VideoStats ViewCount
45

Modifica este esquema a medida que migras para simplificar tu código y realizar solicitudes de datos de manera más rápida y económica. 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 obtiene millones de comentarios, puedes establecer una política de recolección de elementos no utilizados para mantener solo un número fijo de comentarios más recientes.

Debido a que los contadores se pueden actualizar sin la sobrecarga de actualizar toda la fila, tampoco es necesario que los dividas. No tienes que usar una columna UploadDate ni calcular una marca de tiempo inversa y hacer que sea tu clave de orden, ya que las marcas de tiempo de Bigtable te brindan los comentarios ordenados cronológicamente de forma inversa de forma automática. 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, debido a que las columnas en Bigtable están ordenadas lexicográficamente, como una 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 más recientes principales, en una sola solicitud de lectura, que es lo que se recomienda hacer cuando se carga el video. Luego, puedes revisar el resto de los comentarios mientras 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 Realmente me gusta esto. Los efectos especiales son increíbles. @ 2023-09-10T19:01:15
Parece haber una falla de audio a la hora 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. @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 suele denominar el patrón de diseño de listas adyacentes.

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 ID de pago, por lo que puedes usar un patrón de columna ancha diferente y hacer que esos ID se diferentes en columnas en Bigtable, con beneficios similares al ejemplo anterior.

Facturas 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 prácticos 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?