Migrar de DynamoDB a Bigtable

Bigtable y DynamoDB son almacenes de pares clave-valor distribuidos que pueden admitir millones de consultas por segundo (CPS), proporcionar almacenamiento que se escala hasta petabytes de datos y tolerar fallos de nodos.

Este documento está dirigido a los desarrolladores de DynamoDB y a los administradores de bases de datos que quieran migrar a Bigtable. También es útil cuando quieres diseñar aplicaciones para usarlas con Bigtable como almacén de datos.

Para empezar, usa una herramienta de migración proporcionada por Google que te ayude a migrar de DynamoDB a Bigtable. En esta página se describe la herramienta de migración, se comparan los dos sistemas de bases de datos y se explica la arquitectura subyacente y los detalles de interacción que son diferentes y que es importante conocer antes de realizar la migración.

Empezar a usar la herramienta de migración de DynamoDB a Bigtable

Google Cloud Professional Services Google Cloud proporciona una herramienta de migración de código abierto para agilizar la migración de datos de DynamoDB a Bigtable. La herramienta automatiza el proceso de importar tus datos a Google Cloud y, a continuación, cargarlos en Bigtable.

Con esta herramienta, puedes exportar tu tabla de DynamoDB y, a continuación, transferirla a Cloud Storage. La herramienta lee los archivos exportados de tu segmento de Cloud Storage y usa una plantilla de Dataflow para transformar los datos de forma que sean compatibles con Bigtable. Esta transformación incluye la asignación de atributos de DynamoDB a filas de Bigtable. A continuación, el trabajo de Dataflow escribe los datos transformados en tu tabla de Bigtable.

Para obtener más información o empezar, consulta la utilidad de migración de DynamoDB a Bigtable.

Comparación entre DynamoDB y Bigtable

En esta sección se analizan las similitudes y las diferencias entre DynamoDB y Bigtable.

Plano de control

En DynamoDB y Bigtable, el plano de control te permite configurar tu capacidad y configurar y gestionar recursos. DynamoDB es un producto sin servidor y el nivel más alto de interacción con DynamoDB es el nivel de tabla. En el modo de capacidad aprovisionada, es donde aprovisionas tus unidades de solicitud de lectura y escritura, seleccionas tus regiones y la replicación, y gestionas las copias de seguridad. Bigtable no es un producto sin servidor. Debes crear una instancia con uno o varios clústeres, cuya capacidad se determina en función del número de nodos que tengan. Para obtener más información sobre estos recursos, consulta el artículo Instancias, clústeres y nodos.

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

DynamoDB	Bigtable
Tabla: conjunto de elementos con una clave principal definida. Las tablas tienen ajustes para copias de seguridad, replicación y capacidad.	Instancia: grupo de clústeres de Bigtable en diferentes Google Cloud zonas o regiones entre los que se produce la replicación y el enrutamiento de conexiones. Las políticas de replicación se definen a nivel de instancia. Clúster: grupo de nodos de la misma zona geográfica, idealmente ubicados en el mismo lugar que el servidor de aplicaciones por motivos de latencia y replicación.Google Cloud La capacidad se gestiona ajustando el número de nodos de cada clúster. Tabla: organización lógica de valores indexada por la clave de fila. Las copias de seguridad se controlan a nivel de 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 de cada operación con tamaños de carga útil más grandes.Las operaciones UpdateItem consumen la capacidad de escritura utilizada para el elemento actualizado de mayor tamaño, ya sea antes o después de la actualización, aunque esta implique un subconjunto de los atributos del elemento.	Nodo: recurso de computación virtual responsable de leer y escribir datos. El número de nodos de un clúster se traduce en límites de rendimiento para lecturas, escrituras y análisis. Puedes ajustar el número de nodos en función de la combinación de tus objetivos de latencia, el recuento de solicitudes y el tamaño de la carga útil. Los nodos SSD ofrecen el mismo rendimiento para las lecturas y las escrituras, a diferencia de la diferencia significativa entre RCU y WCU. Para obtener más información, consulta la sección Rendimiento de las cargas de trabajo típicas.
Partición: bloque de filas contiguas respaldado por unidades de estado sólido (SSD) ubicadas junto a los nodos. Cada partición está sujeta a un límite de 1000 WCUs, 3000 RCUs y 10 GB de datos.	Tabla: un bloque de filas contiguas respaldado 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 redistribuir los datos rápidamente al escalar y que proporciona una mayor durabilidad al mantener varias copias.
Tablas globales: una forma de aumentar la disponibilidad y la durabilidad de tus datos propagando automáticamente los cambios de datos en varias regiones.	Replicación: una forma de aumentar la disponibilidad y la durabilidad de tus datos propagando automáticamente los cambios de datos en varias regiones o en varias zonas de la misma región.
No aplicable (N/A)	Perfil de aplicación: ajustes que indican a Bigtable cómo enrutar una llamada a la API de un cliente al clúster adecuado de la instancia. También puede usar un perfil de aplicación como etiqueta para segmentar las métricas de atribución.

Replicación geográfica

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

• Alta disponibilidad para garantizar la continuidad de la actividad empresarial en caso de que se produzca un fallo en una zona o región.
• Colocar los datos de tu servicio cerca de los usuarios finales para ofrecerlos con baja latencia en cualquier parte del mundo.
• Aislamiento de cargas de trabajo cuando necesites implementar una carga de trabajo por lotes en un clúster y depender de la replicación en los clústeres de servicio.

Bigtable admite clústeres replicados en tantas zonas como estén disponibles en hasta 8 Google Cloud regiones 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 todos los clústeres de una topología multiprimario, lo que significa que puedes leer y escribir en cualquier clúster. La replicación de Bigtable acaba siendo coherente. Para obtener más información, consulta la descripción general de la replicación.

DynamoDB ofrece tablas globales para admitir la replicación de tablas en varias regiones. Las tablas globales son de varios primarios y se replican automáticamente en todas las regiones. La replicación acaba siendo coherente.

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 multiprimaria	Sí. Puedes leer y escribir en cualquier tabla global.	Sí. Puedes leer y escribir en cualquier clúster de Bigtable.
Modelo de coherencia	Coherencia final. Coherencia inmediata (read-your-writes) a nivel regional para tablas globales.	Coherencia final. Coherencia inmediata (read-your-writes) a nivel de clúster para todas las tablas, siempre que envíe tanto lecturas como escrituras al mismo clúster.
Latencia de replicación	No hay ningún acuerdo de nivel de servicio. segundos	Sin acuerdo de nivel de servicio. segundos
Granularidad de la configuración	Nivel de la tabla.	Nivel de 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 en todas las réplicas convirtiendo una tabla en una tabla global. Las tablas deben tener habilitado DynamoDB Streams, con el stream que contenga tanto las imágenes nuevas como las antiguas del elemento. Elimina 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 entre los clústeres de esa instancia. Nivel de zona. Añadir y quitar 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 dirige a la réplica geográfica más cercana. En caso de fallo, aplicas una lógica empresarial personalizada para determinar cuándo redirigir las solicitudes a otras regiones.	Usa perfiles de aplicación para configurar políticas de enrutamiento del tráfico de clústeres. Usa el enrutamiento de varios clústeres para enrutar el tráfico automáticamente al clúster correcto más cercano. En caso de fallo, Bigtable admite la conmutación por error automática entre clústeres para la alta disponibilidad.
Escalado	La capacidad de escritura en 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 añadiendo o quitando nodos de cada clúster replicado según sea necesario.
Coste	Las WRUs de lectura y escritura cuestan un 50% más que las WRUs normales.	Se te factura por los nodos y el almacenamiento de cada clúster. No hay costes de replicación de red para la replicación regional entre zonas. Los costes se generan cuando la replicación se realiza entre regiones o continentes.
Acuerdo de nivel de servicio	99,999 %	99,999%

Plano de datos

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

DynamoDB	Bigtable
Artículo: grupo de atributos que se puede identificar de forma única entre todos los demás artículos por su clave principal. El tamaño máximo permitido es de 400 KB.	Fila: una sola entidad identificada por la clave de fila. El tamaño máximo permitido es de 256 MB.
N/A	Familia de columnas: espacio de nombres especificado por el usuario que agrupa columnas.
Atributo: agrupación de un nombre y un valor. El valor de un atributo puede ser un tipo escalar, un conjunto o un documento. No hay ningún límite explícito en el tamaño de los atributos. Sin embargo, como cada elemento tiene un límite de 400 KB, en el caso de los elementos que solo tienen un atributo, este puede ocupar hasta 400 KB menos el tamaño ocupado por el nombre del atributo.	Calificador de columna: identificador único de una columna dentro de una familia de columnas. El identificador completo de una columna se expresa como familia-de-columnas:calificador-de-columna. Los calificadores de columna se ordenan lexicográficamente en la familia de columnas. El tamaño máximo permitido para un calificador de columna es de 16 KB. Celda: contiene los datos de una fila, una columna y una marca de tiempo concretas. Una celda contiene un valor que puede ser de hasta 100 MB.
Clave principal: identificador único de un elemento de una tabla. Puede ser una clave de partición o una clave compuesta. Clave de partición: clave principal simple compuesta por un atributo. 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: clave que determina el orden de las filas de una partición. El tamaño máximo permitido es de 1 KB. Clave compuesta: clave principal compuesta por dos propiedades: la clave de partición y una clave de ordenación o un atributo de intervalo.	Clave de fila: identificador único de un elemento de una tabla. Normalmente se representa mediante una concatenación de valores y delimitadores. El tamaño máximo permitido es de 4 KB. Los calificadores de columna se pueden usar para ofrecer un comportamiento equivalente al de la clave de ordenación de DynamoDB. Las claves compuestas se pueden crear usando claves de fila concatenadas y calificadores de columna. Para obtener más información, 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 deja de ser necesario un elemento. Después de la fecha y la hora de la marca de tiempo especificada, el elemento se elimina de la tabla sin consumir capacidad de escritura.	Recolección de elementos no utilizados: las marcas de tiempo de cada celda determinan cuándo ya no se necesita un elemento. La recogida de elementos no utilizados elimina los elementos caducados durante un proceso en segundo plano denominado compactación. Las políticas de recolección de elementos no utilizados se definen a nivel de familia de columnas y pueden eliminar elementos no solo en función de su antigüedad, sino también según el número de versiones que quiera conservar el usuario. No es necesario que tengas en cuenta la capacidad de compactación al dimensionar los clústeres.

Operaciones

Las operaciones del plano de datos te permiten crear, leer, actualizar y eliminar datos de una tabla. En la siguiente tabla se comparan operaciones similares del plano de datos de DynamoDB y Bigtable.

DynamoDB	Bigtable
CreateTable	CreateTable
PutItem BatchWriteItem	MutateRow MutateRows Bigtable trata las operaciones de escritura como upserts.
UpdateItem Escritura condicional Incremento y decremento	CheckAndMutateRow ReadModifyWriteRow Bigtable trata las operaciones de escritura como upserts.
GetItem BatchGetItem, Query, Scan	`ReadRow` `ReadRows` (intervalo, prefijo, búsqueda inversa) Bigtable admite búsquedas eficientes por prefijo de clave de fila, patrón de expresión regular o intervalo de claves de fila hacia delante o hacia atrás.

Tipos de datos

Tanto Bigtable como DynamoDB no tienen esquema. Las columnas se pueden definir en tiempo de escritura sin que se aplique a toda la tabla la existencia de columnas o los tipos de datos. Del mismo modo, el tipo de datos de una columna o un atributo puede variar de una fila o un elemento a otro. Sin embargo, las APIs de DynamoDB y Bigtable gestionan los tipos de datos de formas diferentes.

Cada solicitud de escritura de DynamoDB incluye una definición de tipo para cada atributo, que se devuelve 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 el cliente pueda analizar las respuestas correctamente. La excepción son las operaciones de incremento, que interpretan los valores como números enteros con signo de 64 bits en formato big-endian.

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

DynamoDB	Bigtable
Tipos escalares: se devuelven como tokens tipo_de_datos descriptor 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 signo de 64 bits en formato big-endian.
Conjunto: colección sin ordenar de elementos únicos.	Familia de columnas: puedes usar calificadores de columna como nombres de miembros de conjuntos y, para cada uno, proporcionar un solo byte 0 como valor de celda. Los miembros de un conjunto se ordenan lexicográficamente en su familia de columnas.
Mapa: colección sin ordenar de pares clave-valor con claves únicas.	Familia de columnas Usa el calificador de columna como clave de mapa y el valor de celda como valor. Las claves de mapa se ordenan lexicográficamente.
Lista: colección ordenada de elementos.	Calificador de columna Usa la marca de tiempo de inserción para conseguir el equivalente de list_append y la marca de tiempo de inserción inversa para añadir al principio.

Diseño de esquema

Un aspecto importante que se debe tener en cuenta al diseñar un esquema es cómo se almacenan los datos. Entre las diferencias clave entre Bigtable y DynamoDB se encuentran las siguientes:

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

Actualizaciones de valores únicos

Las operaciones UpdateItem en DynamoDB consumen la capacidad de escritura del mayor de los tamaños de los elementos "antes" y "después", aunque la actualización implique un subconjunto de los atributos del elemento. Esto significa que, en DynamoDB, puedes colocar columnas que se actualizan con frecuencia en filas independientes, aunque lógicamente pertenezcan a la misma fila que otras columnas.

Bigtable puede actualizar una celda con la misma eficiencia tanto si es la única columna de una fila determinada como si es una de las muchas que hay. Para obtener más información, consulta Escrituras simples.

Ordenación de datos

DynamoDB cifra y distribuye de forma aleatoria las claves de partición, mientras que Bigtable almacena las filas en orden lexicográfico por clave de fila y deja la tarea de cifrado al usuario.

La distribución aleatoria de claves no es óptima para todos los patrones de acceso. Reduce el riesgo de intervalos de filas activas, pero hace que los patrones de acceso que implican análisis que cruzan los límites de las particiones sean caros e ineficientes. Estas lecturas sin límites son habituales, sobre todo en los casos prácticos que tienen una dimensión temporal.

Para gestionar este tipo de patrón de acceso (es decir, análisis que cruzan los límites de las particiones), se necesita un índice secundario en DynamoDB, pero Bigtable lo gestiona sin necesidad de un índice secundario. Del mismo modo, en DynamoDB, las operaciones de consulta y de análisis están limitadas a 1 MB de datos analizados, por lo que se requiere paginación si se supera este límite. Bigtable no tiene este límite.

A pesar de que las claves de partición se distribuyen de forma aleatoria, DynamoDB puede seguir teniendo particiones activas si una clave de partición elegida no distribuye el tráfico de forma uniforme, lo que afecta negativamente al rendimiento. Para solucionar este problema, DynamoDB recomienda el shard de escritura, que consiste en dividir aleatoriamente 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, a continuación, usar este número como clave de partición lógica. Como aleatoriza la clave de partición, las escrituras en la tabla se distribuyen de forma uniforme entre todos los valores de la clave de partición.

Bigtable denomina a este procedimiento salado de claves y puede ser una forma eficaz de evitar las tablets activas.

Gestión 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. Un caso de uso habitual de las marcas de tiempo es el control de versiones, que consiste en 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 este concepto y requiere diseños de esquemas complejos para admitir el control de versiones. Este método consiste en crear dos copias de cada elemento: una copia con el prefijo de número de versión cero, como v0_, al principio de la clave de ordenación, y otra copia con el prefijo de número de versión uno, como v1_. Cada vez que se actualiza el elemento, se usa el siguiente prefijo de versión superior en la clave de ordenación de la versión actualizada y se copia el contenido actualizado en el elemento con el prefijo de versión cero. De esta forma, se puede encontrar la versión más reciente de cualquier elemento usando 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 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 una gran capacidad de filas

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 conseguir la transaccionalidad deseada diseñando tus esquemas para agrupar los elementos relevantes en una clave de fila compartida. Para ver un ejemplo que ilustra este enfoque, consulta el patrón de diseño de una sola tabla.

Almacenar valores grandes

Como un elemento de DynamoDB, que es análogo a una fila de Bigtable, está limitado a 400 KB, para almacenar valores grandes es necesario dividir el valor en varios elementos o almacenarlo en otros medios, como S3. Ambos enfoques añaden 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 los esquemas de claves.

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 podría ser un esquema de este tipo en DynamoDB.

Clave principal		Atributos
Clave de partición	Clave de ordenación	Descripción	Precio	Thumbnail
sombreros	fedora#brandA	Confeccionada con lana premium…	30	https://storage…
sombreros	fedoras#brandB	Lona resistente al agua y duradera diseñada para...	28	https://storage…
sombreros	newsboy#brandB	Añade un toque vintage a tu look diario.	25	https://storage…
zapatos	zapatillas#marcaA	Sal a la calle con estilo y comodidad con…	40	https://storage…
zapatos	zapatillas#marcaB	Características clásicas con materiales contemporáneos…	50	https://storage…

En esta tabla, la asignación de DynamoDB a Bigtable es sencilla: convierte la clave principal compuesta de DynamoDB en una clave de fila compuesta de Bigtable. Crea una familia de columnas (SKU) que contenga el mismo conjunto de columnas.

Nota: Cada valor de Bigtable también tiene una marca de tiempo , que no se muestra en la tabla para que sea más breve.

	SKU
Clave de fila	Descripción	Precio	Thumbnail
hats#fedoras#brandA	Confeccionada con lana premium…	30	https://storage…
hats#fedoras#brandB	Lona resistente al agua y duradera diseñada para...	28	https://storage…
hats#newsboy#brandB	Añade un toque vintage a tu look diario.	25	https://storage…
zapatos#zapatillas#marcaA	Sal a la calle 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 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 seguir el enfoque del ejemplo anterior y duplicar este esquema tal cual en Bigtable. Sin embargo, es mejor abordar los problemas del esquema durante el proceso.

En este esquema, la clave de partición contiene el ID único de un vídeo, lo que ayuda a colocar todos los atributos relacionados con ese vídeo en el mismo lugar para que el acceso sea más rápido. Dadas las limitaciones de tamaño de los elementos de DynamoDB, no puedes incluir un número ilimitado de comentarios de texto libre en una sola fila. Por lo tanto, se usa una clave de ordenación con el patrón VideoComment#reverse-timestamp para que cada comentario sea una fila independiente dentro de la partición, ordenada cronológicamente de forma inversa.

Supongamos que un vídeo tiene 500 comentarios y el propietario quiere eliminarlo. Esto significa que también se deben eliminar todos los comentarios y atributos del vídeo. Para hacerlo en DynamoDB, debes analizar todas las claves de esta partición y, a continuación, enviar varias solicitudes de eliminación, iterando en cada una de ellas. DynamoDB admite transacciones de varias filas, pero esta solicitud de eliminación es demasiado grande para realizarla en una sola transacción.

Clave principal		Atributos
Clave de partición	Clave de ordenación	UploadDate	Formatos
0123	Vídeo	2023-09-10T15:21:48	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
	VideoComment#98765481	Content
		Me gusta mucho. Los efectos especiales son increíbles.
	VideoComment#86751345	Content
		Parece que hay un fallo de audio en el minuto 1:05.
	VideoStatsLikes	Recuento
		3
	VideoStatsViews	Recuento
		156
0124	Vídeo	2023-09-10T17:03:21	{"480": "https://storage…", "720": "https://storage…"}
	VideoComment#97531849	Content
		He compartido esto con todos mis amigos.
	VideoComment#87616471	Content
		El estilo me recuerda a un director de cine, pero no sé quién es.
	VideoStats	ViewCount
		45

Modifica este esquema a medida que migras para simplificar el código y hacer que las solicitudes de datos sean más rápidas y económicas. Las filas de Bigtable tienen mucha más capacidad que los elementos de DynamoDB y pueden gestionar un gran número de comentarios. Para gestionar un caso en el que un vídeo recibe millones de comentarios, puedes definir una política de recogida de elementos no utilizados para conservar solo un número fijo de los comentarios más recientes.

Como los contadores se pueden actualizar sin la sobrecarga de actualizar toda la fila, tampoco es necesario dividirlos. Tampoco tienes que usar una columna UploadDate ni calcular una marca de tiempo inversa y convertirla en tu clave de ordenación, ya que las marcas de tiempo de Bigtable te proporcionan los comentarios ordenados cronológicamente de forma inversa automáticamente. Esto simplifica significativamente el esquema y, si se elimina un vídeo, puedes eliminar de forma transaccional la fila del vídeo, incluidos todos los comentarios, en una sola solicitud.

Por último, como las columnas de Bigtable se ordenan lexicográficamente, puedes cambiar el nombre de las columnas para permitir un análisis rápido del intervalo (desde las propiedades del vídeo hasta los N comentarios más recientes) en una sola solicitud de lectura, que es lo que te interesa hacer cuando se carga el vídeo. Después, puedes desplazarte por el resto de los comentarios a medida que el usuario lo haga.

	Atributos
Clave de fila	Formatos	Me gusta	Visualizaciones	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 fallo 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 sé quién es. @2023-10-12T07:08:51

Patrón de diseño de lista de adyacencia

Considera una versión ligeramente diferente de este diseño, que DynamoDB suele denominar patrón de diseño de lista de adyacencia.

Clave principal		Atributos
Clave de partición	Clave de ordenació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 ordenación no se basan en el tiempo, sino en los IDs de pago, por lo que puede usar otro patrón de columna ancha y hacer que esos IDs sean columnas independientes en Bigtable, con ventajas 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 puede ver en los ejemplos anteriores, con el diseño de esquema adecuado, el modelo de columna ancha de Bigtable puede ser muy eficaz y ofrecer muchos casos prácticos que requerirían transacciones de varias filas costosas, indexación secundaria o un comportamiento en cascada al eliminar en otras bases de datos.

Siguientes pasos

• Consulta información sobre el diseño de esquemas de Bigtable.
• Consulta información sobre el emulador de Bigtable.
• Consulta arquitecturas de referencia, diagramas y prácticas recomendadas sobreGoogle Cloud. Consulta nuestro Centro de arquitectura de Cloud.