Opciones de enrutamiento

Cuando envías solicitudes de una aplicación a Bigtable, usas un perfil de app que le indica a Bigtable cómo controlar las solicitudes. Un perfil de app especifica la política de enrutamiento para 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 controlan las conmutaciones por error.

En este documento, se describen las políticas de enrutamiento disponibles para un perfil de app estándar.

Las políticas de enrutamiento son especialmente importantes para los casos de uso de aislamiento de cargas de trabajo, cuando no puedes usar Data Boost. Puedes configurarlos junto con las prioridades de solicitud.

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

Enrutamiento de un solo clúster

Una política de enrutamiento de un solo clúster enruta todas las solicitudes a un clúster de tu instancia. Si ese clúster no está disponible, debes realizar una conmutación por error manual a otro clúster.

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

Por lo general, una instancia replicada proporciona coherencia eventual. Sin embargo, puedes lograr la coherencia de lectura y escritura para una carga de trabajo en una instancia replicada si configuras un perfil de aplicación para esa carga de trabajo de modo que 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 según los requisitos de tu carga de trabajo.

Enrutamiento de varios clústeres

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

Esta configuración proporciona coherencia eventual. No puedes habilitar las transacciones de una sola fila con el enrutamiento de varios clústeres, ya que pueden causar conflictos de datos cuando usas el enrutamiento de varios clústeres. Para obtener más información, consulta Transacciones de una sola fila.

Usa el enrutamiento de varios clústeres si deseas alta disponibilidad (HA). Para obtener más detalles y conocer las configuraciones de instancias recomendadas, consulta Crea una 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 a cualquier clúster

El enrutamiento a cualquier clúster 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 deseas excluir uno o más clústeres de una instancia de una posible conmutación por error, puedes usar el enrutamiento de grupos de clústeres. Esta forma de enrutamiento de varios clústeres te permite especificar un subconjunto de clústeres a los que un perfil de app puede enviar tráfico. Esto puede ser útil si quieres reservar un clúster para una carga de trabajo independiente.

Enrutamiento con afinidad de fila

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

Si deseas que el enrutamiento de varios clústeres logre una mayor coherencia de lectura y escritura, y la mayoría de tus solicitudes son operaciones de una sola fila, puedes usar el enrutamiento de afinidad de filas (enrutamiento persistente). Para habilitar el enrutamiento con afinidad de fila, 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 se debe enrutar la solicitud. No puedes establecer manualmente la asignación entre la clave de fila y el clúster.

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

La coherencia en la lectura de tus escrituras no se logra por completo con el enrutamiento de afinidad de filas en los siguientes casos:

  • Agregar un clúster a la instancia: El enrutamiento con afinidad de filas determina a qué clúster se debe enrutar según la clave de fila. Si se agrega o quita un clúster nuevo de la instancia mientras el enrutamiento con afinidad de filas está habilitado, es posible que cambie la asignación de clave de fila. Para garantizar 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, recomendamos usar grupos de clústeres configurando la marca --restrict-to.

    Con los grupos de clústeres, no puedes borrar un clúster en una instancia mientras un perfil de la app lo esté usando. Además, ningún clúster nuevo que se agregue a la instancia comenzará a recibir solicitudes a menos que se agregue de forma explícita al grupo de clústeres del perfil de la app.

  • 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 la coherencia.

Para obtener más información sobre las conmutaciones por error, consulta Conmutaciones por error. Si quieres aprender a completarlas, consulta Administra 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 en SQL difiere de otros tipos de solicitudes de Bigtable de las siguientes maneras:

  • Si bien una política de enrutamiento de varios clústeres 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 extiende a las consultas SQL. Si falla una solicitud de SQL, no se conmutará por error a otro clúster, incluso si tu perfil de app está configurado para el enrutamiento de varios clústeres.
  • El enrutamiento con afinidad de filas dirige las lecturas y escrituras de una sola fila automáticamente a un clúster específico según la clave de fila. Sin embargo, Bigtable no admite esta política de enrutamiento para las consultas en SQL. Esta limitación significa que no puedes usar el enrutamiento por afinidad de filas con el método ExecuteQuery, incluso si la consulta está diseñada para leer una sola fila. Si envías una solicitud ExecuteQuery con un perfil de app que tiene habilitada la marca --row-affinity, la solicitud se realizará correctamente, pero no se aplicará la afinidad de filas.

Transacciones de fila única

En Bigtable, las mutaciones, como las solicitudes de lectura, escritura y eliminación, siempre son atómicas a nivel de la fila. Esto incluye mutaciones en varias columnas de una sola fila, siempre y cuando 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 sí admite algunas operaciones de escritura que requieren una transacción en otras bases de datos. De esta manera, Bigtable usa transacciones de fila única para completar estas operaciones. Se incluyen operaciones de lectura y de escritura, y todas se ejecutan de forma atómica, sin embargo, siguen siendo atómicas solo a nivel de la fila.

  • Operaciones lectura-modificación-escritura, incluidos los incrementos y los anexos. Una operación lectura-modificación-escritura lee un valor existente, lo incrementa o anexa y escribe el valor actualizado en la tabla.
  • Operaciones de verificación y mutación, también conocidas como mutaciones condicionales o escrituras condicionales. En este tipo de operaciones, Bigtable verifica una fila para ver si cumple con una condición específica. Si cumple con la condición, Bigtable escribe valores nuevos en la fila.

Conflictos entre las transacciones de fila única

Cada clúster de una instancia de Bigtable es un clúster principal que acepta operaciones de lectura y de escritura. Como resultado, las operaciones que requieren transacciones de una sola fila pueden causar problemas en las instancias replicadas.

Si tu caso de uso lo permite, puedes evitar estos conflictos usando agregados. Cuando envías una solicitud de adición a un campo agregado, el valor nuevo se combina con el valor existente. Los agregados te permiten mantener un contador o una suma en ejecución. Para obtener más información, consulta Agrega valores en el momento de la escritura.

Para ilustrar el problema que puede surgir cuando no usas agregados, supongamos que tienes una tabla que usas para almacenar datos de un sistema de tickets. Usas un contador de números enteros para almacenar la cantidad de tickets que se vendieron. Cada vez que vendes un ticket, tu app envía una operación de lectura-modificación-escritura para aumentar el contador en 1.

Si tu instancia tiene un clúster, las apps cliente pueden vender tickets al mismo tiempo y aumentar los contadores sin pérdida de datos porque las solicitudes se controlan de manera atómica en el orden en que las recibe ese único clúster.

Por otro lado, si la instancia tiene varios clústeres y el perfil de app permite el enrutamiento de varios clústeres, las solicitudes simultáneas para aumentar el contador se pueden enviar a diferentes clústeres y, luego, replicarse en los otros clústeres de la instancia. Si envías dos solicitudes de aumento al mismo tiempo, que se enrutan a clústeres diferentes, cada una finaliza su transacción sin “saber” sobre la otra. El contador de cada clúster aumenta en uno. Cuando los datos se replican en el otro clúster, es posible que Bigtable no sepa que querías aumentar en dos.

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

  • Requiere que cada perfil de app especifique si permite las transacciones de fila única.
  • Esto ayuda a evitar que habilites las transacciones en un perfil de app que use el enrutamiento de varios clústeres, debido a que no existe una forma segura de habilitar ambas funciones a la vez.
  • Te advierte si habilitas las transacciones de fila única en dos o más perfiles de app 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 verificación y mutación en conflicto a clústeres diferentes.

¿Qué sigue?