Prácticas recomendadas para el diseño de esquemas

Esta página contiene información sobre el diseño del esquema de Bigtable. Antes de leer esta página, debes familiarizarte con la descripción general de Bigtable. En esta página se tratan los siguientes temas:

Conceptos generales

Diseñar un esquema de Bigtable es diferente de diseñar un esquema para una base de datos relacional. El esquema de Bigtable se define mediante la lógica de la aplicación, en lugar de mediante un objeto o un archivo de definición de esquema. Puedes añadir familias de columnas a una tabla cuando la crees o la actualices, pero las columnas y los patrones de claves de fila se definen mediante los datos que escribas en la tabla.

En Bigtable, un esquema es un plano o un modelo de una tabla, incluida la estructura de los siguientes componentes de la tabla:

  • Claves de fila
  • Familias de columnas, incluidas sus políticas de recolección de elementos no utilizados
  • Columnas

En Bigtable, el diseño del esquema se basa principalmente en las consultas (o solicitudes de lectura) que tienes previsto enviar a la tabla. Como leer un intervalo de filas es la forma más rápida de leer los datos de Bigtable, las recomendaciones de esta página están diseñadas para ayudarte a optimizar las lecturas de intervalos de filas. En la mayoría de los casos, esto significa enviar una consulta basada en prefijos de clave de fila.

Otro aspecto que debes tener en cuenta es evitar los puntos de acceso. Para ello, debes analizar los patrones de escritura y cómo puedes evitar acceder a un espacio de claves pequeño en poco tiempo.

Los siguientes conceptos generales se aplican al diseño de esquemas de Bigtable:

  • Bigtable es un almacén de pares clave-valor, no un almacén relacional. No admite combinaciones y las transacciones solo se admiten en una sola fila.
  • Cada tabla tiene un índice: la clave de fila. Cada clave de fila debe ser única. Para crear un índice secundario, usa una vista materializada continua. Para obtener más información, consulta Crear un índice secundario asíncrono.
  • Las teclas de las filas ordenan las filas lexicográficamente de la cadena de bytes más baja a la más alta. Este orden es big-endian (a veces se denomina "orden de bytes de red"), el equivalente binario del orden alfabético.
  • Las familias de columnas no se almacenan en ningún orden específico.
  • Las columnas se agrupan por familias de columnas y se ordenan alfabéticamente dentro de la familia de columnas. Por ejemplo, en una familia de columnas llamada SysMonitor con los calificadores de columna ProcessName, User, %CPU, ID, Memory, DiskRead y Priority, Bigtable almacena las columnas en este orden:
SysMonitor
%CPU DiskRead ID Memoria Prioridad ProcessName Usuario
  • La intersección de una fila y una columna puede contener varias celdas con marca de tiempo. Cada celda contiene una versión única de los datos con marca de tiempo de esa fila y columna.
  • Las familias de columnas agregadas contienen celdas agregadas. Puedes crear familias de columnas que solo contengan celdas agregadas. Una agregación te permite combinar datos nuevos con los que ya hay en la celda.
  • Todas las operaciones son atómicas a nivel de fila. Una operación afecta a toda una fila o a ninguna parte de ella.
  • Lo ideal es que tanto las lecturas como las escrituras se distribuyan de forma uniforme por el espacio de las filas de una tabla.
  • Las tablas de Bigtable son dispersas. Una columna no ocupa ningún espacio en una fila que no la utilice.

Prácticas recomendadas

Un buen esquema da como resultado un rendimiento y una escalabilidad excelentes, mientras que un esquema mal diseñado puede provocar que el sistema funcione mal. Cada caso práctico es diferente y requiere su propio diseño, pero las siguientes prácticas recomendadas se aplican a la mayoría de los casos prácticos. Hay excepciones, que aparecen indicadas.

En las siguientes secciones se describen las prácticas recomendadas para diseñar esquemas, empezando por el nivel de tabla y terminando en el nivel de clave de fila:

Todos los elementos de la tabla, especialmente las claves de fila, deben diseñarse teniendo en cuenta las solicitudes de lectura planificadas. Consulta las cuotas y los límites para ver los límites de tamaño recomendados y fijos de todos los elementos de las tablas.

Como todas las tablas de una instancia se almacenan en las mismas tabletas, un diseño de esquema que provoque puntos de acceso en una tabla puede afectar a la latencia de otras tablas de la misma instancia. Los hotspots se producen cuando se accede con frecuencia a una parte de la tabla en un breve periodo.

Tablas

Almacena los conjuntos de datos con esquemas similares en la misma tabla, en lugar de hacerlo en tablas independientes.

En otros sistemas de bases de datos, puede que decidas almacenar los datos en varias tablas en función del tema y del número de columnas. Sin embargo, en Bigtable, suele ser mejor almacenar todos los datos en una sola tabla. Puedes asignar un prefijo de clave de fila único para cada conjunto de datos, de forma que Bigtable almacene los datos relacionados en un intervalo contiguo de filas que luego puedes consultar por prefijo de clave de fila.

Bigtable tiene un límite de 1000 tablas por instancia, pero te recomendamos que evites crear un gran número de tablas por los siguientes motivos:

  • Enviar solicitudes a muchas tablas diferentes puede aumentar la sobrecarga de la conexión backend, lo que provoca un aumento de la latencia de cola.
  • Crear más tablas no mejora el equilibrio de carga y puede aumentar la sobrecarga de gestión.

Es posible que quieras tener una tabla independiente para un caso práctico diferente que requiera un esquema distinto, pero no deberías usar tablas independientes para datos similares. Por ejemplo, no deberías crear una tabla nueva porque sea un año nuevo o porque tengas un nuevo cliente.

Familias de columnas

Coloca las columnas relacionadas en la misma familia de columnas. Cuando una fila contiene varios valores relacionados entre sí, es recomendable agrupar las columnas que contienen esos valores en la misma familia de columnas. Agrupa los datos lo más posible para no tener que diseñar filtros complejos y obtener solo la información que necesitas en tus solicitudes de lectura más frecuentes.

Crea hasta 100 familias de columnas por tabla. Crear más de 100 familias de columnas puede provocar una disminución del rendimiento.

Elige nombres cortos para tus familias de columnas. Los nombres se incluyen en los datos que se transfieren en cada solicitud.

Coloca las columnas que tengan diferentes necesidades de retención de datos en diferentes familias de columnas. Esta práctica es importante si quieres limitar los costes de almacenamiento. Las políticas de recogida de elementos no utilizados se definen a nivel de familia de columnas, no a nivel de columna. Por ejemplo, si solo necesitas conservar la versión más reciente de un dato concreto, no lo almacenes en una familia de columnas configurada para almacenar 1000 versiones de otro elemento. De lo contrario, pagarás por almacenar 999 celdas de datos que no necesitas.

Columnas

Crea tantas columnas como necesites en la tabla. Las tablas de Bigtable son dispersas y no se penaliza el espacio de una columna que no se usa en una fila. Puedes tener millones de columnas en una tabla, siempre que ninguna fila supere el límite máximo de 256 MB por fila.

No uses demasiadas columnas en una misma fila. Aunque una tabla puede tener millones de columnas, una fila no debería. Hay varios factores que contribuyen a esta práctica recomendada:

  • Bigtable tarda en procesar cada celda de una fila.
  • Cada celda añade una sobrecarga a la cantidad de datos almacenados en la tabla y enviados a través de la red. Por ejemplo, si almacenas 1 KB (1024 bytes) de datos, es mucho más eficiente en cuanto al espacio almacenar esos datos en una sola celda que distribuirlos en 1024 celdas que contengan 1 byte cada una.

Si tu conjunto de datos requiere lógicamente más columnas por fila de las que Bigtable puede procesar de forma eficiente, considera la posibilidad de almacenar los datos como un protobuf en una sola columna.

También puedes tratar los calificadores de columna como datos. Como tienes que almacenar un calificador de columna para cada columna, puedes ahorrar espacio asignando un valor al nombre de la columna. Por ejemplo, supongamos que tenemos una tabla que almacena datos sobre amistades en una Friendsfamilia de columnas. Cada fila representa a una persona y todas sus amistades. Cada calificador de columna puede ser el ID de un amigo. A continuación, el valor de cada columna de esa fila puede ser el círculo social al que pertenece el amigo. En este ejemplo, las filas podrían tener este aspecto:

Clave de fila Fred Gabriel Hiroshi Seo Yoon Jakob
Jose book-club trabajo tenis
Sofía trabajo colegio chess-club

Compara este esquema con un esquema de los mismos datos que no trata los calificadores de columna como datos y, en su lugar, tiene las mismas columnas en cada fila:

Clave de fila Amigo Círculo
Jose#1 Fred book-club
Jose#2 Gabriel trabajo
Jose#3 Hiroshi tenis
Sofia#1 Hiroshi trabajo
Sofia#2 Seo Yoon colegio
Sofia#3 Jakob chess-club

El segundo diseño de esquema hace que la tabla crezca mucho más rápido.

Si usas calificadores de columna para almacenar datos, asigna a los calificadores de columna nombres cortos pero significativos. Este enfoque te permite reducir la cantidad de datos que se transfieren en cada solicitud. El tamaño máximo es de 16 KB.

Filas

El tamaño de todos los valores de una fila no debe superar los 100 MB. Asegúrate de que los datos de una sola fila no superen los 256 MB. Si se supera este límite, el rendimiento de lectura puede verse reducido.

Mantén toda la información de una entidad en una sola fila. En la mayoría de los casos prácticos, no almacenes datos que debas leer de forma atómica o todos a la vez en más de una fila para evitar incoherencias. Por ejemplo, si actualiza dos filas de una tabla, es posible que una se actualice correctamente y la otra no. Asegúrate de que tu esquema no requiera que se actualice más de una fila al mismo tiempo para que los datos relacionados sean precisos. De esta forma, si falla una parte de una solicitud de escritura o debe enviarse de nuevo, esa parte de los datos no estará incompleta temporalmente.

Excepción: Si mantener una entidad en una sola fila da como resultado filas de cientos de MB, debes dividir los datos en varias filas.

Almacena las entidades relacionadas en filas adyacentes para que las lecturas sean más eficientes.

Celdas

No almacenes más de 10 MB de datos en una sola celda. Recuerda que una celda son los datos almacenados en una fila y una columna concretas con una marca de tiempo única, y que se pueden almacenar varias celdas en la intersección de esa fila y esa columna. El número de celdas conservadas en una columna se rige por la política de recogida de elementos no utilizados que definas para la familia de columnas que contiene esa columna.

Usa celdas de agregación para almacenar y actualizar datos agregados. Si solo te interesa el valor agregado de los eventos de una entidad, como la suma mensual de las ventas por empleado en una tienda, puedes usar agregaciones. Para obtener más información, consulta Agregar valores al escribir.

Claves de fila

Diseña tu clave de fila en función de las consultas que vayas a usar para recuperar los datos. Las claves de fila bien diseñadas ofrecen el mejor rendimiento en Bigtable. Las consultas de Bigtable más eficientes recuperan datos mediante una de las siguientes opciones:

  • Clave de fila
  • Prefijo de clave de fila
  • Intervalo de filas definido por las claves de fila inicial y final

Otros tipos de consultas activan una búsqueda en la tabla completa, que es mucho menos eficiente. Si eliges la clave de fila correcta ahora, podrás evitar un proceso de migración de datos complicado más adelante.

Procura que las claves de las filas sean cortas. Una clave de fila debe tener un tamaño máximo de 4 KB. Las claves de fila largas ocupan más memoria y almacenamiento, y aumentan el tiempo que se tarda en obtener respuestas del servidor de Bigtable.

Almacena varios valores delimitados en cada clave de fila. Como la mejor forma de consultar Bigtable de forma eficiente es por clave de fila, a menudo es útil incluir varios identificadores en la clave de fila. Cuando la clave de fila incluye varios valores, es especialmente importante que sepas cómo usas tus datos.

Los segmentos de clave de fila suelen estar separados por un delimitador, como dos puntos, una barra o un símbolo de almohadilla. El primer segmento o conjunto de segmentos contiguos es el prefijo de la clave de fila, y el último segmento o conjunto de segmentos contiguos es el sufijo de la clave de fila.

Clave de fila de ejemplo

Si planificas bien los prefijos de las claves de fila, podrás aprovechar el orden de clasificación integrado de Bigtable para almacenar datos relacionados en filas contiguas. Almacenar datos relacionados en filas contiguas te permite acceder a ellos como un intervalo de filas, en lugar de ejecutar análisis de tablas ineficientes.

Si tus datos incluyen números enteros que quieres almacenar u ordenar numéricamente, añade ceros iniciales a los números enteros. Bigtable almacena los datos de forma lexicográfica. Por ejemplo, lexicográficamente, 3 > 20, pero 20 > 03. Si se añade un cero inicial al 3, los números se ordenan numéricamente. Esta táctica es importante para las marcas de tiempo en las que se usan consultas basadas en intervalos.

Es importante crear una clave de fila que permita recuperar un intervalo de filas bien definido. De lo contrario, tu consulta requerirá un análisis de tabla, que es mucho más lento que recuperar filas específicas.

Por ejemplo, si tu aplicación monitoriza datos de dispositivos móviles, puedes tener una clave de fila que conste del tipo de dispositivo, el ID del dispositivo y el día en que se registran los datos. Las claves de fila de estos datos podrían tener este aspecto:

        phone#4c410523#20200501
        phone#4c410523#20200502
        tablet#a0b81f74#20200501
        tablet#a0b81f74#20200502

Este diseño de clave de fila le permite recuperar datos con una sola solicitud para lo siguiente:

  • Un tipo de dispositivo
  • Una combinación del tipo de dispositivo y el ID de dispositivo

Este diseño de clave de fila no sería óptimo si quieres obtener todos los datos de un día concreto. Como el día se almacena en el tercer segmento o en el sufijo de la clave de fila, no puedes solicitar un intervalo de filas basado en el sufijo o en un segmento intermedio de la clave de fila. En su lugar, debe enviar una solicitud de lectura con un filtro que analice toda la tabla en busca del valor del día.

Utiliza valores de cadena legibles por humanos en las claves de las filas siempre que sea posible. Esta práctica facilita el uso de la herramienta Key Visualizer para solucionar problemas con Bigtable.

A menudo, debe diseñar claves de fila que empiecen por un valor común y terminen por un valor granular. Por ejemplo, si la clave de fila incluye un continente, un país y una ciudad, puede crear claves de fila como las siguientes para que se ordenen automáticamente primero por los valores con menor cardinalidad:

        asia#india#bangalore
        asia#india#mumbai
        asia#japan#osaka
        asia#japan#sapporo
        southamerica#bolivia#cochabamba
        southamerica#bolivia#lapaz
        southamerica#chile#santiago
        southamerica#chile#temuco

Claves de fila estructuradas

Si tienes previsto consultar tu tabla mediante SQL, puedes definir claves de fila estructuradas, que te permiten acceder a tus datos de Bigtable mediante claves de varias partes, de forma similar a las claves compuestas de las bases de datos relacionales. Si defines claves de fila estructuradas para una tabla, puedes acceder a segmentos específicos de las claves de fila mediante consultas de GoogleSQL para Bigtable.

Las claves de fila estructuradas se crean automáticamente al crear una vista materializada continua. Para implementar claves de fila estructuradas en una tabla de Bigtable, puede crear un esquema de clave de fila que defina el tipo de datos y la codificación de cada segmento de la clave de fila. Bigtable almacena las claves de las filas como bytes ordenados lexicográficamente, y el esquema de claves de las filas indica a GoogleSQL para Bigtable cómo decodificar e interpretar esos bytes.

Los esquemas de claves de fila se ignoran cuando consultas la tabla mediante el método ReadRows de la API Data de Bigtable con una biblioteca de cliente de Bigtable.

Para obtener más información, consulta Gestionar esquemas de claves de fila y Consultas de claves de fila estructuradas.

Claves de fila que se deben evitar

Algunos tipos de claves de fila pueden dificultar la consulta de los datos y provocar un rendimiento deficiente. En esta sección se describen algunos tipos de claves de fila que deberías evitar usar en Bigtable.

Claves de fila que empiezan por una marca de tiempo. Este patrón provoca que las escrituras secuenciales se inserten en un solo nodo, lo que crea un punto de acceso. Si incluye una marca de tiempo en una clave de fila, preceda a esta con un valor de cardinalidad elevada, como un ID de usuario, para evitar puntos de acceso.

Claves de fila que provocan que los datos relacionados no se agrupen. Evita las claves de fila que provoquen que los datos relacionados se almacenen en intervalos de filas no contiguos, ya que no es eficiente leerlos juntos.

IDs numéricos secuenciales. Supongamos que tu sistema asigna un ID numérico a cada uno de los usuarios de tu aplicación. Puede que te veas tentado a usar el ID numérico del usuario como clave de fila de tu tabla. Sin embargo, como es más probable que los usuarios nuevos sean usuarios activos, es probable que este enfoque dirija la mayor parte del tráfico a un número reducido de nodos.

Una opción más segura es usar una versión invertida del ID numérico del usuario, que distribuye el tráfico de forma más uniforme entre todos los nodos de la tabla de Bigtable.

Identificadores que se actualizan con frecuencia. Evita usar una sola clave de fila para identificar un valor que deba actualizarse con frecuencia. Por ejemplo, si almacena datos de uso de memoria de varios dispositivos una vez por segundo, no utilice una sola clave de fila para cada dispositivo que esté formada por el ID del dispositivo y la métrica que se almacena, como 4c410523#memusage, y actualice la fila repetidamente. Este tipo de operación sobrecarga la tabla que almacena la fila usada con frecuencia. También puede provocar que una fila supere su límite de tamaño, ya que los valores anteriores de una columna ocupan espacio hasta que se eliminan las celdas durante la recogida de elementos no utilizados.

En su lugar, almacena cada nueva lectura en una fila nueva. En el ejemplo del uso de memoria, cada clave de fila puede contener el ID del dispositivo, el tipo de métrica y una marca de tiempo, por lo que las claves de fila son similares a 4c410523#memusage#1423523569918. Esta estrategia es eficiente porque, en Bigtable, crear una fila nueva no lleva más tiempo que crear una celda nueva. Además, esta estrategia te permite leer rápidamente los datos de un intervalo de fechas concreto calculando las claves de inicio y fin adecuadas.

En el caso de los valores que cambian con frecuencia, como un contador que se actualiza cientos de veces cada minuto, lo mejor es mantener los datos en la memoria, en la capa de aplicación, y escribir nuevas filas en Bigtable periódicamente.

Valores cifrados con hash. Al cifrar con hash una clave de fila, no podrás aprovechar el orden de clasificación natural de Bigtable, por lo que será imposible almacenar filas de forma óptima para las consultas. Por el mismo motivo, los valores de hash dificultan el uso de la herramienta Key Visualizer para solucionar problemas con Bigtable. Use valores legibles por humanos en lugar de valores cifrados con hash.

Valores expresados como bytes sin procesar en lugar de cadenas legibles por humanos. Los bytes sin procesar son adecuados para los valores de las columnas, pero, para facilitar la lectura y la solución de problemas, utilice valores de cadena en las claves de las filas.

Casos prácticos especiales

Puede que tengas un conjunto de datos único que requiera una consideración especial a la hora de diseñar un esquema para almacenarlo en Bigtable. En esta sección se describen algunos tipos de datos de Bigtable (no todos) y algunas tácticas sugeridas para almacenarlos de la forma más óptima posible.

Datos basados en el tiempo

Si suele recuperar datos en función de la hora en la que se registraron, puede incluir una marca de tiempo como parte de la clave de fila.

Por ejemplo, tu aplicación puede registrar datos relacionados con el rendimiento, como el uso de la CPU y la memoria, una vez por segundo en muchas máquinas. La clave de fila de estos datos podría combinar un identificador de la máquina con una marca de tiempo de los datos (por ejemplo, machine_4223421#1425330757685). Ten en cuenta que las claves de fila se ordenan lexicográficamente.

Si incluye marcas de tiempo en la clave de fila, no utilice una marca de tiempo por sí sola ni al principio de una clave de fila. Este patrón hace que las escrituras secuenciales se inserten en un solo nodo, lo que crea un punto de acceso.

Si sueles recuperar los registros más recientes en tus consultas, puedes usar marcas de tiempo invertidas en la clave de fila. Este patrón hace que las filas se ordenen de la más reciente a la menos reciente, por lo que los datos más recientes aparecen antes en la tabla. Al igual que con cualquier marca de tiempo, no empiece una clave de fila con una marca de tiempo invertida para evitar que se produzcan hotspots.

Puedes obtener una marca de tiempo invertida restando la marca de tiempo del valor máximo de números enteros largos de tu lenguaje de programación (en Java, java.lang.Long.MAX_VALUE).

Para obtener información específica sobre cómo trabajar con datos de series temporales, consulta Diseño de esquemas para datos de series temporales.

Arquitectura multicliente

Los prefijos de clave de fila proporcionan una solución escalable para un caso práctico de "multitenancy", un escenario en el que se almacenan datos similares con el mismo modelo de datos en nombre de varios clientes. Usar una tabla para todos los inquilinos es la forma más eficiente de almacenar y acceder a datos de varios inquilinos.

Por ejemplo, supongamos que almacena y monitoriza historiales de compras en nombre de muchas empresas. Puede usar el ID único de cada empresa como prefijo de clave de fila. Todos los datos de un arrendatario se almacenan en filas contiguas de la misma tabla y puedes consultar o filtrar mediante el prefijo de la clave de fila. Después, cuando una empresa deje de ser su cliente y necesite eliminar el historial de compras que almacenaba de esa empresa, puede eliminar el intervalo de filas que usen el prefijo de clave de fila de ese cliente.

Por ejemplo, si almacena datos de dispositivos móviles de los clientes altostrat y examplepetstore, puede crear claves de fila como las siguientes. Después, si altostrat ya no es tu cliente, elimina todas las filas con el prefijo de clave de fila altostrat.

        altostrat#phone#4c410523#20190501
        altostrat#phone#4c410523#20190502
        altostrat#tablet#a0b41f74#20190501
        examplepetstore#phone#4c410523#20190502
        examplepetstore#tablet#a6b81f79#20190501
        examplepetstore#tablet#a0b81f79#20190502

Por el contrario, si almacenas datos en nombre de cada empresa en su propia tabla, puedes tener problemas de rendimiento y escalabilidad. También es más probable que alcances por error el límite de Bigtable de 1000 tablas por instancia. Cuando una instancia alcanza este límite, Bigtable te impide crear más tablas en la instancia.

Privacidad

A menos que tu caso práctico lo requiera, no utilices información personal identificable (IPI) ni datos de usuario en las claves de fila o en los IDs de familia de columnas. Los valores de las claves de las filas y de las familias de columnas son datos de clientes y datos de servicio. Las aplicaciones que los usan, como el cifrado o el registro, pueden exponerlos inadvertidamente a usuarios que no deberían tener acceso a datos privados.

Para obtener más información sobre cómo se tratan los datos del servicio, consulta el Google Cloud Aviso de Privacidad.

Nombres de dominio

Puedes almacenar nombres de dominio como datos de Bigtable.

Amplia gama de nombres de dominio

Si almacenas datos sobre entidades que se pueden representar como nombres de dominio, te recomendamos que uses un nombre de dominio inverso (por ejemplo, com.company.product) como clave de fila. Usar un nombre de dominio inverso es una buena idea, sobre todo si los datos de cada fila tienden a solaparse con los de las filas adyacentes. En este caso, Bigtable puede comprimir los datos de forma más eficiente.

Por el contrario, los nombres de dominio estándar que no están invertidos pueden provocar que las filas se ordenen de forma que los datos relacionados no se agrupen en un mismo lugar, lo que puede dar lugar a una compresión y a lecturas menos eficientes.

Este enfoque es el más adecuado cuando tus datos se distribuyen en muchos nombres de dominio inverso diferentes.

Para ilustrar este punto, considere los siguientes nombres de dominio, ordenados automáticamente por Bigtable en orden lexicográfico:

      drive.google.com
      en.wikipedia.org
      maps.google.com

Esto no es recomendable en el caso práctico en el que quieras consultar todas las filas de la google.com. Por el contrario, considere las mismas filas en las que se han invertido los nombres de dominio:

      com.google.drive
      com.google.maps
      org.wikipedia.en

En el segundo ejemplo, las filas relacionadas se ordenan automáticamente de forma que sea más fácil recuperarlas como un intervalo de filas.

Pocos nombres de dominio

Si tiene previsto almacenar muchos datos para uno o pocos nombres de dominio, considere otros valores para la clave de fila. De lo contrario, es posible que envíes escrituras a un solo nodo de tu clúster, lo que provocaría puntos de acceso, o que tus filas crezcan demasiado.

Consultas cambiantes o inciertas

Si no siempre ejecutas las mismas consultas en tus datos o no sabes cuáles serán, puedes almacenar todos los datos de una fila en una columna en lugar de en varias. Con este método, se usa un formato que facilita la extracción de los valores individuales más adelante, como el formato binario protocol buffer o un archivo JSON.

La clave de fila se sigue diseñando cuidadosamente para que pueda recuperar los datos que necesite, pero cada fila suele tener solo una columna que contiene todos los datos de la fila en un solo protobuf.

Almacenar datos como un mensaje protobuf en una columna en lugar de distribuirlos en varias columnas tiene ventajas e inconvenientes. Entre las ventajas, se incluyen las siguientes:

  • Los datos ocupan menos espacio, por lo que el coste de almacenarlos es menor.
  • Mantienes un cierto grado de flexibilidad al no comprometerte con familias de columnas ni calificadores de columnas.
  • Tu aplicación de lectura no tiene que "saber" cuál es el esquema de tu tabla.

Algunas de las desventajas son las siguientes:

  • Tienes que deserializar los mensajes de protobuf después de leerlos de Bigtable.
  • No podrás consultar los datos de los mensajes protobuf mediante filtros.
  • No puedes usar BigQuery para ejecutar consultas federadas en campos de mensajes protobuf después de leerlos de Bigtable.

Siguientes pasos