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

Escrituras

En esta página, se enumeran los tipos de solicitudes de escritura que puedes enviar a Bigtable y se describe en qué situaciones debes usarlas. Para obtener información sobre cómo agregar datos en una celda en el momento de la escritura, consulta Cómo agregar valores en el momento de la escritura.

Las APIs de datos y las bibliotecas cliente de 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 Bigtable Beam. Para obtener más información, consulta Escritura por lotes.

Para obtener más información sobre los límites que se aplican a las solicitudes de escritura, consulta Cuotas y límites.

Para ver ejemplos de biblioteca cliente de Cloud Bigtable de las solicitudes de escritura que se describen en esta página, consulta Ejemplos de escritura.

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 elementos:
- 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, measured as the time that has elapsed since the Unix epoch, 00:00:00 UTC on January 1, 1970.

La marca de tiempo que envíes a Bigtable debe ser un valor de microsegundos con una precisión de milisegundos como máximo. Se rechaza una marca de tiempo con precisión de microsegundos, como 3023483279876543. En este ejemplo, el valor de marca de tiempo aceptable es 3023483279876000.

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.

Las agregaciones, incluidos los incrementos

Los agregados son celdas de tablas de Bigtable que agregan valores de celda a medida que se escriben los datos. Los siguientes tipos de agregación están disponibles:

Suma: Incrementa un contador o mantén una suma en curso.
Mínimo: Envía un número entero a una celda y Bigtable conserva el valor más bajo entre el valor actual de la celda y el valor enviado, o el valor enviado si la celda aún no existe.
Máximo: Envía un número entero a una celda que contiene un valor y Bigtable conserva el más alto de los dos valores.
HyperLogLog (HLL): Envía un valor que se agrega a un conjunto probabilístico de todos los valores agregados a la celda.

Las solicitudes para actualizar las celdas agregadas se envían con una solicitud MutateRow y un tipo de mutación de AddToCell o MergeToCell, o uno de los tipos de mutación de eliminación. Para obtener más información sobre las familias de columnas agregadas y los tipos de agregación, consulta Agrupa valores en el momento de la escritura.

Adjuntar

Para adjuntar datos a un valor existente, puedes usar 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 agregar el valor de una columna que contiene el valor some con la cadena thing, y una regla posterior en la misma solicitud agrega esa misma columna con body, el valor se modifica dos veces en una sola operación de escritura atómica, y el valor resultante es somethingbody. La regla posterior no reemplaza a la anterior.

También puedes incrementar un número entero con una llamada a ReadModifyWriteRow, pero te recomendamos que, en su lugar, uses celdas agregadas y AddToCell o MergeToCell. Solo se puede incrementar un valor con ReadModifyWrite 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 cualquier motivo.

Cuándo no se debe usar `ReadModifyWriteRow`

No envíes solicitudes de ReadModifyWriteRow en las siguientes situaciones:

Para controlar tu caso de uso, envía una solicitud de MutateRow con una mutación de AddToCell. Para obtener más información, consulta Agregaciones.
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 puede volver a intentar una solicitud ReadModifyWriteRow.
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, debes MutateRow con una mutación AddToCell para actualizar tus recuentos en el momento de la escritura.

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.
Si escribes grandes cantidades de datos y necesitas que las escrituras se completen rápidamente. Al igual que ReadModifyWriteRow, las solicitudes de escritura condicionales deben leer filas antes de modificarlas, por lo que las solicitudes de CheckAndModifyRow son más lentas que las solicitudes de escritura simples. Por consiguiente, este tipo de escritura no suele ser el enfoque más adecuado para tareas a gran escala.

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 cualquier entrada del lote que no se realice correctamente hasta que se completen todas las operaciones de escritura o se alcance la fecha límite de la solicitud. Luego, muestra una respuesta que identifica cada operación de escritura en el lote y si esta se realizó correctamente 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.

Control de flujo de escritura por lotes

Si envías tus operaciones de escritura masiva (incluidas las eliminaciones) con una de las siguientes opciones, puedes habilitar el control de flujo de operaciones de escritura masiva en tu código.

Cuando se habilita el control de flujo de escritura por lotes para un trabajo de Dataflow, Bigtable hace lo siguiente de forma automática :

Limita la tasa de tráfico para evitar sobrecargar tu clúster de Bigtable
Garantiza que el clúster tenga suficiente carga para activar el ajuste de escala automático de Bigtable (si está habilitado), de modo que se agreguen más nodos automáticamente al clúster cuando sea necesario.

Estas acciones combinadas evitan la sobrecarga del clúster y la falla de la tarea, y no necesitas escalar tu clúster de forma manual antes de ejecutar la operación de escritura por lotes. Cuando el control de flujo está habilitado, el escalamiento del clúster se produce durante el trabajo de Dataflow en lugar de antes, por lo que el trabajo podría tardar más en completarse que si escalas el clúster de forma manual.

Debes usar un perfil de app configurado para el enrutamiento de un solo clúster. No es un requisito habilitar el ajuste de escala automático de Bigtable para el clúster de destino, pero el ajuste de escala automático te permite aprovechar al máximo el control del flujo de escritura por lotes. Puedes usar el ajuste de escala automático de Dataflow de la misma manera que lo harías con cualquier otro trabajo.

Para obtener más información sobre el ajuste de escala automático de Bigtable, consulta Ajuste de escala automático. Para comprender las políticas de enrutamiento de perfiles de app, consulta Descripción general de los perfiles de app.

Para ver muestras de código, consulta Habilita el control de flujo de escrituras por lotes.

Cómo escribir datos en una vista autorizada

Para escribir datos en una vista autorizada, debes usar una de las siguientes opciones:

gcloud CLI
Cliente de Bigtable para Java

Las otras bibliotecas cliente de Bigtable aún no admiten acceso autorizado a vistas.

Cuando escribes datos en una vista autorizada, proporcionas el ID de la vista autorizada además del ID de la tabla.

Todas las operaciones de escritura en una vista autorizada se aplican directamente a la tabla subyacente.

Limitaciones de la definición de vistas autorizadas

En una vista autorizada, las filas o columnas a las que puedes escribir datos están limitadas por la definición de la vista autorizada. En otras palabras, solo puedes escribir en filas y columnas que cumplan con los mismos criterios especificados para la vista autorizada.

Por ejemplo, si la vista autorizada se define con el prefijo de clave de fila examplepetstore1, no puedes escribir datos con una clave de fila de examplepetstore2. El comienzo del valor de la clave de fila debe incluir toda la cadena examplepetstore1.

Del mismo modo, si la vista autorizada se define con el prefijo del calificador de columna order-phone, puedes escribir datos con el calificador de columna order-phone123, pero no puedes usar el calificador de columna order-tablet.

Tu solicitud de escritura tampoco puede hacer referencia a datos que estén fuera de la vista autorizada, como cuando buscas un valor en una solicitud de escritura condicional.

Para cualquier solicitud que escriba o haga referencia a datos fuera de la vista autorizada, se muestra un mensaje de error de PERMISSION_DENIED.

Replicación

Cuando un clúster de una instancia replicada recibe una operación de escritura, esta se replica de inmediato en los otros clústeres de la instancia.

Atomicidad

Cada solicitud MutateRows que envíes a una instancia replicada se confirma como una sola acción atómica en el clúster al que se enruta la solicitud. Cuando la escritura se replica en los otros clústeres de la instancia, esos clústeres también reciben la escritura como una operación atómica. Los clústeres no reciben mutaciones parciales. Una mutación se realiza de forma correcta o falla de forma atómica para todas las células que modifica.

Coherencia

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 y llamar a CheckConsistency en el modo StandardReadRemoteWrites después de enviar 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 Modelo de almacenamiento de Bigtable para obtener más detalles sobre estos identificadores. En el caso poco frecuente de que dos operaciones de escritura con la misma tupla de cuatro elementos se envíen a dos clústeres diferentes, Bigtable resolverá automáticamente el conflicto con un algoritmo interno de gana la última escritura según el tiempo 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.