Diseño de un entorno de Elasticsearch con un grupo de nodos dual
Puede crear un conjunto dual de grupos de nodos de Elasticsearch para mejorar el rendimiento. A continuación propocionamos una configuración de ejemplo donde se utiliza un conjunto dedicado de nodos y recursos para las operaciones de Ingest, ademñas de otro dedicado al tráfico de las búsquedas y navegaciones de los compradores.
La actualización incremental es el método recomendado para utilizar Elasticsearch en . Si el delta es lo suficientemente pequeño, la cantidad de invalidación en una actualización incremental será relativamente pequeña en comparación a una invalidación y reindexación completa. Si los entornos de creación (Auth) y Live comparten el mismo grupo de nodos predeterminado de Elasticsearch, los cambios más grandes del entorno de Auth pueden afectar temporalmente a la navegación y a las búsquedas de los clientes en el entorno de Live. En este escenario, podría separar los entornos de Auth y Live de forma que las actualizaciones incrementales del lado de Auth no afecten a las búsquedas de los clientes en el entorno Live. A continuación proporcionamos una configuración de ejemplo.
Configuración predeterminada de un solo grupo de nodos
En el entorno de Elasticsearch predeterminado, la indexación procede de la siguiente manera.
- Un usuario de empresa que trabaja en el entorno de autoría actualiza el catálogo en Centro de gestión.
- La actualización desencadena una solicitud de invalidación que se envía a CACHEIVL.
- Estos datos también se propagan a lo largo del bus de Redis al servicio Ingest, que utiliza los conductos de Apache NiFi para analizar los datos y actualizar el índice Elastsearch.
- El usuario puede llamar al servicio de consulta para ver estas actualizaciones en el entorno de autoría de una forma eficaz en tiempo real. Para obtener más información, consulte la .API REST de consulta.
- Estos cambios de negocio incrementales de Centro de gestión se representan como sucesos Redis y se vuelven a enviar al servicio Ingest. Aquí se pueden analizar y procesar más.
- Una vez que se ha actualizado el índice, todos los sucesos de invalidación de memoria caché relacionados se envían al bus Redis, donde se pueden replicar en los centros de datos.
Cuando se inicia la propagación de transición, el servidor de transacciones de autoría replica todos los cambios listos para producción de la base de datos de autoría en la base de datos en tiempo real. También emite una solicitud de propagación transición al servicio de introducción para desencadenar una réplica de las actualizaciones aprobadas del índice de creación al índice activo.
Las caches REST y de objeto de datos utilizadas en el servicio de consulta de instancia en vivo también se invalidan. Si procede, las caché JSP utilizadas por el servidor de tienda en la instancia en vivo también se invalidarán.
Se crea una copia del nuevo índice activo en el entorno real y se intercambia en una vez que el nuevo índice está listo. La versión antigua se ha descargado de forma inmediata.
Una configuración del nodo dual
En este ejemplo de un grupo de nodos dual, se definen dos grupos de nodos de Elasticsearch a través de Kubernetes. El elastic-auth-pool contiene un nodo (un maestro y un VCPU de Auth), y elastic-pool-live contiene dos (dos maestros y dos VCPU de Auth). Este total es de tres POD maestros de Elasticsearch, un POD de Auth y dos POD de Live.
- Le permite gestionar por separado el tráfico interno y externo.
- Puede coordinar la invalidación entre los nodos de forma más eficaz.
- Puede asignar distintas funcionalidades informáticas y de red a los entornos Auth y Live.