Opciones de enrutamiento

Cuando envías solicitudes de una aplicación a Bigtable, usas una aplicación que le indica a Bigtable cómo manejar las solicitudes. Un perfil de aplicación especifica los valores de enrutamiento política para las solicitudes. Para las instancias que usan la replicación, la política de enrutamiento controla qué clústeres reciben las solicitudes y cómo se manejan las conmutaciones por error.

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

Las políticas de enrutamiento son particularmente importantes para las cargas de trabajo casos de uso de aislamiento no podrás usar Data Boost (Vista previa). Puedes configurarlos en junto con las prioridades de solicitud.

Las políticas de enrutamiento no afectan la replicación, pero debes saber cómo Bigtable replicación antes de leer esta página. También puedes leer: 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 en tu instancia. Si ese clúster no está disponible, debes realizar una conmutación por error manual en otro clúster.

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

Una instancia replicada normalmente proporciona eventos coherencia. Sin embargo, puedes obtener lecturas de escritura coherencia para una carga de trabajo en una instancia replicada si configuras un perfil de app para esa usar el enrutamiento de un solo clúster para enviar solicitudes de lectura y escritura al mismo clúster. Puedes enrutar el tráfico a cargas de trabajo adicionales en el a otros clústeres de la instancia, según tu carga de trabajo y los requisitos de cumplimiento.

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 se vuelve el tráfico no está disponible, se conmuta por error automáticamente al clúster más cercano disponibles.

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

Usa el enrutamiento de varios clústeres si deseas alta disponibilidad (HA). Para recomendaciones configuraciones de instancias y más detalles, consulta Crea alta disponibilidad (HA).

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

Cualquier enrutamiento de clúster

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

Enrutamiento del grupo de clústeres

Si quieres excluir uno o más clústeres de una instancia de las posibles por error, puedes usar el enrutamiento de grupo 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 deseas reservar un clúster para una carga de trabajo independiente.

Transacciones de fila única

En las mutaciones de Bigtable, como las solicitudes de lectura, escritura y eliminación, siempre son atómicos a nivel de fila. Esto incluye mutaciones a varias columnas en una sola fila, siempre que se incluyan en la misma operación de mutación. Bigtable no admiten transacciones que actualizan de manera 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 de lectura, modificación y escritura, incluidos incrementos y adjuntos. Una operación de lectura, modificación y escritura lee un value; aumenta o agrega el valor existente; y escribe el valor actualizado a la mesa.
  • 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 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 para agregar a un campo agregado, el valor nuevo se combina con el valor existente. Los agregados te permiten mantener una suma o un contador activo. Para ver más consulta Valores agregados en el momento de la escritura.

Para ilustrar el problema que puede surgir cuando no usas agregaciones, supongamos una tabla que se usa para almacenar los datos de un sistema de tickets. Usas un un contador de números enteros para almacenar la cantidad de entradas vendidas. Cada vez vendes un ticket, tu app envía una solicitud de lectura, modificación y 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 envía solicitudes contradictorias de lectura-modificación-escritura o verificación y mutación a diferentes entre los clústeres de Kubernetes.

¿Qué sigue?