Las aplicaciones modernas se implementan como un conjunto de un gran número de microservicios. Cada uno de estos microservicios puede ejecutarse independientemente de muchos otros microservicios. Tales aplicaciones esperan que las bases de datos subyacentes soporten multi-tenancy. Couchbase Server 7.0 ha introducido Ámbitos y colecciones para soportar la multitenencia y facilitar el modelado de datos para las aplicaciones actuales. Los ámbitos y las colecciones proporcionan a los usuarios una separación lógica de los datos dentro de un cubo.
Cada microservicio de una aplicación puede ahora crear independientemente Índices Secundarios Globales necesarios para ese microservicio. En versiones anteriores de Couchbase Server sólo se permitía una solicitud de creación de índice en el clúster. Para reforzar el soporte para multi-tenancy, en Couchbase Server 7.0, el flujo de trabajo de creación de índices ha sido mejorado para permitir múltiples peticiones de creación de índices concurrentes. En este blog, vamos a discutir cómo se ha mejorado la experiencia del usuario al crear varios índices simultáneamente.
Flujo de trabajo de creación de índices mejorado
Entendamos primero el flujo de trabajo de creación de índices en un cluster Couchbase. Creación de índices ocurre en dos fases (1) Creación de metadatos del índice y (2) Construcción del índice. En la primera fase, el servicio de índices de Couchbase determina la mejor ubicación posible para el nuevo índice, con la ayuda de planificador de índicesy se conservan los metadatos del índice. En la segunda fase, los nodos anfitriones determinados en la primera fase iniciarán un flujo con el servicio de datos para la "construcción del índice". Los usuarios pueden especificar el aplazar_construcción durante la creación del índice para que sólo se ejecute la primera fase y la segunda pueda activarse posteriormente mediante la opción construir índice mando.
En las secciones siguientes, el significado de creación de índices se limita sólo a la primera fase.
Para conseguir la mejor colocación de índices posible, sólo debe ejecutarse una instancia del planificador de índices a la vez. Por lo tanto, el servicio de índice - que ejecuta versiones anteriores del servidor Couchbase - rechaza cualquier nueva solicitud de creación de índice entrante si hay una solicitud de creación de índice en curso. 
Este comportamiento ha sido mejorado en Couchbase Server 7.0, donde el servicio de índice acepta todas las peticiones entrantes de creación de índice, incluso si hay una creación de índice en curso. El servicio de índices pone en cola las solicitudes de creación de índices, procesa las solicitudes en cola en segundo plano y sólo después de crear el índice devuelve la respuesta a la persona que lo solicita.
Tenga en cuenta que la creación de índices era una solicitud de bloqueo antes de Couchbase Server 7.0 y sigue siendo de bloqueo en las nuevas versiones también.
Los usuarios pueden supervisar los índices que están en cola para su creación en segundo plano a través de la interfaz web, como se muestra en la siguiente captura de pantalla. Tenga en cuenta que el índice estado es creación programada.
Los usuarios también pueden supervisar el estado del índice mediante programación utilizando N1QL, como se muestra en la siguiente captura de pantalla.
Experiencia de usuario mejorada
En las versiones anteriores, los usuarios tenían que reintentar la creación del índice cuando había otro índice en curso de creación. Si la creación del índice se realiza mediante programación, el programa necesita un mecanismo de reintento. Con Couchbase server 7.0, el programa de usuario no necesita confiar en el mecanismo de reintento mientras se crea un índice, ya que el servicio de índices realizará los reintentos necesarios en segundo plano. Nótese que el servicio de índices no sólo realiza "simples reintentos". Internamente prioriza las peticiones basándose en la marca de tiempo de la petición para que la convergencia de las peticiones de creación de índices sea más rápida y mucho más fiable.
El servicio de índices serializa las creaciones de índices en el clúster con la ayuda de un mecanismo de bloqueo distribuido globalmente. Así, para la creación de un índice, todos los nodos del servicio de índices necesitan alcanzar un consenso antes de permitir la creación del índice.
Veamos ahora el siguiente escenario/ejemplo para comprender cómo se mejora la convergencia con la participación del servicio de índices.
Supongamos que dos aplicaciones de usuario (o microservicios) intentan crear índices de forma concurrente. Las dos aplicaciones pueden conectarse a dos nodos de servicio de consulta diferentes para la creación de índices. El nodo de servicio de consulta ejecuta un cliente de servicio de índice que es responsable de adquirir el bloqueo distribuido globalmente y determinar la colocación del índice ejecutando el planificador de índices.
Cronología de la creación de índices en la versión pre-7.0 de Couchbase
Consideremos una posible línea de tiempo de los eventos que ocurren en el cluster (con Couchbase Server versión < 7.0) como se muestra en el diagrama de abajo.
Calendario:
T0: Ambas aplicaciones lanzan peticiones de creación de índices simultáneamente y las peticiones son recibidas por los clientes del servicio de índices.
T1: El cliente de servicio de índice 1 envía el Cerradura al nodo índice 1. Nodo índice 1 acepta la solicitud.
T2: El cliente de servicio de índice 2 envía el Cerradura al nodo índice 2. Nodo índice 2 acepta la solicitud.
T3: El cliente de servicio de índice 1 envía el Cerradura al nodo índice 2. Nodo índice 2 rechaza la solicitud puesto que ya ha aceptado la solicitud del cliente 2.
T4: El cliente de servicio de índice 2 envía el Cerradura al nodo índice 1. Nodo índice 1 rechaza la solicitud puesto que ya ha aceptado la solicitud del cliente 1.
Nótese que en este ejemplo, en Couchbase Server versión < 7.0, ambas peticiones serán rechazadas por Couchbase y los scripts de usuario necesitarán reintentarlo. Si los scripts de usuario reintentan inmediatamente o después de un periodo de tiempo determinado, el siguiente intento puede llevar a un escenario/tiempo similar y ambas peticiones pueden ser rechazadas en el siguiente intento.
Cola de creación de índices con Couchbase 7.0
Con Couchbase Server 7.0 el comportamiento mejorado, y una línea de tiempo similar a nuestro ejemplo, se muestra en el diagrama de abajo. Observa que la responsabilidad de crear un índice es asumida por los creadores de índices en segundo plano, mientras que el hilo de la aplicación de usuario sigue esperando a que termine la creación del índice. El hilo de usuario obtendrá una respuesta sólo cuando se haya creado el índice.
Calendario:
T0: Dos hilos creadores de índices en segundo plano activan la creación de índices simultáneamente y las solicitudes son recibidas por los clientes del servicio de índices.
T1: El cliente de servicio de índice 1 envía el Cerradura (con prioridad P1) al nodo de índice 1. Nodo índice 1 acepta la solicitud.
T2: El cliente de servicio de índice 2 envía el Cerradura (con prioridad P2) al nodo de índice 2. Nodo índice 2 acepta la solicitud.
T3: El cliente de servicio de índice 1 envía el Cerradura (con prioridad P1) al nodo de índice 2. Nodo índice 2 acepta la solicitud, ya que tiene mayor prioridad que la solicitud aceptada anteriormente.
T4: El cliente de servicio de índice 2 envía el Cerradura (con prioridad P2) al nodo de índice 1. Nodo índice 1 rechaza la solicitud porque ya ha aceptado la solicitud con mayor prioridad del cliente 2.
Tenga en cuenta que el mecanismo de bloqueo distribuido utiliza un protocolo de confirmación en dos fases de modo que la solicitud previamente aceptada (con prioridad P2) en el nodo de índice 2 fallará durante la fase de confirmación y será reintentada por el creador del índice en segundo plano.
También hay que tener en cuenta que las prioridades de las peticiones se basan en marcas de tiempo generadas con una granularidad de nanosegundos. Esto elimina la mayor parte de la contención de bloqueos distribuidos. Sin embargo, existe la posibilidad de que dos solicitudes tengan exactamente la misma marca de tiempo. Para manejar este caso, el servicio de índice utiliza un backoff aleatorio para reducir aún más la contención de bloqueo distribuido.
