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 cuándo debes usarlas y cuándo no.

La API de Bigtable Data y las bibliotecas cliente 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 replicadas y de un solo clúster, con enrutamiento de un solo clúster o de varios clústeres.

Para las operaciones de escritura por lotes y de transmisión, puedes usar el [conector de Bigtable Beam. Para obtener más información, consulta Escrituras por lotes.

Para obtener 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 Cloud Bigtable.

Para obtener información sobre cómo agregar datos a celdas agregadas, consulta Valores agregados en el momento de escritura (Vista previa).

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 de la fecha y hora actuales, que se mide como el tiempo transcurrido desde el tiempo Unix, 00:00:00 UTC del 1 de enero de 1970.

Una marca de tiempo que envías 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 sola solicitud de escritura tienen la misma marca de tiempo, a menos que las anules. Puedes configurar la marca de tiempo de todas las mutaciones de una solicitud de escritura para que sea igual o diferente entre sí.

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

En muchos casos, el uso de agregaciones (Vista previa), que te permite actualizar un valor en el momento de la escritura, es la mejor opción para los casos en los que deseas aumentar o incluir un valor. Sin embargo, las agregaciones no admiten operaciones de anexo. Para obtener más información, consulta Agrega valores en el momento de la escritura.

Si quieres agregar datos a un valor existente o necesitas aumentar un valor numérico existente y no puedes usar agregados, puedes enviar una solicitud ReadModifyWriteRow. Esta solicitud incluye el nombre de la tabla, el ID del perfil de la app 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 agregado 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 `ReadModifyWriteRow`

No debes enviar solicitudes ReadModifyWriteRow en las siguientes situaciones:

Tu caso de uso se puede controlar con agregaciones (vista previa).
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 deseas contar un total de millones, como las vistas de páginas, debes usar agregaciones para actualizar los recuentos en el momento de la escritura. También puedes considerar registrar cada vista como una escritura simple en lugar de aumentar un valor y, luego, 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 del lote que no funcionan, hasta que todas las escrituras sean exitosas o se alcance el plazo de la solicitud. Luego, muestra una respuesta que identifica cada escritura en el lote y si 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 de forma lexicográfica 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 las escrituras por lotes mediante una de las siguientes opciones, puedes habilitar el control de flujo de escritura por lotes en el código.

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

Limita la frecuencia del tráfico para evitar la sobrecarga de 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 cuando sea necesario.

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

Debes usar un perfil de aplicación configurado para el enrutamiento de un solo clúster. Habilitar el ajuste de escala automático de Bigtable para el clúster de destino no es un requisito, 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 como 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 una muestra de código que demuestre cómo habilitar el control de flujo de escritura por lotes mediante el conector de Bigtable HBase Beam , consulta Escribe en Bigtable.

Escribe 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 el acceso de vista autorizado.

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

Todas las escrituras en una vista autorizada se aplican de forma directa a la tabla subyacente.

Limitaciones de definición de vistas autorizadas

En una vista autorizada, la definición de vista autorizada limita las filas o columnas en las que puedes escribir datos. 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 por 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.

De manera similar, si la vista autorizada está definida por 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.

La 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.

Se mostrará un mensaje de error de PERMISSION_DENIED ante cualquier solicitud que escriba datos o haga referencia a ellos fuera de la vista autorizada.

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ías a una instancia replicada se confirma como una acción atómica única en el clúster al que se enruta la solicitud. Cuando la escritura se replica en los otros clústeres de la instancia, cada uno de esos clústeres recibe la escritura como una operación atómica. Los clústeres no reciben mutaciones parciales; una mutación se realiza correctamente o falla de forma atómica para todas las celdas 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 modo StandardReadRemoteWrites después de enviar solicitudes de escritura. El token verifica la coherencia de la replicación. En general, puedes crear un token de coherencia después de que se haya enviado un lote de escrituras o después de un intervalo 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, que usa el token para verificar que todos los datos se hayan replicado antes de que se intente leer.

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 común de que dos escrituras con la misma tupla cuatro se envíen a dos clústeres diferentes, Bigtable resuelve automáticamente el conflicto con un algoritmo interno de la última escritura gana 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.