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 deberías usarlas y cuándo no. Información sobre agregar datos en una celda al momento de la escritura, consulta Agrega valores en la escritura time (vista previa).

La API de Bigtable Data y las bibliotecas cliente te permiten hacer lo siguiente: escribirás datos de forma 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 la resiliencia funciona tanto con instancias replicadas de un solo clúster, con el enrutamiento de un solo clúster o el enrutamiento de varios clústeres.

Para operaciones de escritura por lotes y por transmisión, puedes usar 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.

Para ejemplos de la biblioteca cliente de Cloud Bigtable de las solicitudes de escritura como se describe en esta página, consulta Cómo escribir ejemplos.

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. se mide como el tiempo transcurrido desde el tiempo Unix, 00:00:00 UTC el 1 de enero de 1970.

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

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

Cuando quieras aumentar o aumentar un valor, con las agregaciones, que permiten cuando actualizas un valor en el momento de la escritura, es la mejor opción. Los agregados no son compatibles de datos agregados. Para obtener más información, consulta Agrega valores en el momento de la escritura (Vista previa).

Si quieres agregar datos a un valor existente o necesitas incrementar un valor numérico existente y no puedes usar agregaciones, puedes enviar un ReadModifyWriteRow solicitud. Esta solicitud incluye el nombre de la tabla, el ID de el perfil de app que se debe usar, una clave de fila y un conjunto de reglas para usar la escritura de los datos. Cada regla incluye el nombre de la familia de columnas, el calificador de columna, y un valor agregado o un 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 envíes solicitudes ReadModifyWriteRow en las siguientes situaciones:

Tu caso de uso se puede manejar 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 volver a intentar 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 algo que será un número en la millones, como las vistas de página, deberías usar agregaciones para actualizar los recuentos en el momento de la escritura. Tú podría registrar cada vista como una escritura simple en lugar de aumentar un valor y, luego, usar un trabajo de Dataflow para agregar de datos no estructurados.

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 de los siguientes tipos de mutaciones o ambos:

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 lee las filas antes de modificarlas, por lo que las solicitudes CheckAndModifyRow son más lentas que solicitudes de escritura simples. Como resultado, este tipo de escritura no suele ser la 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 reintenta cualquier entrada del lote que no tengan éxito, hasta que todas las operaciones de escritura se realicen correctamente o hasta que el plazo de la solicitud sea alcanzada. Luego, muestra una respuesta que identifica cada escritura en el lote si la escritura 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 con una de las siguientes opciones, puedes habilitar control de flujo de escritura por lotes en tu código.

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

Limita la frecuencia del tráfico para evitar la sobrecarga de tu clúster de Bigtable.
Garantiza que el clúster tenga la carga suficiente para activar Bigtable ajuste de escala automático (si está habilitado), para 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 del trabajo, y no deberá escalar manualmente su clúster antes de ejecutar la escritura por lotes. Cuando el control de flujo está habilitado, el escalamiento del clúster se produce durante la de Dataflow en lugar de antes, por lo que el trabajo podría tardar más que si escalas tu clúster de forma manual.

Debes usar un perfil de aplicación configurado para el enrutamiento de un solo clúster. Habilitando El ajuste de escala automático de Bigtable para el clúster de destino no es pero el ajuste de escala automático permite aprovechar al máximo el flujo de escritura por lotes control. 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 el enrutamiento de perfiles de apps consulta Descripción general de los perfiles de app.

Aquí encontrarás una muestra de código en la que se demuestra cómo habilitar el control de flujo de escritura por lotes con el comando Conector de HBase de Bigtable para Bigtable, 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 son compatibles de visualización autorizado.

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

Todas las escrituras en una vista autorizada se aplican directamente a la desde una tabla de particiones.

Limitaciones de la definición de vista autorizada

En una vista autorizada, las filas o columnas en las que puedes escribir datos están limitados 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 por el prefijo de la clave de fila examplepetstore1, entonces no puedes escribir datos con una clave de fila de examplepetstore2; al comienzo del valor de la clave de fila debe incluir el valor cadena examplepetstore1.

Del mismo modo, si el calificador de columna define la vista autorizada. el prefijo order-phone, podrás escribir datos usando 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 del vista autorizada, como cuando se busca un valor en una de escritura condicional.

Para cualquier solicitud que escriba o haga referencia a datos fuera del 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, esa escritura 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 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, esos clústeres también y cada una recibe la escritura como una operación atómica. Los clústeres no reciben solicitudes parciales mutaciones una mutación es exitosa o falla atómicamente en 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 pueden leerse de inmediato, pero si tiene más de un clúster, lo que significa que usa replicación, Bigtable tiene coherencia eventual. Puedes para lograr coherencia en la 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 y verifica la coherencia de la replicación. En general, se crea un token de coherencia ya sea después de enviar un lote de escrituras o después de un cierto intervalo, como como una hora. Luego, puedes entregar el token para que lo use otro proceso, como como un módulo que realiza una solicitud de lectura, que usa el token para verificar que se asegure de todos los datos se replican antes de que intenten 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 información sobre estos identificadores. En el raro caso de que dos escriban con el se envían exactamente la misma tupla cuádruple a dos clústeres diferentes, Bigtable resuelve el conflicto con un algoritmo interno ganancia de la última escritura basado en el servidor tiempo. 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.