Escrituras

En esta página se enumeran los tipos de solicitudes de escritura que puede enviar a Bigtable y se describe cuándo debe usarlas y cuándo no. Para obtener información sobre cómo agregar datos en una celda al escribir, consulta Agregar valores al escribir.

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

Cada biblioteca de cliente ofrece la posibilidad de enviar los siguientes tipos de solicitudes de escritura:

  • Operaciones de escritura sencillas
  • Incrementos y anexiones
  • Escrituras condicionales
  • Escrituras por lotes

Las bibliotecas de cliente de Bigtable tienen una función de reintentos inteligentes integrada para escrituras simples y por lotes, lo que significa que gestionan sin problemas la indisponibilidad temporal. Por ejemplo, si tu aplicación intenta escribir datos y se produce una interrupción temporal o un problema de red, se vuelve a intentar automáticamente hasta que se confirme la escritura o se alcance el plazo de la solicitud. Esta resistencia funciona tanto con instancias de un solo clúster como con instancias replicadas, con enrutamiento de un solo clúster o de varios clústeres.

Para las operaciones de escritura por lotes y en tiempo real, 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.

Para ver ejemplos de bibliotecas de cliente de Cloud Bigtable de las solicitudes de escritura descritas 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:

  • Nombre de la tabla en la que se va a escribir.
  • Un ID de perfil de aplicación, que indica a Bigtable cómo enrutar el tráfico.
  • Una o varias mutaciones. Una mutación consta de los siguientes elementos:
    • Nombre de la familia de columnas
    • Calificador de columna
    • Marca de tiempo
    • Valor que se escribe en la tabla

La marca de tiempo de una mutación tiene el valor predeterminado de la fecha y la hora actuales, medidas como el tiempo transcurrido desde la época de Unix, es decir, las 00:00:00 UTC del 1 de enero de 1970.

La marca de tiempo que envíes a Bigtable debe ser un valor en 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 única tienen la misma marca de tiempo, a menos que las anules. Puede definir la marca de tiempo de todas las mutaciones de una solicitud de escritura para que sea la misma o diferente entre sí.

Operaciones de escritura sencillas

Puedes escribir una sola fila en Bigtable con una solicitud 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 para esa fila. La escritura de una sola fila es atómica. Usa este tipo de escritura cuando hagas varias mutaciones en una sola fila.

Para ver ejemplos de código que muestran cómo enviar solicitudes de escritura sencillas, consulta Realizar una escritura sencilla.

Cuándo no usar escrituras simples

Las escrituras simples no son la mejor forma de escribir datos en los siguientes casos prácticos:

  • Vas a escribir un lote de datos que tendrá claves de fila contiguas. En este caso, debes usar escrituras por lotes en lugar de escrituras simples consecutivas, ya que un lote contiguo se puede aplicar en una sola llamada de backend.

  • Quieres un alto rendimiento (filas por segundo o bytes por segundo) y no necesitas una latencia baja. En este caso, las escrituras por lotes serán más rápidas.

Actualizaciones incrementales

Bigtable te permite crear celdas con el tipo de datos aggregate. Las celdas de agregación están optimizadas para cuando quieras cambiar los valores de las celdas de una tabla, ya que agregan los valores de las celdas a medida que se escriben los datos. Están disponibles los siguientes tipos de agregación:

  • Suma: incrementa un contador o mantiene una suma continua.
  • 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 añade a un conjunto probabilístico de todos los valores añadidos a la celda.

Las solicitudes para actualizar celdas agregadas se envían con una solicitud MutateRow y un tipo de mutación AddToCell o MergeToCell, o bien uno de los tipos de mutación de eliminación.

Añade

Para añadir datos a un valor, puedes usar una solicitud ReadModifyWriteRow. Esta solicitud incluye el nombre de la tabla, el ID del perfil de aplicación que se debe usar, una clave de fila y un conjunto de reglas que se deben usar al escribir los datos. Cada regla incluye el nombre de la familia de columnas, el calificador de columna y un valor de anexión o un importe de incremento.

Las reglas se aplican en orden. Por ejemplo, si tu solicitud incluye una petición para añadir el valor de una columna que contiene el valor some con la cadena thing, y una regla posterior de la misma solicitud añade a esa misma columna el valor body, el valor se modifica dos veces en una sola escritura atómica y el valor resultante es somethingbody. La regla posterior no sobrescribe la anterior.

También puedes incrementar un número entero con una llamada ReadModifyWriteRow, pero te recomendamos que uses celdas de agregación y AddToCell o MergeToCell. Un valor se puede incrementar con ReadModifyWrite solo si está codificado como un número entero con signo de 64 bits en formato big-endian. Bigtable trata un incremento de un valor vacío o que no existe como si el valor fuera cero.

Las solicitudes ReadModifyWriteRow son atómicas. No se vuelven a intentar si fallan por cualquier motivo.

Cuándo no se deben utilizar ReadModifyWriteRow

No envíe solicitudes ReadModifyWriteRow en las siguientes situaciones:

  • Tu caso práctico se puede gestionar enviando una solicitud MutateRow con una mutación AddToCell. Para obtener más información, consulta Agregar valores en el momento de la escritura.

  • Estás usando un perfil de aplicación que tiene enrutamiento a varios clústeres.

  • Estás usando varios perfiles de aplicación de un solo clúster y enviando escrituras que podrían entrar en conflicto con los datos escritos en la misma fila y columna de otros clústeres de la instancia. Con el enrutamiento de un solo clúster, una solicitud de escritura se envía a un solo clúster y, a continuación, se replica.

  • Utilizas la función reintentos inteligentes que proporcionan las bibliotecas de cliente. No se puede volver a intentar una solicitud ReadModifyWriteRow.

  • Estás escribiendo grandes cantidades de datos y necesitas que las escrituras se completen rápidamente. Una solicitud que lee y, a continuación, modifica una fila es más lenta que una solicitud de escritura simple. Por lo tanto, este tipo de escritura no suele ser la mejor opción a gran escala.

    Por ejemplo, si quieres contar algo que se mida en millones, como las vistas de páginas, debes MutateRow con una AddToCell mutación para actualizar los recuentos en el momento de la escritura.

Escrituras condicionales

Si quieres comprobar si se cumple una condición en una fila y, en función del resultado, escribir datos en esa fila, envía una solicitud CheckAndMutateRow. Este tipo de solicitud incluye una clave de fila y un filtro de fila. Un filtro de filas es un conjunto de reglas que se usan para comprobar el valor de los datos. Las mutaciones se confirman en columnas específicas de la fila solo cuando se cumplen determinadas condiciones, que comprueba el filtro. Este proceso de comprobación y escritura se completa como una sola acción atómica.

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

  • Mutaciones verdaderas o mutaciones que se aplican si el filtro devuelve un valor.
  • Mutaciones falsas, que se aplican si el filtro no da ningún resultado.

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 se completan todas las mutaciones.

Para ver ejemplos de código que muestran cómo enviar escrituras condicionales, consulta Escribir un valor de forma condicional.

Cuándo no usar escrituras condicionales

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

  • Estás usando un perfil de aplicación que tiene enrutamiento a varios clústeres.

  • Estás usando varios perfiles de aplicación de un solo clúster y enviando escrituras que podrían entrar en conflicto con los datos escritos en la misma fila y columna 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, a continuación, se replica.

  • Estás escribiendo grandes cantidades de datos y necesitas que las escrituras se completen rápidamente. Al igual que ReadModifyWriteRow, las solicitudes de escritura condicional necesitan leer 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 la mejor opción a gran escala.

Escrituras por lotes

Puedes escribir más de una fila con una sola llamada mediante una solicitud MutateRows. Las solicitudes MutateRows contienen un conjunto de hasta 100.000 entradas que se aplican de forma atómica. Cada entrada consta de 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 repartidas entre todas las entradas. Por ejemplo, una escritura por lotes podría incluir cualquiera de las siguientes permutaciones:

  • 100.000 entradas con 1 mutación en cada una.
  • 1 entrada con 100.000 mutaciones.
  • 1000 entradas con 100 mutaciones cada una.

Cada entrada de una solicitud MutateRows es atómica, pero la solicitud en su conjunto no lo es. Si es necesario, Bigtable vuelve a intentar escribir las entradas del lote que no se hayan escrito correctamente hasta que todas las escrituras se completen o se alcance la fecha límite de la solicitud. A continuación, devuelve una respuesta que identifica cada escritura del lote e indica si se ha completado correctamente o no.

Para ver ejemplos de código que muestran cómo enviar escrituras por lotes, consulta Realizar escrituras por lotes.

Cuándo no usar escrituras por lotes

  • Estás escribiendo datos en bloque en filas que no están cerca entre sí. Bigtable almacena los datos lexicográficamente por clave de fila, que es el equivalente binario del orden alfabético. Por este motivo, cuando las claves de fila de una solicitud no son similares entre sí, Bigtable las gestiona de forma secuencial en lugar de en paralelo. El rendimiento será alto, pero la latencia también lo será. Para evitar esa latencia alta, usa MutateRows cuando las claves de las filas sean similares y Bigtable escriba filas que estén cerca unas de otras. Usa MutateRow o escrituras sencillas para las filas que no estén cerca entre sí.

  • Está solicitando varias mutaciones en la misma fila. En este caso, el rendimiento será mejor si realizas todas las mutaciones en una sola solicitud de escritura simple. Esto se debe a que, en una operación de escritura sencilla, todos los cambios se confirman en una sola acción atómica, pero una operación de escritura por lotes se ve obligada a serializar las 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) mediante una de las siguientes opciones, puedes habilitar el control de flujo de escritura por lotes en tu código.

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

  • Limita el tráfico para evitar sobrecargar el clúster de Bigtable.
  • Asegura que el clúster tenga suficiente carga para activar el autoescalado de Bigtable (si está habilitado), de forma que se añadan automáticamente más nodos al clúster cuando sea necesario.

Estas acciones combinadas evitan que el clúster se sobrecargue y que las tareas fallen, y no es necesario que lo escales manualmente antes de ejecutar la escritura por lotes. Cuando el control de flujo está habilitado, el escalado del clúster se produce durante el trabajo de Dataflow en lugar de antes, por lo que el trabajo puede tardar más en completarse que si escalaras el clúster manualmente.

Debes usar un perfil de aplicación configurado para el enrutamiento de un solo clúster. No es obligatorio habilitar el autoescalado de Bigtable en el clúster de destino, pero te permite aprovechar al máximo el control del flujo de escritura por lotes. Puedes usar el autoescalado de Dataflow como lo harías con cualquier otro trabajo.

Para obtener más información sobre el autoescalado de Bigtable, consulte Autoescalado. Para conocer las políticas de enrutamiento de perfiles de aplicaciones, consulta el resumen de perfiles de aplicaciones.

Para ver ejemplos de código, consulta Habilitar el control del flujo de escritura por lotes.

Escribir datos en una vista autorizada

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

  • CLI de gcloud
  • Cliente de Bigtable para Java

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

Cuando escribe datos en una vista autorizada, debe proporcionar 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 tabla subyacente.

Limitaciones de las definiciones 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. Es decir, solo puede escribir en las filas y columnas que cumplan los mismos criterios especificados en la vista autorizada.

Por ejemplo, si la vista autorizada se define mediante el prefijo de clave de fila examplepetstore1, no podrá escribir datos con la clave de fila examplepetstore2. El valor de la clave de fila debe incluir toda la cadena examplepetstore1.

Del mismo modo, si la vista autorizada se define mediante el prefijo order-phone del calificador de columna, puede escribir datos con el calificador de columna order-phone123, pero no puede 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 compruebas un valor en una solicitud de escritura condicional.

En el caso de las solicitudes que escriban o hagan referencia a datos fuera de la vista autorizada, se devolverá un mensaje de error PERMISSION_DENIED.

Replicación

Cuando un clúster de una instancia replicada recibe una escritura, esta se replica inmediatamente en los demás 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 dirige la solicitud. Cuando la escritura se replica en los demás clústeres de la instancia, cada uno de ellos también 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 estar disponibles para lectura los datos que escribes depende de varios factores, como el número de clústeres de tu instancia y el tipo de enrutamiento que utilice tu perfil de aplicación.

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, lo que significa que está usando la replicación, Bigtable es eventualmente coherente. Para conseguir la coherencia inmediata (read-your-writes), puedes enrutar 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 comprueba la coherencia de la replicación. Por lo general, se crea un token de coherencia después de enviar un lote de escrituras o tras un intervalo determinado, como una hora. Después, puedes transferir el token para que lo use otro proceso, como un módulo que haga una solicitud de lectura, que usa el token para comprobar que todos los datos se han replicado antes de intentar leerlos.

Si usas un token justo después de crearlo, puede que tarde unos minutos en comprobar la coherencia la primera vez que lo uses. Este retraso se debe a que cada clúster comprueba todos los demás para asegurarse de que no se reciban más datos. Después del primer uso o si esperas varios minutos para usar el token por primera vez, el token se usará correctamente cada vez que se utilice.

Resolución de conflictos

Cada valor de celda de una tabla de Bigtable se identifica de forma única mediante la tupla de cuatro elementos (clave de fila, familia de columnas, calificador de columna y marca de tiempo). Consulta el modelo de almacenamiento de Bigtable para obtener más información sobre estos identificadores. Si se envían dos escrituras con la misma tupla de cuatro elementos a dos clústeres diferentes, Bigtable resuelve automáticamente el conflicto mediante un algoritmo interno last write wins basado en la hora del servidor. La implementación de Bigtable de "la última escritura gana" es determinista y, cuando la replicación se pone al día, todos los clústeres tienen el mismo valor para la tupla de cuatro elementos.

Siguientes pasos