Opciones de enrutamiento

Cuando envías solicitudes de una aplicación a Bigtable, usas un perfil de aplicación que indica a Bigtable cómo gestionar las solicitudes. Un perfil de aplicación especifica la política de enrutamiento de las solicitudes. En las instancias que usan la replicación, la política de enrutamiento controla qué clústeres reciben las solicitudes y cómo se gestionan las conmutaciones por error.

En este documento se describen las políticas de enrutamiento disponibles para un perfil de aplicación estándar.

Las políticas de enrutamiento son especialmente importantes en los casos prácticos de aislamiento de cargas de trabajo, cuando no puedes usar Data Boost. Puedes configurarlos junto con las prioridades de las solicitudes.

Las políticas de enrutamiento no afectan a la replicación, pero debes saber cómo funciona la replicación de Bigtable antes de leer esta página. También debes leer la sección sobre conmutaciones por error.

Enrutamiento de un solo clúster

Una política de enrutamiento de un solo clúster dirige todas las solicitudes a un clúster de tu instancia. Si ese clúster deja de estar disponible, debes cambiar manualmente a otro clúster.

Esta es la única política de enrutamiento que te permite habilitar las transacciones de una sola fila.

Una instancia replicada suele proporcionar consistencia eventual. Sin embargo, puedes conseguir la coherencia de lectura y escritura de una carga de trabajo en una instancia replicada si configuras un perfil de aplicación para que esa carga de trabajo use el enrutamiento de un solo clúster para enviar solicitudes de lectura y escritura al mismo clúster. Puedes enrutar el tráfico de cargas de trabajo adicionales en la instancia replicada a otros clústeres de la instancia en función de los requisitos de tu carga de trabajo.

Enrutamiento de varios clústeres

Una política de enrutamiento de varios clústeres dirige las solicitudes que envías a una instancia a la región más cercana en la que la instancia tenga un clúster. Si el clúster deja de estar disponible, el tráfico se redirige automáticamente al clúster disponible más cercano.

Esta configuración proporciona coherencia final. No puedes habilitar las transacciones de una sola fila con el enrutamiento multiclúster, ya que estas transacciones pueden provocar conflictos de datos cuando usas el enrutamiento multiclúster. Para obtener más información, consulta Transacciones de una sola fila.

Usa el enrutamiento de varios clústeres si quieres disfrutar de alta disponibilidad. Para obtener más información sobre las configuraciones de instancias recomendadas y otros detalles, consulta Crear alta disponibilidad (HA).

Los dos tipos de enrutamiento de varios clústeres son cualquier clúster y grupo de clústeres.

Para obtener más información sobre las consideraciones de enrutamiento relacionadas con SQL, consulta la sección Enrutamiento con SQL de este documento.

Enrutamiento de clústeres

El enrutamiento de clústeres hace que todos los clústeres de la instancia estén disponibles para recibir solicitudes y para la conmutación por error.

Enrutamiento de grupos de clústeres

Si quieres excluir uno o varios clústeres de una instancia de la posible conmutación por error, puedes usar el enrutamiento de grupos de clústeres. Este tipo de enrutamiento a varios clústeres te permite especificar un subconjunto de clústeres a los que puede enviar tráfico un perfil de aplicación. Esto puede ser útil si quieres reservar un clúster para una carga de trabajo independiente.

Enrutamiento por afinidad de filas

El enrutamiento de afinidad de filas dirige automáticamente las solicitudes de lectura y escritura de una sola fila a un clúster específico en función de la clave de fila de la solicitud.

Si quieres que el enrutamiento de varios clústeres consiga una mayor tasa de coherencia de lectura-escritura y la mayoría de tus solicitudes son operaciones de una sola fila, puedes usar el enrutamiento de afinidad de fila (enrutamiento persistente). Para habilitar el enrutamiento de afinidad de filas, usa un perfil de aplicación personalizado con la marca --row-affinity habilitada. Bigtable usa la clave de fila de la solicitud para determinar automáticamente a qué clúster debe dirigir la solicitud. No puedes definir manualmente la asignación entre la clave de fila y el clúster.

El enrutamiento de afinidad de filas solo se puede usar en solicitudes de lectura o escritura de una sola fila. Esto incluye las solicitudes que llaman a ReadRows con una clave especificada, MutateRow y MutateRows con una clave especificada, y BulkMutateRow con una clave especificada.

La coherencia inmediata (read-your-writes) no se consigue por completo con el enrutamiento de afinidad de filas en los siguientes casos:

  • Añadir un clúster a la instancia: el enrutamiento de afinidad de filas determina a qué clúster se debe enrutar en función de la clave de fila. Si se añade o se quita un clúster de la instancia mientras el enrutamiento de afinidad de filas está habilitado, es posible que cambie la asignación de la clave de fila. Para asegurarte de que el orden de conmutación por error del clúster siga siendo el mismo a pesar de los cambios en la lista de clústeres de la instancia, te recomendamos que uses grupos de clústeres configurando la marca --restrict-to.

    Con los grupos de clústeres, no puedes eliminar un clúster de una instancia mientras lo esté usando un perfil de aplicación. Además, los clústeres que se añadan a la instancia no empezarán a recibir solicitudes a menos que se añadan explícitamente al grupo de clústeres del perfil de la aplicación.

  • Conmutación por error: si un clúster no está disponible o no está en buen estado, las solicitudes al clúster afectado se dirigen al siguiente clúster según el orden de conmutación por error. Este cambio de ruta puede afectar a la coherencia.

Para obtener más información sobre las conmutaciones por error, consulta Conmutaciones por error. Para saber cómo completar una conmutación por error, consulta Gestionar conmutaciones por error.

Enrutamiento con SQL

Cuando usas SQL para consultar Bigtable, hay consideraciones especiales sobre cómo se enrutan tus solicitudes. El comportamiento de enrutamiento de las consultas de SQL difiere de otros tipos de solicitudes de Bigtable de las siguientes formas:

  • Aunque una política de enrutamiento multiclúster proporciona alta disponibilidad a través de la conmutación por error automática para la mayoría de las solicitudes, este comportamiento no se aplica a las consultas SQL. Si falla una solicitud de SQL, no se conmutará por error a otro clúster, aunque el perfil de tu aplicación esté configurado para el enrutamiento multiclúster.
  • El enrutamiento de afinidad de filas dirige las lecturas y escrituras de una sola fila automáticamente a un clúster específico en función de la clave de fila. Sin embargo, Bigtable no admite esta política de enrutamiento para las consultas de SQL. Esta limitación significa que no puedes usar el enrutamiento de afinidad de filas con el método ExecuteQuery, aunque la consulta esté diseñada para leer una sola fila. Si envías una solicitud ExecuteQuery mediante un perfil de aplicación con la marca --row-affinity habilitada, la solicitud se completará correctamente, pero no se aplicará la afinidad de filas.

Transacciones de una sola fila

En las mutaciones de Bigtable, como las solicitudes de lectura, escritura y eliminación, siempre se aplican de forma atómica a nivel de fila. Esto incluye mutaciones en varias columnas de una misma fila, siempre que se incluyan en la misma operación de mutación. Bigtable no admite transacciones que actualicen de forma atómica más de una fila.

Sin embargo, Bigtable admite algunas operaciones de escritura que requerirían una transacción en otras bases de datos. En la práctica, Bigtable usa transacciones de una sola fila para completar estas operaciones. Estas operaciones incluyen lecturas y escrituras, y todas las lecturas y escrituras se ejecutan de forma atómica, pero las operaciones siguen siendo atómicas solo a nivel de fila:

  • Operaciones de lectura-modificación-escritura, incluidos los incrementos y las anexiones. Una operación de lectura-modificación-escritura lee un valor, lo incrementa o añade algo y escribe el valor actualizado en la tabla.
  • Operaciones de comprobación y modificación, también conocidas como modificaciones condicionales o escrituras condicionales. En una operación de comprobación y modificación, Bigtable comprueba si una fila cumple una condición especificada. Si se cumple la condición, Bigtable escribe nuevos valores en la fila.

Conflictos entre transacciones de una sola fila

Todos los clústeres de una instancia de Bigtable son clústeres principales que aceptan tanto lecturas como escrituras. Por lo tanto, las operaciones que requieren transacciones de una sola fila pueden causar problemas en las instancias replicadas.

Si tu caso práctico lo permite, puedes evitar estos conflictos usando agregaciones. Cuando envías una solicitud de adición a un campo agregado, el nuevo valor se combina con el valor actual. Las agregaciones te permiten mantener una suma o un contador acumulados. Para obtener más información, consulta Agregar valores al escribir.

Para ilustrar el problema que puede surgir cuando no se usan agregaciones, supongamos que tiene una tabla que usa para almacenar datos de un sistema de venta de entradas. Utilizas un contador de números enteros para almacenar el número de entradas que se han vendido. Cada vez que vendas una entrada, tu aplicación enviará una operación de lectura-modificación-escritura para aumentar el contador en 1.

Si tu instancia tiene un clúster, las aplicaciones cliente pueden vender entradas al mismo tiempo e incrementar los contadores sin perder datos, ya que las solicitudes se gestionan de forma atómica en el orden en que las recibe ese clúster.

Por otro lado, si tu instancia tiene varios clústeres y tu perfil de aplicación permite el enrutamiento a varios clústeres, las solicitudes simultáneas para incrementar el contador se podrían enviar a diferentes clústeres y, después, replicarse en los demás clústeres de la instancia. Si envías dos solicitudes de incremento al mismo tiempo que se dirigen a clústeres diferentes, cada una completará su transacción sin "saber" nada de la otra. El contador de cada clúster se incrementa en uno. Cuando los datos se replican en el otro clúster, Bigtable no puede saber que querías incrementar el valor en 2.

Para ayudarte a evitar resultados no deseados, Bigtable hace lo siguiente:

  • Requiere que cada perfil de aplicación especifique si permite transacciones de una sola fila.
  • Impide que habilites las transacciones de una sola fila en un perfil de aplicación que utilice el enrutamiento a varios clústeres, ya que no hay ninguna forma segura de habilitar ambas funciones a la vez.
  • Te avisa si habilitas las transacciones de una sola fila en dos o más perfiles de aplicación diferentes que usan el enrutamiento de un solo clúster y apuntan a clústeres diferentes. Si decides crear este tipo de configuración, debes asegurarte de no enviar solicitudes de lectura-modificación-escritura o de comprobación y mutación conflictivas a diferentes clústeres.

Siguientes pasos