El núcleo de ElasticSearch: características distribuidas
ES admite el modo de clúster y es un sistema distribuido. Tiene dos beneficios principales:
Un clúster de ES está compuesto por varias instancias de ES. Los diferentes clústeres se distinguen por los nombres de los clústeres, que se pueden modificar a través de cluster.name. El valor predeterminado es elasticsearch. Cada instancia de ES es esencialmente un proceso JVM y tiene su propio nombre, que se puede modificar a través de node.name
Los datos relacionados con el clúster ES se denominan estado del clúster y registra principalmente la siguiente información: información del nodo , como el nombre del nodo, la dirección de conexión, etc.; información del índice, como el nombre del índice, la configuración, etc.
El nodo que puede modificar el estado del clúster se denomina nodo maestro. un estado del clúster almacenado en cada nodo, y el maestro mantiene La última versión se sincroniza con otros nodos
El nodo maestro es elegido por todos los nodos del clúster. El nodo que se puede elegir se llama maestro. nodo elegible. La configuración relevante es la siguiente: node.master: true
El nodo que maneja la solicitud es el nodo coordinador. Este nodo es la función predeterminada de todos los nodos y no se puede cancelar. Enrute la solicitud al nodo correcto para su procesamiento, como una solicitud para crear un índice al nodo maestro
El nodo que almacena datos es el nodo de datos. Los nodos predeterminados son todos los tipos de datos. es el siguiente: node.data: true
p>Antes de hablar sobre los dos conceptos de copia y fragmentación, primero hablemos sobre el significado de estos dos conceptos: resolver la disponibilidad del sistema y aumentar la capacidad del sistema
Imaginemos un escenario de este tipo. Los datos solo se almacenan en un servidor ES. Una vez que este ES se cae o se ve afectado por otros factores incontrolables, además de perder la disponibilidad del servicio, también puede existir la posibilidad de que el servicio se pierda. pérdida de datos. Al mismo tiempo, la capacidad de almacenamiento del servicio independiente no puede hacer frente a los requisitos de gran volumen de datos del proyecto.
La disponibilidad del sistema se puede dividir en disponibilidad de servicio y disponibilidad de datos
Disponibilidad del servicio significa: después de que el servicio actual cuelga, otros servidores reemplazarán el nodo actual para brindar soporte de servicio.
Disponibilidad de datos significa: después de que el servicio actual cuelga, si los datos almacenados en el servidor actual aún pueden proporcionar servicios de modificación y acceso externo.
Una copia puede entenderse como una copia de determinados datos, y el contenido de la copia es coherente con los datos de origen. La existencia de una copia puede cumplir efectivamente con los requisitos de disponibilidad del sistema. Por ejemplo, podemos copiar un nodo que sea exactamente igual al nodo de origen según el nodo original, de modo que una vez que el nodo original muera, otro nodo aún pueda reemplazarlo. El nodo de origen proporciona servicios y el nodo copiado tiene los mismos datos que el nodo de origen, lo que también garantiza la disponibilidad de los datos.
Mencionamos en la sección anterior que las réplicas se pueden usar para resolver problemas de disponibilidad del sistema, pero aquí hay un problema, no importa cuántas réplicas (nodos) existan, el espacio de almacenamiento del nodo de origen no puede ser. aumentó. Con respecto a este problema, ES introdujo el concepto de Shard para resolver el problema.
Después de leer las características de la fragmentación, es posible que algunas personas no sepan exactamente qué es la fragmentación. De hecho, la fragmentación son datos del nodo de origen n/1. Por ejemplo, solo hay un nodo maestro en el clúster ES original y todos los datos del índice se almacenan en este nodo. Ahora dividimos ciertos datos de índice en 3 partes y los almacenamos en 3 nodos ES respectivamente. Luego, cada servidor ES tiene un fragmento. La colección de todos los fragmentos de nodos del índice son los datos completos del índice.
Vamos a demostrarlo a continuación:
Para comprender mejor el mecanismo de fragmentación de ES, es posible que desee pensar más en dos preguntas en el caso anterior:
La respuesta es no. La razón es que la cantidad de fragmentos definidos cuando creamos el índice es solo 3 y todos cayeron en 3 nodos. Por lo tanto, incluso si se agrega un nodo más, no habrá ningún fragmento de fragmento correspondiente que pueda caer en el nuevo nodo y la capacidad de datos de test_shard_index no se podrá expandir.
La respuesta es no. Debido a que las copias recién agregadas también se distribuyen en estos tres nodos, todavía usan los mismos recursos. Si desea aumentar el rendimiento, debe agregar nuevos nodos.
A través de las dos preguntas anteriores, creo que todos se han dado cuenta de la importancia de la fragmentación. Si la cantidad de fragmentos es demasiado pequeña, será imposible lograr la expansión horizontal agregando nodos; copia) los fragmentos son demasiado grandes, el problema será Esto da como resultado que se distribuyan demasiados fragmentos en un nodo, lo que resulta en un desperdicio de recursos y afecta el rendimiento de la consulta
El estado de salud del clúster incluye los siguientes tres tipos: verde estado de salud, lo que significa que todos los fragmentos primarios y secundarios se asignan normalmente; el amarillo significa que todos los fragmentos primarios y secundarios se asignan normalmente, pero algunos fragmentos de réplica no se asignan normalmente; el rojo indica que hay fragmentos primarios; que no están asignados
Podemos ver la información de estado del clúster a través de esta API: GET _cluster/health
También podemos obtener directamente el estado del clúster actual a través de cerebro o head complemento
Cabe señalar que incluso si el estado del clúster actual es rojo, no significa que el ES actual haya perdido la capacidad del servicio. Simplemente significa que los índices a los que no se les asignan fragmentos primarios no se pueden almacenar ni operar normalmente.
Lo que aquí significa conmutación por error es que cuando uno o más nodos en el clúster de ES están inactivos, ES implementa una estrategia de respuesta para la disponibilidad del servicio.
Aquí creamos un nuevo índice con un fragmento de 3 y una réplica de 1. Los fragmentos se distribuyen en tres nodos. En este momento, el clúster está en verde
Cuando la máquina. donde se encuentra el nodo maestro se cae Si el servicio finaliza, ¿qué pasará con el clúster en este momento?
Podemos ver desde la falla del nodo maestro del nodo1 hasta la recuperación de la disponibilidad del clúster. Por ES, ES tiene su propio mecanismo de conmutación por error para garantizar la alta disponibilidad del clúster. También podemos realizar experimentos localmente. Después de crear el índice, elimine el nodo maestro y observe el estado del clúster.
Al mismo tiempo, incluso si el nodo2 está inactivo en este momento, el nodo3 puede reanudar rápidamente sus capacidades de prestación de servicios.
Sabemos que el documento que creamos eventualmente se almacenará en fragmentos, por lo que, según el clúster distribuido, ¿cómo determina el clúster ES en qué fragmento debería recaer finalmente el documento actual?
Obviamente, necesitamos un algoritmo de mapeo que pueda distribuir documentos de manera uniforme a cada fragmento. Entonces, ¿pueden el algoritmo aleatorio común y el algoritmo de operación por turnos satisfacer las necesidades? La respuesta es no. Aunque estos dos algoritmos pueden satisfacer las necesidades de almacenamiento de documentos y fragmentos distribuidos uniformemente, cuando consultamos documentos a través de DocumentId, ES no sabe en qué fragmento de nodo está almacenado el ID del documento, por lo que solo puede recuperarlo de todos los fragmentos. lleva mucho tiempo. Si creamos una tabla de relaciones de mapeo entre documentos y fragmentos para este problema, aunque es posible ubicar rápidamente el fragmento de almacenamiento correspondiente al documento, cuando la cantidad de datos en el documento es grande, la eficiencia de recuperación también será menor. .
Para el problema anterior, la solución proporcionada por ES es establecer un algoritmo de mapeo de documento a fragmentos
es calcula los fragmentos correspondientes al documento mediante la siguiente fórmula:
El algoritmo hash garantiza que los datos se puedan distribuir uniformemente entre los fragmentos
el enrutamiento es un parámetro clave, el valor predeterminado es el ID del documento, también puede especificarlo usted mismo
number_of_primary_shards es el número de fragmentos primarios
Podemos ver que este algoritmo está relacionado con el número de fragmentos primarios, por lo que el número de fragmentos no se puede cambiar una vez determinado
Ya sé cómo se asignará ES El documento a los fragmentos. Expliquemos en detalle el proceso de creación y lectura del documento.
El problema del cerebro dividido, también conocido como split-brain en inglés, es un problema de red clásico en sistemas distribuidos, tal y como se muestra en la siguiente figura:
En un cluster de 3 nodos, de repente la red del nodo1 e interrumpe los otros dos nodos
La solución es realizar la elección maestra solo cuando el número de nodos elegibles maestros elegibles sea mayor o igual al quórum
Antes de hablar sobre el rendimiento en tiempo real de la búsqueda de documentos, primero hablemos de la característica inmutable del índice invertido. Dado que el índice invertido es inmutable y específico una vez generado, tiene las siguientes tres ventajas:
A continuación, explicaremos varias acciones de Lucene para implementar la búsqueda de documentos en tiempo real y analizaremos cómo funciona en Nuevas aplicaciones La búsqueda en tiempo real de ES se realiza después de agregar documentos.
Sabemos por la descripción anterior que cuando agregamos un nuevo documento, se agregará un nuevo segmento de archivo de índice invertido, pero aún lleva mucho tiempo escribir el segmento en el disco (difícil de lograr). rendimiento del tiempo), por lo que ES utiliza las características del caché del sistema de archivos para crear primero segmentos en el caché y abrir consultas para mejorar aún más el rendimiento en tiempo real. Este proceso se llama actualización en es.
Antes de actualizar, el documento se almacenará en un búfer. Durante la actualización, todos los documentos en el búfer se borrarán y se generarán segmentos.
ES ejecuta una actualización cada 1 segundo. de forma predeterminada, el rendimiento en tiempo real del documento se ha mejorado a 1 segundo, por lo que es se llama Tiempo casi real
Aunque el reflush logra un rendimiento en tiempo real de segundo nivel al almacenar documentos en el caché. , Si se produce un tiempo de inactividad antes de que el segmento de la memoria se escriba en el disco, los documentos que contiene no se pueden recuperar. ¿Cómo resolver este problema?
ES introduce el mecanismo de translog. Al escribir un documento en el búfer, la operación también se escribe en el translog.
El archivo translog se escribirá en el disco inmediatamente (fsync). En ES 6.x, cada solicitud se escribirá en el disco de forma predeterminada. También podemos modificarlo para escribirlo cada 5 segundos. por lo que el riesgo es perder 5 Para datos en segundos, la configuración relevante es index.translog.*. Al mismo tiempo, ES comprobará el archivo translog cada vez que se inicie y recuperará datos del mismo.
flush es responsable de escribir los segmentos de la memoria en el disco y realiza principalmente el siguiente trabajo:
Tiempo de ejecución de Reflush y Flush
Enfoque de ES es eliminar el primer documento y luego crear un nuevo documento
Como mencionamos anteriormente, agregar nuevos documentos se resuelve creando un nuevo segmento, y eliminar documentos se realiza manteniendo el archivo .del. El intervalo de tiempo de reflujo que configuramos ahora es de 1 segundo, luego un único índice ES generará 3600 segmentos en una hora, y la cantidad de archivos de segmentos que se generarán en un día o incluso en un mes es inimaginable. Para resolver el problema de degradación del rendimiento que puede ser causado por demasiados segmentos, ES adopta el método de fusión de segmentos para reducir la cantidad de segmentos.
Hay dos formas de realizar la operación de fusión: una es que ES realiza regularmente la operación de fusión de segmentos en segundo plano y la otra es que ejecutamos manualmente el comando force_merge_api para implementar la operación de fusión.