Google utiliza tecnología de IA para traducir contenido a tu idioma preferido. Las traducciones realizadas con IA pueden contener errores.

Escrituras

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

La API de datos de Bigtable y las bibliotecas cliente te permiten escribir datos en tus tablas de manera programática. 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.

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 Escrituras 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 la 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, medidas como el tiempo transcurrido desde el tiempo Unix, 00:00:00 UTC del 1 de enero de 1970.

De forma predeterminada, una marca de tiempo que envías a Bigtable debe ser un valor de microsegundos con una precisión de milisegundos como máximo. Bigtable rechaza las marcas de tiempo con precisión de microsegundos, como 3023483279876543, a menos que escribas en una tabla con nivel de detalle de marca de tiempo de microsegundos. Las tablas con nivel de detalle de microsegundos aceptan marcas de tiempo proporcionadas por el usuario con precisión de microsegundos completa. Esta función solo está disponible para las instancias de la edición Enterprise Plus.

Todas las mutaciones en una sola solicitud de escritura tienen la misma marca de tiempo, a menos que las anules. Puedes establecer que la marca de tiempo de todas las mutaciones en una solicitud de escritura sea la misma 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.

Actualizaciones incrementales

Bigtable te permite crear celdas con un tipo de datos de agregación. Las celdas de agregación están optimizadas para cuando deseas cambiar los valores en las celdas de la tabla existentes, lo que agrega 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 acumulada.
Mínimo: Envía un número entero a una celda y Bigtable conserva el menor de los dos valores.
Máximo: Envía un número entero a una celda y Bigtable conserva el mayor 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.

Adjuntar

Para agregar datos a un valor existente, puedes usar 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 que se deben usar cuando se escriben los datos. Cada regla incluye el nombre de la familia de columnas, el calificador de columna y un valor de adición o un importe 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 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 ReadModifyWriteRow, pero te recomendamos que uses celdas agregadas y AddToCell o MergeToCell en su lugar. Un valor se puede incrementar con ReadModifyWrite solo si se codifica como un entero con signo big-endian de 64 bits. Bigtable trata un incremento de un valor vacío o inexistente como si el valor fuera cero.

Las solicitudes ReadModifyWriteRow son atómicas. No se reintentan si fallan por algún motivo.

Cuándo no usar `ReadModifyWriteRow`

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

Tu caso de uso se puede controlar enviando una solicitud MutateRow con una mutación AddToCell. Para obtener más información, consulta Agrega valores en el momento de la escritura.
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.
Escribes grandes cantidades de datos y necesitas que las escrituras se completen con rapidez. Una solicitud que lee y, luego, modifica una fila es más lenta que una solicitud de escritura simple. Por lo tanto, este tipo de escritura no suele ser el mejor enfoque a gran escala.

Por ejemplo, si quieres contar algo que se medirá en millones, como las vistas de página, 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 de fila 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.

Debido a que una escritura condicional lee la fila para evaluar el filtro, el emisor debe tener los permisos bigtable.tables.readRows y bigtable.tables.mutateRows en la tabla (o los permisos equivalentes bigtable.authorizedViews.readRows y bigtable.authorizedViews.mutateRows en una vista autorizada). Para obtener más información, consulta Control de acceso.

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 condicional deben leer las filas antes de modificarlas, por lo que las solicitudes CheckAndModifyRow son más lentas que las solicitudes de escritura simples. Por lo tanto, este tipo de escritura no suele ser el mejor enfoque 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 haya realizado correctamente, hasta que todas las escrituras se realicen de forma correcta o se alcance la fecha límite de la solicitud. Luego, devuelve 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 tus escrituras por lotes (incluidas las eliminaciones) con una de las siguientes opciones, puedes habilitar el control de flujo de escritura por lotes 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 frecuencia del 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 al clúster de forma automática cuando sea necesario.

Estas acciones combinadas evitan la sobrecarga del clúster y la falla del trabajo, y no necesitas escalar manualmente el clúster antes de ejecutar la 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 puede tardar más en finalizar que si escalas el clúster de forma manual.

Debes usar un perfil de app 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 de 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 los 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 escritura por lotes.

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 a la vista autorizada.

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 en 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 la cadena examplepetstore1 completa.

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 verificas un valor en una solicitud de escritura condicional.

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

Replicación

Cuando un clúster de una instancia replicada recibe una 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 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, cada uno de esos clústeres también recibe la escritura como una operación atómica. Los clústeres no reciben mutaciones parciales; una mutación se ejecuta 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.

Con una instancia de un solo clúster, los datos se pueden leer de inmediato, pero si una instancia tiene más de un clúster, lo que significa que usa la replicación, Bigtable es coherencia eventual. Puedes lograr la coherencia de lectura de tus escrituras enrutando 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, creas un token de coherencia después de que se envía 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 se hayan replicado todos los datos antes de intentar 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 caso de que se envíen dos escrituras con la misma tupla de cuatro elementos a dos clústeres diferentes, Bigtable resuelve automáticamente el conflicto con un algoritmo interno de gana la última escritura basado en 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.