Descripción general de la replicación

La replicación de Bigtable te permite aumentar la disponibilidad y la durabilidad de tus datos al copiarlos en varias regiones o en varias zonas dentro de la misma región. Además, puedes aislar las cargas de trabajo, porque tienes la posibilidad de enrutar distintos tipos de solicitudes a clústeres diferentes.

En esta página, se explica cómo funciona la replicación en Bigtable y se describen algunos casos prácticos comunes de replicación. También se explica el modelo de coherencia que Bigtable usa cuando se habilita la replicación y se describe qué ocurre cuando un clúster se conmuta por error a otro clúster.

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

Usa la replicación

Para usar la replicación en una instancia de Bigtable, crea una instancia nueva con más de un clúster o agrega clústeres a una instancia existente.

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 puede contener solo un clúster por zona. Por ejemplo, si creas una instancia en 8 regiones que tienen 3 zonas cada una, la instancia puede tener hasta 24 clústeres.

Cada zona de una región puede contener solo un clúster. Tener clústeres en diferentes zonas o regiones te permite acceder a los datos de tu instancia, incluso si una zona o región de Google Cloud deja de estar disponible.

Cuando creas una instancia con más de un clúster, Bigtable comienza de inmediato a sincronizar tus datos entre las zonas en las que se encuentran y crea una copia independiente y separada de los datos en cada zona en la que la instancia tiene un clúster. Del mismo modo, cuando agregas un clúster nuevo a una instancia existente, Cloud Bigtable copia tus datos existentes desde la zona del primer clúster hasta la zona del clúster nuevo y, a continuación, sincroniza los cambios en tus datos entre las zonas.

Bigtable replica automáticamente los cambios que se realizan en tus datos, incluidos todos los tipos de cambios siguientes:

  • Actualizaciones de los datos en las tablas existentes
  • Tablas nuevas y borradas
  • Familias de columnas que se agregaron y quitaron
  • 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 los clústeres es eventual.

Bigtable considera todos los clústeres de tu instancia como el principal, por lo que puedes realizar lecturas y escrituras en cada uno de ellos. También puedes configurar la instancia para que las solicitudes de los distintos tipos de aplicaciones se enruten a clústeres diferentes.

Antes de agregar clústeres a una instancia, debes tener en cuenta las restricciones que se aplican cuando cambias las políticas de recolección de elementos no utilizados para tablas replicadas.

Rendimiento

El uso de la replicación tiene implicaciones de rendimiento que debes planificar cuando creas una instancia replicada o habilitas la replicación mediante la adición de un clúster a una instancia de un solo clúster. Por ejemplo, los clústeres replicados en regiones diferentes generalmente tienen una latencia de replicación más alta que los clústeres replicados en la misma región. Además, los clústeres en las instancias que tienen más de un clúster a menudo necesitan más nodos para manejar el trabajo adicional de manejar la replicación. Para obtener más información, consulta Información sobre el rendimiento.

Casos de uso

En esta sección, se describen algunos casos prácticos comunes de la replicación de Bigtable. Si quieres descubrir cuál es la mejor configuración para cada caso práctico y obtener sugerencias de implementación, consulta Ejemplos de configuración de la replicación.

Aísla las aplicaciones en uso de las lecturas por lotes

Cuando usas un solo clúster para ejecutar un gran trabajo de estadísticas por lotes que realiza varias lecturas grandes, junto con una aplicación que lleva a cabo una mezcla de lecturas y escrituras, ese gran trabajo por lotes puede ralentizar los procesos para los usuarios de la aplicación. Con la replicación, puedes usar los perfiles de aplicaciones con enrutamiento de un solo clúster para enrutar los trabajos de estadísticas por lotes y el tráfico de aplicaciones a diferentes clústeres, de modo que los trabajos por lotes no afecten a los usuarios de tus aplicaciones. Obtén más información sobre cómo implementar este caso práctico.

Mejora la disponibilidad

Si una instancia tiene solo un clúster, la durabilidad y la disponibilidad de tus datos estará limitada según la zona en la que se encuentre el clúster. La replicación puede mejorar la durabilidad y la disponibilidad, ya que almacena copias independientes de todos tus datos en varias zonas o regiones, y realiza la conmutación por error automáticamente entre los clústeres si es necesario. Obtén más información sobre cómo implementar este caso de uso.

Proporciona copias de seguridad casi en tiempo real

Por ejemplo, en algunos casos, si no te puedes permitir leer datos inactivos, siempre deberás enrutar las solicitudes a un solo clúster. Sin embargo, aún puedes usar la replicación mediante el control de las solicitudes con un clúster y el uso del otro como una copia de seguridad casi en tiempo real. Si el primer clúster deja de estar disponible, puedes reducir el tiempo de inactividad con una conmutación por error manual al clúster de respaldo. Obtén más información sobre cómo implementar este caso práctico.

Asegúrate de que tus datos tengan una presencia global

Puedes configurar la replicación en ubicaciones de todo el mundo para acercar tus datos a 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 aplicaciones al clúster más cercano. Obtén más información sobre cómo implementar este caso práctico.

Modelo de coherencia

De forma predeterminada, la replicación para Bigtable tiene coherencia eventual. Esto significa que cuando escribes un cambio en un clúster, a la larga, podrás leerlo en otros clústeres de la instancia, pero solo después de que el cambio se replique 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 este se encuentra sobrecargado o no disponible por el momento, es posible que la replicación lleve un poco más de tiempo. Además, la replicación puede llevar más tiempo si los clústeres están muy separados. En consecuencia, no siempre es seguro suponer que estás leyendo el último valor escrito o que, con esperar unos segundos después de cada escritura, le das a Bigtable el tiempo suficiente para replicar el cambio.

Si necesitas otra garantía de coherencia, Bigtable también proporciona coherencia en la lectura de tus escrituras cuando se habilita la replicación, lo que garantiza que una aplicación nunca lea datos más antiguos que sus escrituras más recientes. A fin de obtener coherencia en la lectura de tus escrituras para un grupo de aplicaciones, cada aplicación del grupo debe usar un perfil de app configurado en el enrutamiento en un solo clúster, y todos los perfiles de app deben enrutar las solicitudes al mismo clúster. Puedes usar los clústeres adicionales de la instancia al mismo tiempo para otros fines.

Para algunos casos prácticos de replicación, Bigtable también puede proporcionar coherencia sólida, lo que garantiza que todas las aplicaciones vean los datos en el mismo estado. Para obtener una coherencia sólida, puedes usar la configuración del perfil de app de enrutamiento de un solo clúster para la coherencia en la lectura de tus escrituras antes descrita, pero no debes usar los clústeres adicionales de la instancia, a menos que necesites realizar una conmutación por error a un clúster diferente. Revisa los ejemplos de configuración de replicación para ver si esto es posible en tu caso práctico.

Resolución de conflictos

Cada valor de celda en una tabla de Bigtable se identifica de forma única con la tupla de cuatro elementos (clave de fila, familia de columnas, calificador de columna, marca de tiempo). Consulta Modelo de almacenamiento de Bigtable para obtener más detalles sobre estos identificadores. En el caso poco frecuente de que dos operaciones de escritura con la misma tupla de cuatro elementos se envíen a dos clústeres diferentes, Bigtable resolverá automáticamente el conflicto con un algoritmo interno de gana la última escritura según el tiempo del servidor. La implementación de Bigtable "gana la última escritura" es determinista y, cuando la replicación se actualiza, 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, debes usar perfiles de aplicación, o perfiles de app, para especificar las políticas de enrutamiento. Los perfiles de app también determinan si puedes realizar transacciones de una sola fila, como las operaciones de lectura-modificación-escritura (incluidos los incrementos y anexos) y las operaciones verificar y mutar (también conocidas como escrituras o mutaciones condicionales).

Si deseas obtener más detalles, consulta Perfiles de aplicación. Si quieres obtener ejemplos de la configuración que puedes usar para implementar casos de uso comunes, consulta Ejemplos de configuraciones de replicación.

Políticas de enrutamiento

Cada perfil de app tiene una política de enrutamiento que controla qué clústeres se encargan de las solicitudes entrantes de tus aplicaciones. Las opciones para las políticas de enrutamiento incluyen las siguientes:

  • Enrutamiento de un solo clúster: Envía todas las solicitudes a un clúster que especificas.
  • Enrutamiento de varios clústeres a cualquier clúster: Envía solicitudes al clúster disponible más cercano en la instancia.
  • Enrutamiento de grupo de clústeres: Envía solicitudes al clúster disponible más cercano de un grupo de clústeres que especificas en la configuración del perfil de app.

Conmutaciones por error

Si un clúster de Bigtable deja de responder, la replicación permite que el tráfico entrante realice una conmutación por error a otro clúster en la misma instancia. Las conmutaciones por error pueden ser manuales o automáticas, según el perfil de aplicación que use una aplicación y su configuración.

Si deseas obtener detalles, consulta Conmutaciones por error.

Quita rangos de filas cuando la replicación está habilitada

La API de Administrador de Cloud Bigtable te permite quitar un rango continuo de filas de una tabla según sus claves de fila. En instancias que no usan la replicación, Bigtable puede quitar un rango de filas con rapidez y eficiencia. Sin embargo, esta tarea se vuelve considerablemente más lenta cuando la replicación está habilitada.

¿Qué sigue?