Descripción general de la replicación

La réplica de Bigtable te permite aumentar la disponibilidad y la durabilidad de tus datos copiándolos en varias regiones o en varias zonas de la misma región. También puedes aislar las cargas de trabajo enrutando diferentes tipos de solicitudes a distintos clústeres.

En esta página se explica cómo funciona la replicación en Bigtable y se describen algunos casos prácticos habituales de replicación. También se explica el modelo de coherencia que usa Bigtable cuando la replicación está habilitada y se describe lo que ocurre cuando un clúster falla y se pasa a otro.

Antes de leer esta página, debes familiarizarte con la descripción general de Bigtable.

Cómo funciona la replicación

Para usar la replicación en una instancia de Bigtable, crea una instancia con más de un clúster o añade clústeres a una instancia que ya tengas.

Las instancias de Bigtable pueden tener clústeres ubicados en hasta 8 regiones de Bigtable y, en cada una de esas 8 regiones, la instancia solo puede contener un clúster por zona. Por ejemplo, si creas una instancia en 8 regiones, cada una de las cuales tiene 3 zonas, tu instancia puede tener hasta 24 clústeres.

Cada zona de una región solo puede contener un clúster. Si tienes clústeres en diferentes zonas o regiones, podrás acceder a los datos de tu instancia aunque una de las zonas o regiones no esté disponible. Google Cloud

Cuando creas una instancia con más de un clúster, Bigtable empieza inmediatamente a sincronizar tus datos entre los clústeres, lo que crea una copia independiente de tus datos en cada zona en la que tu instancia tenga un clúster. Del mismo modo, cuando añades un nuevo clúster a una instancia, Bigtable copia los datos del clúster original a la zona del nuevo clúster y, a continuación, sincroniza los cambios de los datos entre las zonas.

Bigtable replica cualquier cambio que se haga en tus datos, incluidos los siguientes tipos de cambios:

  • Actualizaciones de los datos de las tablas
  • Tablas nuevas y eliminadas
  • Familias de columnas añadidas y eliminadas
  • Cambios en la política de recolección de elementos no utilizados de una familia de columnas

La replicación tiene cierta latencia y la coherencia entre clústeres es eventual.

Bigtable trata cada clúster de tu instancia como un clúster principal, por lo que puedes realizar lecturas y escrituras en cada clúster. También puedes configurar tu instancia para que las solicitudes de diferentes tipos de aplicaciones se dirijan a diferentes clústeres.

Antes de añadir clústeres a una instancia, debes tener en cuenta las restricciones que se aplican al cambiar las políticas de recolección de elementos no utilizados de las tablas replicadas.

Rendimiento

El uso de la replicación tiene implicaciones en el rendimiento que debes tener en cuenta al crear una instancia replicada o habilitar la replicación añadiendo un clúster a una instancia de un solo clúster. Por ejemplo, los clústeres replicados en diferentes regiones suelen tener una latencia de replicación mayor que los clústeres replicados en la misma región. Además, los clústeres de las instancias que tienen más de un clúster suelen necesitar más nodos para gestionar el trabajo adicional de la replicación. Para obtener más información, consulta el artículo Interpretar el rendimiento.

Casos prácticos

En esta sección se describen algunos casos prácticos habituales de la replicación de Bigtable. Para encontrar los mejores ajustes de configuración para cada caso práctico, así como consejos de implementación para otros casos prácticos, consulta Ejemplos de ajustes de replicación.

Aísla las aplicaciones de servicio de las lecturas por lotes

Si usas un solo clúster para ejecutar una tarea de analíticas por lotes que realice numerosas lecturas grandes junto con una aplicación que realice una combinación de lecturas y escrituras, la tarea por lotes grande puede ralentizar el trabajo de los usuarios de la aplicación. Con la replicación, puedes usar perfiles de aplicación con enrutamiento de un solo clúster para enrutar trabajos de analíticas por lotes y tráfico de aplicaciones a diferentes clústeres, de modo que los trabajos por lotes no afecten a los usuarios de tus aplicaciones. Consulta más información sobre cómo implementar este caso práctico.

Mejorar la disponibilidad

Si una instancia solo tiene un clúster, la durabilidad y la disponibilidad de tus datos se limitan a la zona en la que se encuentra ese clúster. La replicación puede mejorar tanto la durabilidad como la disponibilidad almacenando copias independientes de tus datos en varias zonas o regiones y conmutando automáticamente entre clústeres si es necesario. Más información sobre cómo implementar este caso práctico

Proporcionar copias de seguridad casi en tiempo real

En algunos casos, por ejemplo, si no puedes permitirte leer datos obsoletos, siempre tendrás que enrutar las solicitudes a un solo clúster. Sin embargo, puedes seguir usando la replicación gestionando las solicitudes con un clúster y manteniendo otro clúster como copia de seguridad casi en tiempo real. Si el clúster de servicio deja de estar disponible, puedes minimizar el tiempo de inactividad haciendo un failover manual al clúster de copia de seguridad. Consulta más información sobre cómo implementar este caso práctico.

Asegurarse de que los datos tengan una presencia global

Puedes configurar la replicación en ubicaciones de todo el mundo para que tus datos estén más cerca de tus clientes. Por ejemplo, puedes crear una instancia con clústeres replicados en EE. UU., Europa y Asia, y configurar perfiles de aplicación para enrutar el tráfico de la aplicación al clúster más cercano. Más información sobre cómo implementar este caso práctico

Modelos de coherencia

En esta sección se explican los modelos de coherencia que Bigtable puede proporcionar para la replicación, en función de la política de enrutamiento que utilices.

Coherencia eventual

De forma predeterminada, la replicación de Bigtable es coherente con el tiempo. Este término significa que, cuando escribes un cambio en un clúster, puedes leerlo en los demás clústeres de la instancia, pero solo después de que se haya replicado entre los clústeres.

Si tu instancia responde, la latencia de la replicación suele ser de unos segundos o minutos, no de horas. Sin embargo, si escribes una gran cantidad de datos en un clúster o si un clúster está sobrecargado o no está disponible temporalmente, la replicación puede tardar en ponerse al día. Además, la replicación puede tardar más tiempo si tus clústeres están lejos unos de otros. Por lo tanto, no es seguro asumir que siempre se lee el último valor que se ha escrito o que, si se espera unos segundos después de una escritura, Bigtable tiene tiempo suficiente para replicar el cambio.

Coherencia inmediata (read-your-writes)

Puedes conseguir una coherencia inmediata (read-your-writes) con el enrutamiento de un solo clúster y una alta tasa de coherencia inmediata (read-your-writes) con el enrutamiento de varios clústeres con enrutamiento de afinidad de filas o cuando los clústeres de tu instancia estén en regiones diferentes.

Enrutamiento de un solo clúster

Si usas el enrutamiento de un solo clúster, Bigtable puede proporcionar coherencia inmediata (read-your-writes) cuando la replicación está habilitada. Este modelo de coherencia asegura que una aplicación nunca lea datos que sean anteriores a sus escrituras más recientes.

Cada perfil de aplicación que uses debe configurarse para el enrutamiento de un solo clúster y todos los perfiles de aplicación deben enrutar las solicitudes al mismo clúster. Puedes usar los clústeres adicionales de la instancia al mismo tiempo para otros fines.

Enrutamiento entre varios clústeres con un clúster por región

Con el enrutamiento de varios clústeres, Bigtable siempre enruta las solicitudes al clúster más cercano. Si cada clúster de tu instancia se encuentra en una región de Bigtable diferente y usas un perfil de aplicación configurado para el enrutamiento multiclúster, tus datos tendrán una coherencia de lectura-escritura en la región de origen, a menos que se produzca una conmutación por error.

Enrutamiento por afinidad de filas

Para conseguir una mayor coherencia de lectura y escritura con el enrutamiento multiclúster a una instancia que tenga más de un clúster en una región, puedes usar un perfil de aplicación configurado para el enrutamiento por afinidad de filas (enrutamiento persistente).

Con el enrutamiento por afinidad de filas, Bigtable enruta automáticamente tus 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. No puedes definir manualmente la asignación entre la clave de fila y el clúster. No se garantiza la coherencia porque las solicitudes pueden seguir fallando por varios motivos, como cuando un clúster no está en buen estado, hay problemas de red o el clúster ha recibido demasiadas solicitudes.

Coherencia inmediata

En algunos casos prácticos de replicación, Bigtable también puede proporcionar coherencia sólida, lo que asegura que todas tus aplicaciones vean los datos en el mismo estado. Para conseguir una coherencia sólida, debes usar la configuración del perfil de aplicación de enrutamiento de un solo clúster para la coherencia de lectura y escritura que se ha descrito anteriormente, pero no debes usar los clústeres adicionales de la instancia a menos que necesites conmutar por error a otro clúster. Consulta los ejemplos de configuraciones de replicación para ver si es posible en tu caso práctico.

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.

Perfiles de aplicación

Si una instancia usa la replicación, puedes usar perfiles de aplicación o perfiles de aplicación para especificar políticas de enrutamiento. Los perfiles de aplicación también determinan si puedes realizar transacciones de una sola fila, que incluyen operaciones de lectura-modificación-escritura (como incrementos y anexiones) y operaciones de comprobación y modificación (también conocidas como mutaciones condicionales o escrituras condicionales).

Para obtener más información, consulta Perfiles de aplicación. Para ver ejemplos de ajustes que puede usar para implementar casos prácticos habituales, consulte Ejemplos de configuraciones de replicación.

Políticas de enrutamiento

Todos los perfiles de aplicación tienen una política de enrutamiento que controla qué clústeres gestionan las solicitudes entrantes de tus aplicaciones. Entre las opciones de las políticas de enrutamiento se incluyen las siguientes:

  • Enrutamiento de un solo clúster: envía todas las solicitudes a un solo clúster que especifiques.
  • Rutas entre clústeres:
    • Cualquier enrutamiento de clústeres: envía las solicitudes al clúster más cercano de la instancia.
    • Enrutamiento de grupos de clústeres: restringe todas las solicitudes a los clústeres que especifiques.
    • Enrutamiento por afinidad de filas: envía una solicitud de lectura o escritura de una sola fila a un clúster específico en función de la clave de fila de la solicitud. Para obtener más información, consulta Enrutamiento de afinidad de filas.

Conmutaciones por error

Si un clúster de Bigtable deja de responder, la replicación permite que el tráfico entrante se redirija a otro clúster de la misma instancia. Las conmutaciones por error pueden ser manuales o automáticas, en función del perfil de aplicación que utilice una aplicación y de cómo esté configurado el perfil de aplicación. Para obtener más información, consulta el artículo sobre conmutaciones por error.

Eliminación de intervalos de filas cuando la replicación está habilitada

La API Admin de Cloud Bigtable te permite eliminar un intervalo contiguo de filas de una tabla en función de sus claves de fila. En las instancias que no usan la replicación, Bigtable puede eliminar un intervalo de filas de forma rápida y eficiente. Sin embargo, cuando la replicación está habilitada, eliminar un intervalo de filas es mucho más lento y menos eficiente.

Siguientes pasos