Se usó la API de Cloud Translation para traducir esta página.

Escrituras

Descripción general

En esta página, se enumeran los tipos de solicitudes de escritura que puedes enviar a Cloud Bigtable y se describe en qué situaciones debes usarlas.

Las API de datos y las bibliotecas cliente de Cloud Bigtable te permiten escribir datos de manera programática en tus tablas. Bigtable envía una respuesta o una confirmación de recepción por cada escritura.

Cada biblioteca cliente cuenta con la capacidad de enviar los siguientes tipos de solicitudes de escritura:

Escrituras simples
Incrementos y anexos
Escrituras condicionales
Escrituras por lotes

Las bibliotecas cliente de Bigtable tienen una función integrada de reintentos inteligentes para escrituras simples y por lotes, lo que significa que manejan sin problemas los problemas temporales de disponibilidad. Por ejemplo, si tu aplicación intenta escribir datos y ocurre una interrupción temporal o un problema de red, lo reintentará automáticamente hasta que se confirme la escritura o se alcance la fecha límite de la solicitud. Esta resiliencia funciona con instancias y enrutamiento de uno o varios clústeres.

En las operaciones de escritura por lotes y de transmisión, puedes usar el conector de Dataflow para Bigtable. Para obtener más información sobre los límites que se aplican a las solicitudes de escritura, consulta Cuotas y límites.

Existen ejemplos de cada tipo de escritura disponibles para cada biblioteca cliente de Bigtable.

Tipos de escrituras y cuándo usarlas

Todas las solicitudes de escritura incluyen los siguientes componentes básicos:

El nombre de la tabla en la que se escribirá.
Un ID de perfil de aplicación que le indica a Bigtable cómo enrutar el tráfico.
Una o más mutaciones. Una mutación consta de los siguientes cuatro elementos siguientes:
- Nombre de la familia de columnas
- Calificador de columna
- Marca de tiempo
- Valor que ingresaste en la tabla

La marca de tiempo de una mutación tiene un valor predeterminado, que corresponde a la fecha y hora actuales. Todas las mutaciones de una solicitud de escritura tendrán la misma marca de tiempo, a menos que las anules. Puedes establecer que la marca de tiempo de todas las mutaciones de una solicitud de escritura sea la misma o diferente para cada una.

Escrituras simples

Puedes escribir una sola fila de Bigtable con una solicitud de MutateRow que incluya el nombre de la tabla, el ID del perfil de aplicación que se debe usar, una clave de fila y hasta 100,000 mutaciones de ella. Una escritura de una única fila es atómica. Usa este tipo de escritura cuando realices varias mutaciones en una sola fila.

Para ver las muestras de código que demuestran cómo enviar solicitudes de escritura simples, consulta Realiza una escritura simple.

Cuándo no usar las escrituras condicionales

No se recomienda escribir datos mediante las escrituras simples en los siguientes casos prácticos:

Si escribes un lote de datos que tendrá claves de fila contiguas. En este caso, debes utilizar escrituras por lotes en lugar de escrituras simples consecutivas, ya que se puede aplicar un lote contiguo en una sola llamada de backend.
Si quieres alto rendimiento (filas o bytes por segundo) y no necesitas latencia baja. En este caso, las escrituras por lotes serán más rápidas.

Incrementos y anexos

Si quieres adjuntar datos a un valor existente o incrementar un valor numérico existente, envía una solicitud ReadModifyWriteRow. Esta incluye el nombre de la tabla, el ID del perfil de la aplicación que se debe usar, una clave de fila y un conjunto de reglas para escribir los datos. Cada regla incluye el nombre de la familia de columnas, el calificador de columna y un valor anexo o una cantidad de incremento.

Las reglas se aplican en orden. Por ejemplo, si tu solicitud incluye una solicitud para aumentar el valor de una columna en dos y una regla posterior de la misma solicitud aumenta esa columna en 1, se incrementará en 3 en esta escritura atómica. La regla posterior no reemplaza a la anterior.

Solo se puede incrementar un valor si se codifica como un número entero de 64 bits firmado como un valor big-endian. Bigtable trata los incrementos con valores vacíos o que no existen como si el valor fuera cero. Las solicitudes de ReadModifyWriteRow son atómicas. No se reintentarán si fallan por algún motivo.

Para ver las muestras de código que demuestran cómo agregar un valor en una celda, consulta Aumenta un valor existente.

Cuándo no usar incrementos y anexos

No debes enviar solicitudes de ReadModifyWriteRow en los siguientes casos:

Si usas un perfil de aplicación que tiene enrutamiento de varios clústeres.
Si usas varios perfiles de aplicación de un solo clúster y envías escrituras que podrían entrar en conflicto con los datos escritos en las mismas filas y columnas de otros clústeres de la instancia. Con el enrutamiento de un solo clúster, se envía una solicitud de escritura a un solo clúster y, luego, se replica.
Si dependes de la función de reintentos inteligentes que proporcionan las bibliotecas cliente. No se pueden reintentar los incrementos ni los anexos.
Si escribes grandes cantidades de datos y necesitas que las escrituras se completen rápidamente. Una solicitud que lee y, luego, modifica una fila es más lenta que una solicitud de escritura simple. Por consiguiente, este tipo de escritura no suele ser el enfoque más adecuado para tareas a gran escala. Por ejemplo, si quieres contar millones de elementos, como las páginas vistas, te sugerimos registrar cada vista como una escritura simple en lugar de incrementar un valor. Luego, puedes usar un trabajo de Dataflow para agregar los datos.

Escrituras condicionales

Si quieres verificar una fila para ver una condición y, luego, según el resultado, escribir datos en ella, envía una solicitud de CheckAndMutateRow. Este tipo de solicitud incluye una clave y un filtro de fila. Un filtro de fila es un conjunto de reglas que puedes usar para verificar el valor de los datos existentes. Las mutaciones se confirman en columnas específicas de la fila solo cuando se cumplen ciertas condiciones que verificó el filtro. Este proceso de verificación y escritura se realiza como una acción atómica.

Una solicitud de filtro debe incluir uno o ambos de los siguientes tipos de mutaciones:

Mutaciones verdaderas o, en otras palabras, mutaciones que se aplican si el filtro muestra un valor
Mutaciones falsas, que se aplican si el filtro no produce nada

Puedes proporcionar hasta 100,000 mutaciones de cada tipo (verdaderas y falsas) en una sola escritura, y debes enviar al menos una. Bigtable envía una respuesta cuando todas las mutaciones están completas.

Para ver muestras de código que demuestren cómo enviar escrituras condicionales, consulta Escribe un valor de manera condicional.

Cuándo no usar escrituras condicionales

No puedes usar escrituras condicionales en el siguiente caso práctico:

Si usas un perfil de aplicación que tiene enrutamiento de varios clústeres.
Si usas varios perfiles de aplicación de un solo clúster y envías escrituras que podrían entrar en conflicto con los datos escritos en las mismas filas y columnas de otros clústeres de la instancia. Con el enrutamiento de un solo clúster, se envía una solicitud de escritura a un solo clúster y, luego, se replica.

Escrituras por lotes

Puedes escribir más de una fila con una sola llamada mediante una solicitud MutateRows. Las solicitudes de MutateRows contienen un conjunto de hasta 100,000 entradas que se aplican de manera atómica. Cada entrada consiste en una clave de fila y al menos una mutación que se aplicará a la fila. Una solicitud de escritura por lotes puede contener hasta 100,000 mutaciones distribuidas en todas las entradas. Por ejemplo, una escritura por lotes puede incluir cualquiera de las siguientes permutaciones:

100,000 entradas con 1 mutación en cada entrada
1 entrada con 100,000 mutaciones
1,000 entradas con 100 mutaciones cada una

Cada entrada de una solicitud MutateRows es atómica, pero, en su conjunto, la solicitud no lo es. Si es necesario, Bigtable vuelve a intentar las entradas en el lote que no se ejecutan de forma correcta, hasta que todas las escrituras se realicen de forma correcta o se alcance el plazo de la solicitud. Luego, se muestra una respuesta que identifica cada escritura en el lote y si la escritura se realizó de manera correcta o no.

Para ver muestras de código que demuestren cómo enviar escrituras por lotes, consulta Realiza escrituras por lotes.

Cuándo no usar escrituras por lotes

Si escribes datos masivos en filas que no están cerca unas de las otras.. Bigtable almacena los datos lexicográficamente por clave de fila, el equivalente binario del orden alfabético. Debido a esto, cuando las claves de fila de una solicitud no son similares, Bigtable las maneja secuencialmente, en lugar de hacerlo en paralelo. La capacidad de procesamiento será alta, pero la latencia también lo será. Para evitar este problema, usa MutateRows cuando las claves de fila sean similares, y Bigtable escribirá filas que estén cerca unas de otras. Usa MutateRow o escrituras simples para las filas que no estén cerca.
Si solicitas varias mutaciones para la misma fila. En este caso, obtendrás un mejor rendimiento si realizas todas las mutaciones en una sola solicitud de escritura simple. Esto se debe a que, en una escritura simple, todos los cambios se confirman en una acción atómica, pero una escritura por lotes se fuerza a serializar mutaciones en la misma fila, lo que provoca latencia.

Coherencia en el uso de la replicación

El tiempo que tardan en leerse los datos que escribes depende de varios factores, como la cantidad de clústeres de la instancia y el tipo de enrutamiento que usa tu perfil de aplicaciones. En una instancia de un solo clúster, los datos se pueden leer inmediatamente, pero si una instancia tiene más de un clúster (es decir, que usa replicación), Bigtable aplica un modelo de coherencia eventual. Para lograr la coherencia de lectura y escritura, enruta las solicitudes al mismo clúster.

Puedes crear y usar un token de coherencia después de enviar las solicitudes de escritura. El token verifica la coherencia de la replicación. En general, se suele crear un token de coherencia después enviar un lote de escrituras o después de un período determinado, como una hora. Luego, puedes entregar el token para que lo use otro proceso, como un módulo que realiza una solicitud de lectura y que usa el token para asegurarse de que todos los datos se hayan replicado antes de intentar leerlos.

Si usas un token inmediatamente después de crearlo, es posible que le tome unos minutos verificar la coherencia. Este retraso se debe a que cada clúster verifica otro clúster para asegurarse de que no haya más datos. Después del uso inicial o, si esperas varios minutos antes de usar el token por primera vez, este se ejecuta de inmediato cada vez que se utiliza.

Resolución de conflictos

Cada valor de celda en una tabla de Bigtable se identifica de forma única con la tupla de cuatro elementos (clave de fila, familia de columnas, calificador de columna, marca de tiempo). Consulta el modelo de almacenamiento de Bigtable para obtener más detalles sobre estos identificadores. En el caso poco frecuente de que dos escrituras con la misma tupla cuatro veces se envíen a dos clústeres diferentes, Bigtable resuelve automáticamente el conflicto con un algoritmo interno de ventaja de la última escritura según la hora del servidor. La implementación de Bigtable "gana la última escritura" es determinista y, cuando la replicación se actualiza, todos los clústeres tienen el mismo valor para la tupla de cuatro elementos.