Con Couchbase Server 3.0, hemos introducido un nuevo protocolo para la sincronización de datos llamado DCP (database change protocol). DCP impulsa muchas instalaciones dentro de Couchbase Server, incluyendo el mantenimiento de réplicas, reequilibrio, recuperación de nodos, copias de seguridad, indexación hasta la replicación XDCR. Esencialmente se encuentra en el corazón de nuestra arquitectura y bombea sangre al resto del cuerpo.

Con la versión anterior del producto, a medida que las mutaciones llegaban a los nodos del clúster de origen, se ponían en cola para la persistencia en disco y la replicación a otros nodos. Una vez que se consigue la persistencia en disco, el replicador XDCR detecta las mutaciones leyendo de nuevo las mutaciones desde el disco y se replican al clúster de destino. La latencia de la replicación XDCR depende de varios factores, pero en Couchbase Server 2.x, uno de los principales factores es la rapidez con la que se pueden persistir las mutaciones en el disco. La IO en disco no es rápida. Ciertamente no es rápido en "memoria".

Con la nueva versión 3.0, con la ayuda de DCP, XDCR detecta mutaciones directamente iniciando un flujo DCP. A medida que las mutaciones llegan DCP ayuda a la replicación intra cluster así como a los replicadores XDCR que recogen la mutación y replican al cluster de destino. ¡El flujo y la memoria son rápidos! Y esa es nuestra magia para conseguir latencias XDCR hasta 4 veces más bajas.

Para aquellos que utilizan XDCR para alta disponibilidad y recuperación de desastres, significa que podemos llevar sus cambios a la seguridad de otro clúster en otro centro de datos más rápido. Esto significa que estará mejor protegido frente a fallos en todo el clúster, como desastres regionales que afecten a todo un centro de datos. Para aquellos que utilizan XDCR para la localización de datos en sus despliegues globales, significa que podemos hacer que los datos estén disponibles en todo el mundo más rápidamente.

Antes de terminar, debo señalar una cosa: los datos de rendimiento son siempre difíciles de comunicar. Es importante señalar que la latencia absoluta con XDCR depende de muchos factores. Los factores de latencia incluyen el ancho de banda de la red, la latencia 'ping' entre clusters, la capacidad computacional disponible para procesar las mutaciones en origen y destino y más... Para obtener los datos más precisos, prueba Couchbase Server 3.0 y ¡háznoslo saber! Descárgalo aquí: couchbase.com/descargar

Autor

Publicado por Cihan Biyikoglu, Director de Gestión de Productos, Couchbase

Cihan Biyikoglu es director de gestión de productos en Couchbase, responsable del producto Couchbase Server. Cihan es un entusiasta de los grandes datos que aporta más de veinte años de experiencia al equipo de productos de Redis Labs. Cihan comenzó su carrera como desarrollador de C/C++.

Dejar una respuesta