Desde principios de este año, nosotros (Couchbase Indexing Team) emprendimos un proyecto para mejorar servicio de indexación en Capella. Este blog discute los objetivos que planeamos alcanzar al inicio de este proyecto y la lista de mejoras entregadas para lograr ese objetivo. Ten en cuenta que la mayoría de estas mejoras, aunque dirigidas a Capella (la base de datos en la nube de Couchbase), también son válidas para clústeres autogestionados de Couchbase Server.
Objetivos
-
- Operaciones de escalado más rápidas: En el caso de las bases de datos en la nube, el escalado puede ser una actividad muy frecuente, por lo que debe ser rápido.
- Mejorar la compatibilidad con hardware de gama baja: Los usuarios pueden empezar con un hardware de gama baja y, más adelante, aprovisionarse de hardware de gama más alta, a medida que aumente la demanda de la aplicación.
- Mejora de la compatibilidad con la entrada/salida lenta de disco: Los despliegues en la nube utilizan almacenamiento tipo EBS, que probablemente sea más lento que las unidades SSD conectadas directamente. Por tanto, el coste de una sola operación de E/S se multiplica en un entorno de nube.
El objetivo final era mejorar la experiencia general del usuario.
En las secciones siguientes se explican los índice de mejoras del servicio realizadas en la versión 7.2.2 de Couchbase Server, y cómo estas mejoras logran los objetivos mencionados.
Operaciones de escalado más rápidas
La carga de trabajo de la aplicación del usuario puede aumentar/disminuir con frecuencia. Cuando los usuarios esperan que la carga de trabajo de la aplicación aumente, pueden "añadir más nodos (es decir, ampliar)" o "aumentar la CPU/memoria de los nodos (es decir, ampliar)", o hacer ambas cosas.
Para reducir, Capella añade más nodos de servicio de índice (con la misma configuración que la de los nodos existentes) al clúster. A continuación Reequilibrio del servidor Couchbasedonde los índices pueden moverse de su nodo anfitrión actual a cualquier otro nodo del cluster. Este movimiento se realiza para lograr una distribución equilibrada de la carga entre todos los nodos indexadores.
Para ampliar, Operación de escalado Capella activa internamente una secuencia del servidor couchbase reequilibrio swap operaciones. Cada reequilibrio de intercambio añade un nuevo nodo (que tiene la configuración actualizada) y elimina un nodo antiguo (que tiene la configuración antigua). Una vez que todos los nodos antiguos han sido sustituidos por nodos nuevos, la operación de escalado finaliza. Durante el reequilibrio de intercambio, el servicio de índices debe mover los índices del nodo antiguo al nuevo, para que no se pierdan los índices.
El servicio de índices realiza el movimiento del índice mediante (1) la reconstrucción del índice utilizando Protocolo de cambio de datos (DCP) en el nodo de destino y, a continuación, (2) eliminar el índice del nodo de origen. Dado que la reconstrucción de los índices en el nodo de destino puede consumir mucha CPU, el servicio de índices mueve los índices en lotes. Cada lote requerirá la lectura del flujo de datos desde el servicio de datos, y los índices se construirán en los nodos del servicio de índices. Una vez que un lote de índices se traslada al nodo de destino, ese lote de índices puede servir a Consultas N1QL (exploraciones de índice) del nodo de destino.
Ejemplo de ampliación
Los siguientes diagramas muestran un ejemplo del flujo de trabajo "Scale Out" en dos pasos utilizando el reequilibrio basado en DCP. Aquí, el servicio de índices ha decidido mover los índices 3, 6 y 9 al nuevo nodo. Del mismo modo, el índice 5 se moverá del nodo 1 al nodo 2. Así, en el primer paso, los índices 3, 6 y 9 serán reconstruidos en el nuevo nodo de índices con la ayuda de DCP. Del mismo modo, el índice 5 se reconstruirá en el nodo 2.
A continuación, en el segundo paso, se activarán los índices 3, 6 y 9 en el nuevo nodo, mientras que sus copias antiguas se eliminarán de su host anterior. Del mismo modo, se activará el índice 5 en el nodo 2 y se eliminará su copia antigua del nodo 1.
Ejemplo de ampliación
Los siguientes diagramas muestran el proceso de reequilibrio de intercambio basado en DCP, que se utiliza para realizar operaciones de ampliación en los nodos. En el primer paso, se añade un nuevo nodo de índices al clúster. El servicio de índices ha decidido mover los índices 3 y 4 al nuevo nodo de índices, mientras que el índice 5 se moverá al nodo de índices 1. Así, en el primer paso, los índices 3 y 4 se reconstruirán en el nuevo nodo de índices, mientras que el índice 5 se reconstruirá en el nodo de índices 1.
En el segundo paso, cuando finalice la creación de los índices 3, 4 y 5, los índices se activarán en sus nodos de destino correspondientes y el nodo de índice 2 se eliminará del clúster.
En Couchbase Server 7.2.2, la operación de escalado es más rápida:
-
- Aumentar el número de índices que se mueven en un lote
Por defecto, el número de índices que se reconstruyen en el nodo destino está limitado a un número pequeño. La razón para elegir un número pequeño es evitar la contención de recursos (CPU) entre la reconstrucción de índices y los escaneos de índices. Para resolver este problema de contención de recursos, en Couchbase Server 7.2.2, evitamos reenviar escaneos de índices al nuevo nodo, hasta que todos los índices en ese nodo estén reconstruidos. Con esto, toda la CPU puede ser usada para la reconstrucción de índices, lo que permite mover más índices en un solo lote. Tenga en cuenta que el lote más grande sólo se utiliza cuando el lote de índices se traslada a un nodo "vacío" del clúster. Para los nodos no vacíos (es decir, nodos que alojan algunos índices), será necesario que sirvan escaneos de índices y que compartan la CPU. Por este motivo, el tamaño de lote mayor sólo se utiliza cuando los índices se mueven a un nodo vacío. A continuación se indican los tamaños de lote por defecto:
- Aumentar el número de índices que se mueven en un lote
Lote de nodos no vacío Tamaño: 3
Lote vacío Tamaño: 20
Nota: el aumento del tamaño del lote permite reducir la carga del servicio de datos, ya que también se reduce el número de veces que se leen elementos de datos del servicio de datos.
-
- Evitar el movimiento de índices entre nodos existentes
En caso de scale out, el servicio de índices puede mover los índices entre los nodos existentes en el cluster. Del mismo modo, en caso de reequilibrio de intercambio, el servicio de índices puede mover los índices del nodo antiguo a otros nodos existentes también. Estos movimientos de índices se realizan principalmente para lograr una distribución equilibrada de la carga en el clúster. Pero conceptualmente, estos movimientos de índices adicionales se suman a la sobrecarga de escalado.
- Evitar el movimiento de índices entre nodos existentes
En Couchbase Server 7.2.2, el movimiento de los índices está restringido a los movimientos que son necesarios para asegurar la funcionalidad. Se evitan los movimientos innecesarios.
En los ejemplos anteriores, en caso de reducción de escala, se evitará el movimiento del índice 5 del nodo 1 al nodo 2. Del mismo modo, en caso de aumento de escala, el índice 5 se moverá al nodo recién añadido en lugar de al nodo 1. Del mismo modo, en caso de ampliación, el índice 5 se moverá al nuevo nodo añadido en lugar de al nodo 1.
Tenga en cuenta que, para lograr una distribución equilibrada de la carga, se puede activar explícitamente una operación de reequilibrio una vez finalizada la operación de escalado.
Resultados experimentales
El experimento realiza un escalado para el servicio de índices, es decir, un escalado de 3 nodos de servicio de índices a 4 nodos de servicio de índices. Hay 100 índices repartidos entre los 3 nodos de servicio de índices. Como parte del escalado, estos 100 índices se redistribuirán en 4 nodos. Además, durante la operación de reequilibrio, se está ejecutando la carga de trabajo de actualización de datos front-end, así como la carga de trabajo de escaneo. Así, con este experimento pudimos comprobar que se reducía el impacto de una operación de reequilibrio en curso sobre las consultas entrantes.
Tabla de resultados:
| Versión de Couchbase Server | 7.2.0 | 7.2.2 |
|---|---|---|
| Tiempo de ampliación (de 3 a 4 nodos índice) | 20,7 min | 6,8 min |
| Consumo de CPU del servicio de datos durante la operación de escalado | 400% | 270% |
Aparte de los resultados anteriores, en nuestras pruebas internas también hemos observado Mejora de 8 y 15 veces las latencias de consulta en los percentiles 95 y 99. respectivamente.
Nota: Esta función está activada por defecto en los clusters Capella provisionados. Para los clústeres autogestionados, utilice la siguiente configuración para habilitarla.
El siguiente comando REST puede utilizarse para activar la dosificación de nodos vacíos:
curl -X POST -u http://:9102/settings --data '{"indexer.rebalance.enableEmptyNodeBatching" : true}'
Este comando REST se puede utilizar para cambiar el tamaño del lote de nodos vacíos a 25:
curl -X POST -u http://:9102/settings --data '{"indexer.rebalance.emptyNodeBuildBatchSize" : 25}'
¿Y ahora qué?
En la siguiente parte de este blog, discutiremos más mejoras del servicio de índices en Couchbase Server 7.2.2.
Más información sobre los productos Couchbase:
-
- Descargar Couchbase Server
- Iniciar una prueba gratuita de Couchbase Capella (DBaas)
- Acceso a Couchbase documentación para desarrolladores
- Véase quién más utiliza Couchbase
"El servicio de índices realiza el movimiento del índice mediante (1) la reconstrucción del índice utilizando el protocolo de cambio de datos (DCP) en el nodo de destino y, a continuación, (2) la eliminación del índice del nodo de origen."
¿No sería más sencillo (y mucho más eficiente) copiar simplemente los archivos de índice físicos del nodo 1 al nodo 2? De todas formas, los GSI son pares (Secondary Key, PK), por lo que la copia física sería válida. ¿Qué me estoy perdiendo?
Echa un vistazo a la última novedad que hace exactamente eso para reducir los gastos generales: https://www.couchbase.com/blog/file-transfer-index-rebalance/ - desde Couchbase Server 7.6.