4. Explicación detallada del principio de fragmentación de ES y del proceso de lectura y escritura.
Antes de aprender los principios de fragmentación de ES y el proceso de lectura y escritura, primero debe aprender algunos conceptos básicos de ES y conocimientos relacionados con el entorno del clúster de ES.
4.1 Conceptos básicos de ES
4.1.1 Índice
El índice es equivalente a la base de datos en MySQL, un índice es una colección de documentos con características algo similares.
4.1.2 Tipo
El tipo es equivalente a una tabla en MySQL. Un tipo es una clasificación/partición lógica de un índice, y su semántica está completamente determinada por el usuario. Normalmente, se define un tipo para documentos que tienen un conjunto común de campos. Las diferentes versiones de ES usan los tipos de manera diferente.
| Versión | Tipo |
|---|---|
| 5.x | Soporta múltiples tipos |
| 6.x | Sólo puede haber un tipo |
| 7.x | El tipo personalizado ya no se admite de forma predeterminada; el valor predeterminado es _doc |
4.1.3 Documentación
Un documento equivale a una fila en MySQL, un documento es una unidad de información básica que se puede indexar, es decir, un dato.
4.1.4 Campos
El campo es equivalente a una columna en MySQL, es decir, un campo es un campo de atributo.
4.1.5 Mapeo
El mapeo se utiliza para especificar cómo ES maneja los datos, como el tipo de datos de un campo, el valor predeterminado, el analizador, si se puede indexar, etc.
Cómo establecer un mapeo apropiado es el enfoque del uso de ES
4.1.6 Fragmentación
Cuando los datos almacenados en un índice son demasiado grandes, el tamaño de los datos puede exceder la capacidad del espacio en disco o la eficiencia del procesamiento de solicitudes de búsqueda se reduce considerablemente. Para resolver este problema, Elasticsearch proporciona la capacidad de dividir el índice en varias partes, cada parte se denomina fragmento . Al crear un índice, puede especificar la cantidad deseada de fragmentos. Cada fragmento en sí es también un "índice" completamente funcional e independiente que se puede colocar en cualquier nodo del clúster.
Las principales funciones de fragmentación :
- Permite dividir/ampliar la capacidad del contenido de forma horizontal.
- Permite operaciones distribuidas y paralelas en fragmentos, mejorando así el rendimiento.
En cuanto a cómo se distribuye un fragmento, cómo se agregan sus documentos y cómo Elasticsearch administra completamente las solicitudes de búsqueda, todo esto es transparente para los usuarios y no es necesario preocuparse demasiado.
Nota: Mencionamos anteriormente que Elasticsearch se desarrolla en base a Lucene y Lucene también tiene el concepto de indexación. En ES, un índice de Lucene se denomina fragmento y un índice de Elasticsearch es una colección de varios fragmentos.
Cuando ES busca en el índice, envía solicitudes de consulta a cada fragmento que pertenece al índice (índice Lucene) y luego fusiona los resultados de cada fragmento en un conjunto de resultados global.
4.1.7 Copias
ES permite a los usuarios crear una o más copias de un fragmento, estas copias se denominan fragmentos replicados (réplicas) y los fragmentos copiados se denominan fragmentos primarios .
Las principales funciones de las copias:
-
Proporciona alta disponibilidad en caso de falla de fragmento/nodo .
Para lograr una alta disponibilidad, ES no colocará fragmentos de réplica y fragmentos primarios en el mismo nodo .
-
Aumenta el volumen/rendimiento de búsqueda porque las búsquedas se pueden ejecutar en paralelo en todas las réplicas.
En resumen, cada índice se puede dividir en varios fragmentos. Un índice también se puede replicar 0 veces (lo que significa que no hay replicación) o varias veces. Una vez replicado, cada índice tiene un fragmento primario (el fragmento original utilizado como fuente de replicación) y un fragmento de réplica (una copia del fragmento primario). La cantidad de fragmentos y la replicación se pueden especificar en el momento de la creación del índice. Una vez creado el índice, el usuario puede cambiar dinámicamente la cantidad de replicaciones en cualquier momento, pero no puede cambiar la cantidad de fragmentos . De forma predeterminada, cada índice en ES está fragmentado en 1 fragmento primario y 1 fragmento de réplica , lo que significa que si hay al menos dos nodos en el clúster de ES, el índice tendrá 1 fragmento primario y otro fragmento replicado (1 copia completa). En este caso, cada índice tiene un total de 2 fragmentos y debemos determinar el número de fragmentos en función de las necesidades del índice.
4.1.8 Asignación
El proceso de asignar fragmentos a un nodo, incluida la asignación de fragmentos primarios o réplicas. Si es una réplica, también incluye el proceso de copiar datos del fragmento principal. Este proceso lo completa el nodo maestro .
El entorno del clúster se explicará en el próximo capítulo.
4.2 Entorno de clúster
4.2.1 Arquitectura del sistema
-
nodo
Cada instancia de ElasticSearch en ejecución se denomina nodo.
-
grupo
Un clúster consta de uno o más nodos con el mismo nombre.clúster, que comparten la presión de los datos y la carga. Cuando se agrega o elimina un nodo del clúster, el clúster redistribuirá todos los datos de manera uniforme.
-
nodo maestro
Cuando se elige un nodo como nodo maestro, será responsable de administrar todos los cambios en todo el clúster, como agregar y eliminar índices, o agregar y eliminar nodos, etc., y generalmente no involucra al nodo maestro a nivel de documento. cambios y búsquedas Operación, cuando se configura de esta manera, incluso si el clúster tiene solo un nodo maestro, el aumento en el tráfico no lo convertirá en un cuello de botella y cualquier nodo puede convertirse en el nodo maestro.
Los usuarios pueden enviar solicitudes a cualquier nodo del clúster, incluido el nodo maestro. Cada nodo conoce la ubicación de cualquier documento y puede reenviar las solicitudes de los usuarios directamente al nodo que almacena el documento que el usuario necesita. No importa a qué nodo el usuario envíe la solicitud, es responsable de recopilar datos de cada nodo que contiene el documento que necesitamos y devolver el resultado final al cliente. Elasticsearch gestiona todo esto de forma transparente.
4.2.2 Implementar clúster
Este ejemplo es para implementar un clúster de una sola máquina en un entorno Windows.
Los pasos específicos son los siguientes:
-
En un espacio en disco adecuado, cree la carpeta del clúster ElasticSearch
-
En la carpeta ElasticSearch-cluster, copie tres copias de la versión descomprimida es-7.8.0
-
Cambie la configuración de cada es. La ruta del archivo de configuración es: la ruta de instalación de su es/config/elasticsearch.yml
Configuración clave del nodo-9201
#集群名称，同一个集群中的各个节点的这个配置项需要保持一致 cluster.name: my-es #节点名称，同一个集群中的各个节点的这个配置项需要保证唯一 node.name: node-9201 #是否是主节点 node.master: true #是否是数据节点，为false则表示不存储数据 node.data: true #ip地址，由于是本机测试，所以指定为localhost network.host: localhost #http端口号 http.port: 9201 #tcp监听端口，同一个集群中的各个节点之间通过tcp协议进行相互通信 transport.tcp.port: 9301 #集群内可以发现的其他节点的tcp路径 discovery.seed_hosts: ["localhost:9302","localhost:9303"] discovery.zen.fd.ping_timeout: 1m discovery.zen.fd.ping_retries: 5 #初始化时被指定的主节点 cluster.initial_master_nodes: ["node-9201"] #跨域配置 http.cors.enabled: true http.cors.allow-origin: "*"Configuración clave del nodo-9202
#集群名称，同一个集群中的各个节点的这个配置项需要保持一致 cluster.name: my-es #节点名称，同一个集群中的各个节点的这个配置项需要保证唯一 node.name: node-9202 #是否是主节点 node.master: true #是否是数据节点，为false则表示不存储数据 node.data: true #ip地址，由于是本机测试，所以指定为localhost network.host: localhost #http端口号 http.port: 9202 #tcp监听端口，同一个集群中的各个节点之间通过tcp协议进行相互通信 transport.tcp.port: 9302 #集群内可以发现的其他节点的tcp路径 discovery.seed_hosts: ["localhost:9301", "localhost:9303"] discovery.zen.fd.ping_timeout: 1m discovery.zen.fd.ping_retries: 5 #初始化时被指定的主节点 cluster.initial_master_nodes: ["node-9201"] #跨域配置 http.cors.enabled: true http.cors.allow-origin: "*"Configuración clave del nodo-9203
#集群名称，同一个集群中的各个节点的这个配置项需要保持一致 cluster.name: my-es #节点名称，同一个集群中的各个节点的这个配置项需要保证唯一 node.name: node-9203 #是否是主节点 node.master: true #是否是数据节点，为false则表示不存储数据 node.data: true #ip地址，由于是本机测试，所以指定为localhost network.host: localhost #http端口号 http.port: 9203 #tcp监听端口，同一个集群中的各个节点之间通过tcp协议进行相互通信 transport.tcp.port: 9303 #集群内可以发现的其他节点的tcp路径 discovery.seed_hosts: ["localhost:9301", "localhost:9302"] discovery.zen.fd.ping_timeout: 1m discovery.zen.fd.ping_retries: 5 #初始化时被指定的主节点 cluster.initial_master_nodes: ["node-9201"] #跨域配置 http.cors.enabled: true http.cors.allow-origin: "*"
4.2.3 Iniciar el clúster
-
puesta en marcha
Consulte la Sección 2.1 e inicie el nodo-9201, el nodo-9202 y el nodo-9203 en secuencia.
-
prueba(http)
{
"cluster_name": "my-es", // 集群名称
"status": "green", // 当前节点的状态
"timed_out": false, // 是否超时
"number_of_nodes": 3, // 节点总数
"number_of_data_nodes": 3, // 数据节点总数
"active_primary_shards": 0,
"active_shards": 0,
"relocating_shards": 0,
"initializing_shards": 0,
"unassigned_shards": 0,
"delayed_unassigned_shards": 0,
"number_of_pending_tasks": 0,
"number_of_in_flight_fetch": 0,
"task_max_waiting_in_queue_millis": 0,
"active_shards_percent_as_number": 100.0
}
4.2.4 Conmutación por error
-
Cree el siguiente índice en el clúster para facilitar el aprendizaje posterior.
Cree un índice de usuarios y asigne tres fragmentos principales y una réplica (una réplica para cada fragmento principal).
{ "settings" : { "number_of_shards" : 3, "number_of_replicas" : 1 } } -
Utilice el complemento del navegador para ver el estado general del clúster
Solo iniciamos el nodo nodo-9201 y el nodo nodo-9202
Utilice el complemento elasticsearch-head para ver el estado del clúster especificado directamente a través del navegador.
Como se puede ver en la figura anterior, el valor de salud del clúster es verde en este momento, lo que significa que en el clúster actual, los tres fragmentos principales y las tres réplicas están asignados correctamente a diferentes nodos (tenga en cuenta que lo presentamos anteriormente). no es seguro si el fragmento principal y su réplica están en el mismo nodo).
Esto significa que si hay algún problema con algún nodo del cluster, nuestros datos permanecerán intactos. Todos los documentos indexados recientemente se almacenarán en el fragmento principal y luego se copiarán en los fragmentos de réplica correspondientes en paralelo. Esto garantiza que podamos obtener documentos tanto del fragmento principal como del fragmento de réplica.
Es decir, si el nodo anterior nodo-9201 falla, no afectará la función de consulta de ES y aún podremos obtener datos del documento de la copia.
4.2.5 Expansión horizontal
Cuando la aplicación se ha estado ejecutando durante un período de tiempo y la cantidad de datos en ES aumenta gradualmente, podemos lograr una expansión horizontal agregando nuevos nodos al clúster de ES. Cuando se inicia el tercer nodo, el clúster tendrá tres nodos y reasignará los fragmentos para distribuir la carga.
En este momento, inicie el nodo nodo-9203 y verifique nuevamente la asignación de fragmentos del clúster.
Como puede ver en la figura anterior, cuando un nuevo nodo se une al clúster, el clúster redistribuye los fragmentos. En este momento, los recursos de hardware (CPU, RAM, E/S) de cada nodo serán compartidos por menos fragmentos y se mejorará el rendimiento de cada fragmento.
Sharding es un motor de búsqueda completamente funcional que tiene la capacidad de utilizar todos los recursos de un nodo. Nuestro índice con 6 fragmentos (3 fragmentos primarios y 3 fragmentos de réplica) se puede expandir a un máximo de 6 nodos . Hay un fragmento en cada nodo y cada fragmento tiene todos los recursos del nodo donde se encuentra.
Entonces, ¿qué pasa si queremos expandirnos más allá de los 6 nodos?
El número de fragmentos primarios se determina cuando se crea el índice . De hecho, este número define la cantidad máxima de datos que este índice puede almacenar. (El tamaño real depende de sus datos, hardware y escenarios de uso). Sin embargo, las operaciones de lectura (la búsqueda y devolución de datos pueden ser procesadas por los fragmentos primarios o de réplica al mismo tiempo, por lo que cuantos más fragmentos de réplica tenga, mejor tendrá un mayor rendimiento.
Por lo tanto, ES permite a los usuarios ajustar dinámicamente la cantidad de fragmentos de réplica en un clúster en ejecución y escalar el clúster según demanda.
-
Ajuste el número de réplicas a 2 (dos fragmentos de réplica para cada fragmento principal)
Envíe una solicitud PUT al clúster ES, http/localhost:9201/index name/_settings, y agregue el siguiente contenido en el cuerpo de la solicitud
{ "number_of_replicas":2 }
-
Ver el estado del clúster
El índice de usuarios ahora tiene 9 fragmentos: 3 fragmentos primarios y 6 fragmentos de réplica. Esto significa que podemos escalar el clúster a 9 nodos, con un fragmento en cada nodo. En comparación con los 3 nodos originales, el rendimiento de la búsqueda del clúster se puede mejorar 3 veces. Por supuesto, simplemente agregar más fragmentos de réplica a un clúster con la misma cantidad de nodos no mejorará el rendimiento, porque cada fragmento obtendrá menos recursos de los nodos. En este momento, es necesario agregar más recursos de hardware para mejorar el rendimiento. Pero más fragmentos de réplica aumentan la cantidad de redundancia de datos: según la configuración de nodo anterior, podemos perder 2 nodos sin perder ningún dato.
4.2.6 Cómo afrontar los fallos
Cuando el nodo maestro en el clúster ES deja de funcionar (el nodo-9201 se apaga), el clúster ES elegirá un nuevo nodo (estos nodos alternativos son aquellos nodos cuyo elemento de configuración node.master en el archivo de configuración es verdadero. Dado que Al configurar el entorno del clúster anteriormente, este elemento de configuración de los tres nodos es verdadero, por lo que en este momento el clúster ES seleccionará un nodo del nodo-9202 y el nodo-9203 como el nuevo nodo maestro).
Puede ver el estado del entorno del clúster ES en este momento a través del complemento de la siguiente manera:
Como se puede ver en la figura anterior, el nodo primario en este momento es el nodo-9203. Los fragmentos originales 0 y 1 en el nodo-9201 son fragmentos primarios. El nuevo nodo primario copiará inmediatamente las copias correspondientes de estos fragmentos en el nodo -9202 El fragmento se promociona al fragmento principal y el estado del clúster será amarillo en este momento. **Este proceso de promoción del fragmento primario ocurre instantáneamente, como presionar un interruptor. **Aunque tenemos los tres fragmentos primarios, también hemos configurado que cada fragmento primario debe corresponder a 2 fragmentos de réplica. En este momento, solo hay un fragmento de réplica, por lo que el clúster está en estado amarillo, aunque está en estado amarillo, pero las funciones del clúster ES se pueden utilizar como de costumbre.
Si reiniciamos el nodo-9201, el clúster puede asignar nuevamente los fragmentos de réplica que faltan y el estado del clúster se restaurará a su estado anterior. Si el nodo-9201 aún posee los fragmentos anteriores, intentará reutilizarlos y solo copiará los archivos de datos modificados del fragmento principal. En comparación con el clúster anterior, solo se ha cambiado el nodo maestro.
La figura anterior muestra el estado del clúster después de iniciar nuevamente el nodo-9201.
Nota: Los lectores deben hacer todo lo posible para operar manualmente estos capítulos sobre conmutación por error, expansión horizontal y respuesta a fallas para comprender el concepto de diseño del clúster ES.
4.2.7 Cálculo de ruta
-
algoritmo de enrutamiento
Al agregar un documento a un clúster ES, el documento se almacenará en un fragmento principal. Dado que habrá varios fragmentos primarios en un entorno de clúster, ¿cómo sabe Elasticsearch en qué fragmento principal se debe colocar este documento?
Para resolver los problemas anteriores, Elasticsearch utiliza un algoritmo para realizar cálculos de enrutamiento para determinar en qué fragmento se debe colocar el documento, y también utiliza este algoritmo para obtener el fragmento que almacena el documento al realizar la consulta.
El algoritmo es como sigue:
shard = hash(routing) % number_of_primary_shardsel enrutamiento es un valor variable, el valor predeterminado es el _id del documento y también puede ser definido por el usuario.
El significado de este algoritmo es: tomar el valor hash del enrutamiento y dividirlo por el número de fragmentos primarios para obtener el resto. El valor resultante es un número entre 0 (número de fragmentos primarios - 1) (el conteo comienza desde 0, por ejemplo como 3 fragmentos primarios) Fragmentación, entonces el rango es 0 2), que es la ubicación de fragmentación donde se almacena el documento.
Esto explica por qué es importante determinar el número de fragmentos primarios al crear el índice y nunca cambiar este número: porque si el número cambia, todos los valores de enrutamiento anteriores dejarán de ser válidos y ya no se encontrará el documento.
-
Enrutamiento personalizado
Todas las API de documentos (obtener, indexar, eliminar, agrupar, actualizar y mget) aceptan un parámetro de enrutamiento llamado enrutamiento, a través del cual podemos personalizar la asignación de documentos a fragmentos. Se puede utilizar un parámetro de enrutamiento personalizado para garantizar que todos los documentos relacionados (como todos los documentos que pertenecen al mismo usuario) se almacenen en el mismo fragmento.
Esta parte se explicará en detalle en capítulos posteriores.
4.3 Control de fragmentación
Al describir esta sección, utilice el siguiente índice de prueba de clúster en un entorno de clúster, que tiene 3 fragmentos principales y 1 réplica .
En este clúster, cada nodo tiene la capacidad de manejar cualquier solicitud. Cada nodo conoce la ubicación de cualquier documento en el clúster, por lo que las solicitudes se pueden reenviar directamente al nodo requerido. En los siguientes ejemplos, enviaré todas las solicitudes al nodo-9201, que se denomina nodo coordinador.
Nota: En el trabajo, para lograr el equilibrio de carga, generalmente se sondean todos los nodos del clúster para que puedan transportar solicitudes de forma conjunta, en lugar de enviar todas las solicitudes al mismo nodo.
4.3.1 Proceso de escritura (proceso aproximado)
En Elasticsearch, las solicitudes para agregar, eliminar y modificar documentos (completos) pertenecen al proceso de escritura. El proceso de escritura debe completarse en el fragmento principal antes de sincronizarse con el fragmento de réplica.
Por ejemplo solicitar:
PONER/ELIMINAR http://localhost:9200/cluster-test/_doc/1001
Agregar, actualizar completamente o eliminar un documento específico
Si no se especifica la clave principal al agregar un documento, ES generará automáticamente la clave principal y realizará cálculos de enrutamiento basados en la clave principal generada automáticamente.
A continuación, usamos un ejemplo para aprender cómo se realiza el proceso de escritura en Elasticsearch en el clúster ES.
Supongamos que enviamos solicitudes para agregar, eliminar y modificar documentos (completos) al nodo-9201, luego ES realizará el siguiente procesamiento:
- node-9201 usa el _id del documento (si se especifica el parámetro de enrutamiento, se usa el parámetro correspondiente) para realizar el cálculo de ruta y obtener el fragmento al que pertenece el documento. Por ejemplo, si pertenece al fragmento 0, entonces el nodo El nodo -9201 reenviará la solicitud al nodo-9202 (porque el fragmento primario 0 está en el nodo-9202).
- node-9202 maneja la solicitud en el fragmento primario 0. Si tiene éxito, reenviará la solicitud al nodo 9203 y permitirá que el fragmento de réplica 0 realice el mismo procesamiento. Cuando el fragmento de réplica 0 se procese con éxito, se notificará al nodo 9202 y luego el nodo 9202 notificará el resultado exitoso del procesamiento. .nodo-9201.
- node-9201 devuelve el resultado de la solicitud del cliente.
El diagrama específico es el siguiente:
Cuando el cliente recibe una respuesta exitosa, los cambios del documento se ejecutaron en el fragmento principal y en todos los fragmentos de réplica, y los cambios son seguros. Por supuesto, Elasticsearch también proporciona algunos parámetros para que los usuarios intervengan en este proceso (lo que puede mejorar aún más el rendimiento a expensas de la seguridad de los datos). Por supuesto, estos parámetros rara vez se utilizan porque Elasticsearch ya es lo suficientemente rápido.
La siguiente tabla enumera algunos parámetros y sus significados que pueden intervenir en este proceso.
| parámetro | significado |
|---|---|
| consistencia | consistencia, es decir, consistencia . El valor del parámetro de coherencia se puede establecer en uno (siempre que el estado del fragmento primario sea normal, se realiza la operación de escritura), todo (el estado de todos los fragmentos primarios y de réplica debe ser normal antes de realizar la operación de escritura) y quórum (grande. La mayoría de los fragmentos están en un estado normal y se permiten operaciones de escritura), el valor predeterminado es quórum, lo que significa que bajo la configuración predeterminada, incluso antes de intentar realizar una operación de escritura, el fragmento principal requerirá un número específico ( quórum) La operación de escritura se realizará solo cuando la copia del fragmento esté en un estado activo y disponible. Esto es para evitar operaciones de escritura cuando ocurre una falla en la red, lo que puede provocar inconsistencia en los datos. La fórmula de cálculo para la cantidad especificada (quórum) es int((primary + number_of_replicas) / 2) + 1 . Entre ellos, number_of_replicas se refiere a la cantidad de réplicas establecidas en la configuración del índice, no a la cantidad de réplicas actualmente activas. |
| se acabó el tiempo | ¿Qué sucede si no hay suficientes fragmentos de réplica? Elasticsearch esperará a que aparezcan más fragmentos; de forma predeterminada, esperará hasta 1 minuto. Los usuarios pueden ajustar el tiempo de espera utilizando el parámetro de tiempo de espera. |
Nota: Al crear un nuevo índice, el número de réplicas de índice por defecto es 1, lo que significa que se deben requerir dos réplicas de fragmentos activos para cumplir con el número especificado.Esta configuración predeterminada nos impedirá realizar operaciones de escritura en un solo nodo. Por lo tanto, ES estipula que la cantidad especificada solo tendrá efecto cuando number_of_replicas sea mayor que 1 .
4.3.2 Proceso de lectura (proceso aproximado)
Proceso de lectura, lo que se analiza aquí es el proceso de lectura de documentos específicos según la ruta o la identificación. (Nota para distinguirlo del proceso de búsqueda de datos).
Por ejemplo, la solicitud es GET http://localhost:9201/cluster-test/_doc/1001
A continuación, usamos un ejemplo para aprender cómo se realiza el proceso de lectura en Elasticsearch en el clúster ES.
Supongamos que enviamos una solicitud para leer datos al nodo-9201, luego ES realizará el siguiente procesamiento:
-
El nodo-9201 realiza un cálculo de enrutamiento en el documento y obtiene el fragmento al que pertenece el documento. Por ejemplo, pertenece al fragmento 0, y utilizará el algoritmo de sondeo aleatorio por turnos para seleccionar aleatoriamente uno entre el fragmento primario 0 y todos sus fragmentos de réplica., deje que la solicitud de lectura se cargue y el nodo nodo-9201 reenviará la solicitud a un nodo específico, como el nodo-9203.
Utilice el parámetro de ruta o utilice directamente la identificación para calcular la ruta y leer los datos.
-
Node-9203 procesa la solicitud en la réplica del fragmento 0 y devuelve los resultados de la consulta al nodo-9201.
-
node-9201 devuelve los resultados de la consulta al cliente.
El diagrama específico es el siguiente:
4.3.3 Proceso de actualización (proceso aproximado)
La actualización parcial de un documento combina los procesos de lectura y escritura explicados anteriormente.
A continuación, usamos un ejemplo para aprender cómo se realiza el proceso de actualización en Elasticsearch en el clúster ES.
Supongamos que enviamos una solicitud para actualizar datos al nodo-9201, luego ES realizará el siguiente procesamiento:
-
El nodo nodo-9201 realiza el cálculo de ruta en el documento y obtiene el fragmento al que pertenece el documento, por ejemplo, pertenece al fragmento 0.
-
El nodo nodo-9201 reenvía la solicitud al nodo nodo-9202 (el fragmento primario 0 está en este nodo).
-
El nodo node-9202 procesa la solicitud de actualización, lee el documento, modifica los datos JSON en el campo _source e intenta volver a indexar el documento (si otro proceso está modificando el documento en este momento, se volverá a intentar el paso 3 después del retry_on_conflict se ha excedido el número de veces) darse por vencido).
Volver a indexar el documento mencionado anteriormente en realidad significa marcar la versión anterior del documento para su eliminación (es decir, marcar la versión anterior del documento en el archivo .del), luego generar una nueva versión del documento y escribir esta nueva versión. del documento documento.
-
Si el nodo nodo-9202 actualiza con éxito el documento, reenviará la nueva versión del documento al nodo nodo-9203, y el nodo nodo-9203 reconstruirá el índice (índice invertido) para la nueva versión del documento.
En este paso, el nodo secundario hará lo mismo que el nodo principal. (Marque la versión anterior del documento como eliminada y escriba la nueva versión del documento)
-
Una vez que el nodo nodo-9203 se actualiza correctamente, se devuelve una respuesta al nodo nodo-9202.
-
El nodo nodo-9202 devolverá el resultado de la actualización exitosa al nodo nodo-9201.
-
El nodo nodo-9201 devuelve los resultados al cliente.
El diagrama específico es el siguiente:
Nota :
Cuando el fragmento principal reenvía cambios al fragmento de réplica, no reenvía solicitudes de actualización. En lugar de ello, envía una nueva versión del documento completo. Tenga en cuenta que estos cambios se reenviarán a los fragmentos de réplica de forma asincrónica y no hay garantía de que lleguen en el mismo orden en que se enviaron. Si Elasticsearch solo reenvía solicitudes de cambio, es posible que los cambios se apliquen en el orden incorrecto, lo que provocará documentos dañados.
4.3.4 Proceso de operación de múltiples documentos (proceso aproximado)
El proceso de operación de múltiples documentos aquí se refiere a solicitudes mget y masivas.
Flujo de procesamiento de la solicitud mget:
-
El cliente envía una solicitud mget al nodo nodo-9201.
-
El nodo nodo-9201 crea solicitudes de recuperación de múltiples documentos para cada nodo y luego reenvía estas solicitudes a todos los nodos en paralelo, como el nodo-9202 y el nodo-9203.
-
Después de que el nodo nodo-9202 y el nodo nodo-9203 procesen la solicitud, el resultado se responderá al nodo nodo-9201.
-
El nodo nodo-9201 responde al cliente con el resultado de la solicitud.
Todo el proceso es equivalente a un lote de solicitudes de obtención. Para el procesamiento de solicitudes por cada nodo, consulte el proceso de lectura presentado anteriormente.
Flujo de procesamiento de solicitudes masivas:
-
El cliente envía una solicitud masiva al nodo nodo-9201.
-
El nodo node-9201 crea solicitudes por lotes para cada nodo y las reenvía en paralelo a cada nodo que contiene el fragmento principal.
-
Una vez que todos los nodos hayan procesado la solicitud, los resultados se responderán al nodo nodo-9201.
-
El nodo nodo-9201 responde al cliente con el resultado de la solicitud.
Todo el proceso es equivalente a un lote de solicitudes nuevas, eliminadas y actualizadas. Para el procesamiento de solicitudes por cada nodo, consulte el proceso de escritura presentado anteriormente.
4.4 Principio de fragmentación
4.4.1 Búsqueda de documentos (búsqueda por párrafo)
-
Índice invertido inmutable
La recuperación temprana de texto completo crearía un gran índice invertido para toda la colección de documentos y lo escribiría en el disco. Una vez que se necesita crear un índice invertido para un nuevo documento, se debe reemplazar todo el índice invertido, es decir, el índice invertido. es reemplazado Una vez escrito en el disco, no se puede cambiar y solo se puede reemplazar por completo.
Las ventajas de esto son:
-
No se requiere bloqueo. Si nunca actualiza el índice, no necesita preocuparse de que varios procesos modifiquen datos al mismo tiempo.
-
Una vez que se lee un índice en la memoria caché del sistema de archivos del kernel, permanece allí debido a su inmutabilidad . Siempre que haya suficientes en la memoria caché del sistema de archivos
espacio, entonces la mayoría de las solicitudes de lectura solicitarán memoria directamente sin llegar al disco. Esto proporciona un gran aumento de rendimiento.
-
Escribir un único índice invertido grande permite comprimir los datos, lo que reduce la cantidad de E/S del disco y el uso del índice que debe almacenarse en la memoria caché.
Las desventajas de esto también son muy obvias: si necesita hacer que un nuevo documento pueda buscarse, necesita reconstruir todo el índice invertido, lo que impone un gran límite a la cantidad de datos que puede contener un índice invertido, o el índice Hay limitaciones significativas sobre la frecuencia con la que se puede actualizar.
-
-
Actualizar dinámicamente el índice invertido
Para actualizar el índice invertido y al mismo tiempo conservar la inmutabilidad del índice invertido, Elasticsearch adopta el método de complementar el índice invertido para reflejar las modificaciones recientes agregando nuevos índices complementarios en lugar de reescribir directamente todo el índice invertido Índice de clasificación . Durante la recuperación, cada índice invertido se consultará por turno y los resultados se fusionarán después de que se complete la primera consulta, lo que puede evitar la pérdida de rendimiento causada por la reconstrucción frecuente del índice invertido.
-
Buscar por segmento
Elasticsaerch está desarrollado en base a Lucene y tiene el concepto de búsqueda por segmento . Cada segmento en sí es un índice invertido. Además de los segmentos, también existe el concepto de punto de confirmación , que registra todos los segmentos actualmente disponibles . El nuevo índice invertido complementario mencionado anteriormente es en realidad un nuevo segmento.
La relación entre segmentos y puntos de envío se muestra en la siguiente figura.
-
Escribir datos bajo el pensamiento de segmentación.
Cuando se agrega un nuevo documento al índice, pasará por el siguiente proceso ( aquí solo nos centramos en el uso de segmentos y puntos de envío ) .
-
Se agregan nuevos documentos a la memoria caché.
El diagrama esquemático del punto de envío, segmento y memoria caché en este momento es el siguiente
-
De vez en cuando [de forma predeterminada, después de un cierto período de tiempo, o cuando la cantidad de datos en la memoria alcanza una determinada etapa, los datos se enviarán al disco en lotes. ( Los detalles específicos se explicarán más adelante en el principio subyacente del proceso de escritura )], se envía el caché
-
Se escribe un nuevo segmento (índice invertido suplementario) en el disco
-
Se genera un nuevo punto de confirmación que contiene el nuevo segmento y se escribe en el disco.
Una vez que un segmento tiene un punto de confirmación, significa que el segmento solo tiene permiso de lectura y ha perdido el permiso de escritura; por el contrario, cuando el segmento está en la memoria, solo tiene permiso para escribir datos pero no permiso para leer datos. , por lo que no se puede recuperar.
-
El disco está sincronizado: todas las escrituras en espera en la caché del sistema de archivos se vacían en el disco para garantizar que se escriban en archivos físicos.
-
-
Se abre un nuevo segmento para que se puedan recuperar los documentos que contiene
-
La memoria caché se borra, esperando recibir nuevos documentos.
El diagrama esquemático del punto de envío, segmento y memoria caché en este momento es el siguiente
-
-
Eliminar/actualizar datos bajo el pensamiento de segmentación
Cuando es necesario eliminar datos, dado que el segmento donde se encuentran los datos es inmutable, el documento no se puede eliminar directamente del segmento anterior. En este momento, cada punto de envío contendrá un archivo .del, que almacena la identificación de los datos eliminados. ( eliminación lógica )
Cuando sea necesario actualizar los datos, primero se realizará la operación de eliminación y luego se realizará la nueva operación, es decir, los datos antiguos se registrarán primero en el archivo .del y luego se agregará un dato actualizado. al nuevo segmento.
-
Consultar datos basándose en el pensamiento de segmentación.
Consulte los datos que cumplen con las condiciones de la consulta en todos los segmentos, luego combine los conjuntos de resultados de la consulta en cada segmento para obtener un conjunto de resultados grande y luego elimine los datos eliminados registrados en el archivo .del y devuélvalos al cliente.
4.4.2 Búsqueda casi en tiempo real
Se puede ver en el nuevo proceso de datos bajo la idea de segmentación introducida en la sección anterior que cuando se escribe un nuevo documento, los datos todavía están en la memoria caché. En este momento, estos datos no se pueden consultar, por lo que la consulta de Elasticsearch Se busca casi en tiempo real .
Al enviar un nuevo segmento al disco, debe utilizar la llamada al sistema fsync para asegurarse de que los datos se escriban físicamente en el disco para que no se pierdan después de un corte de energía. Sin embargo, fsync es muy caro. Si fsync se utiliza para escribir datos físicamente en el disco cada vez que se agregan datos nuevos o modificados, provocará una gran pérdida de rendimiento.
En Elasticsearch se utiliza un enfoque más ligero para hacer que un documento sea recuperable, es decir, fsync se elimina del proceso desde que se escribe el documento hasta que se puede recuperar, para mejorar el rendimiento. Para lograr este objetivo, entre Elasticsearch y el disco se encuentra el caché del sistema de archivos del sistema operativo (OS Cache) .
Entre la memoria caché de Elasticsearch (Memoria) y el disco duro (Disco) se encuentra la memoria caché del sistema de archivos del sistema operativo (OS Cache)
Como se describió en la sección anterior, el documento en el búfer de índice de memoria se escribirá en un nuevo segmento, pero aquí el nuevo segmento se escribirá primero en la memoria caché del sistema de archivos** (este paso será menos costoso) y se se descargan al disco en lotes más adelante (este paso es relativamente costoso)**. Siempre que el archivo ya esté en la memoria caché del sistema de archivos, se puede abrir y leer como cualquier otro archivo, es decir, se puede recuperar.
Como se introdujo anteriormente, el proceso de escribir datos en el búfer de memoria en el caché del sistema de archivos se llama actualizar . Esta operación se realiza de forma predeterminada cada segundo o cuando los datos en el búfer de memoria alcanzan una cierta cantidad de datos (sección 4.4.1 Como descrito en), es por eso que decimos que Elasticsearch es una búsqueda casi en tiempo real (los cambios en el documento serán visibles después de un segundo, por lo que no es en tiempo real, sino casi en tiempo real).
Por supuesto, Elasticsearch proporciona una API de actualización para que los usuarios realicen operaciones de actualización manualmente, como enviar solicitud/nombre de índice/_refresh.
Aunque el vaciado es una operación mucho más ligera que la confirmación, aún conlleva una sobrecarga de rendimiento. Las actualizaciones manuales son útiles al escribir pruebas, pero no las haga cada vez que indexe un documento en un entorno de producción. En cambio, nuestras aplicaciones deben ser conscientes de la naturaleza casi en tiempo real de Elasticsearch y aceptar sus deficiencias.
Algunos escenarios no requieren una actualización cada segundo (como agregar una gran cantidad de archivos de registro a ES) ¿Cómo satisfacer las necesidades de los escenarios anteriores?
Podemos ajustar el intervalo de tiempo para realizar operaciones de actualización configurando el intervalo de actualización del índice.
{
"settings": {
"refresh_interval": "30s"
}
}
refresco_interval puede actualizar dinámicamente los índices existentes. En un entorno de producción, cuando crea un índice nuevo de gran tamaño, puede desactivar las actualizaciones automáticas y luego volver a activarlas cuando comience a utilizar el índice.
# 关闭自动刷新
PUT /索引名/_settings
{
"refresh_interval": -1 }
# 每一秒刷新
PUT /索引名/_settings
{
"refresh_interval": "1s" }
En este momento, el proceso de escritura de Elasticsearch se muestra en la siguiente figura. ( El propósito de este diagrama de flujo es presentarle paso a paso las ideas de diseño del proceso de escritura de Elasticsearch. El diagrama de flujo aquí no está completo ).
4.4.3 Cambios persistentes
En la sección anterior, presentamos el mecanismo de consulta liviano de Elasticsearch que escribe datos de documentos desde la memoria caché al caché del sistema de archivos a través de la operación de actualización. En este proceso, se elimina la llamada al sistema fsync. Si no se usa fsync para escribir los datos de Cuando el caché del sistema de archivos se escribe en el disco duro (llamamos a la operación de escribir los datos en el caché del sistema de archivos en el disco duro ) , no hay garantía de que seguirá existiendo después de un corte de energía o incluso de que el programa se cierre. normalmente (es decir, no hay persistencia) .
Para garantizar la confiabilidad, Elasticsearch debe garantizar que los cambios de datos persistan en el disco. Para lograr este requisito, Elasticsearch agrega un translog (registro de transacciones) como mecanismo de compensación para evitar la pérdida de datos. Todos los cambios que no se han realizado se registrado en el translog. Los datos persistieron en el disco.
Con respecto a translog , debe comprender las siguientes tres preguntas.
-
¿Cuándo se escriben los datos para translog?
Cuando los datos se escriben en la memoria caché, se agregará una copia de los datos al translog. ( Esta parte se presentará en detalle más adelante )
-
¿Cuándo utilizar datos de translog?
Cuando se inicia Elasticsearch, no solo cargará los segmentos persistentes según el último punto de envío, sino que también volverá a conservar los datos no persistentes en el disco según los datos del translog.
-
¿Cuándo se deben borrar los datos en translog?
Cuando los datos de la caché del sistema de archivos se vacían en el disco, el translog antiguo se elimina y se genera un nuevo translog en blanco.
**De forma predeterminada, se realizará una operación de descarga cada 30 minutos o cuando el translog sea demasiado grande (el valor predeterminado es 512 MB). **Normalmente, la actualización automática es suficiente. Cuando Elasticsearch intenta restaurar o reabrir un índice, necesita reproducir todas las operaciones en el translog, por lo que la recuperación es más rápida si el registro es más corto.
La capacidad máxima de translog se puede especificar a través del parámetro de configuración index.translog.flush_threshold_size .
Después de agregar translog, el proceso de escritura de Elasticsearch se muestra en la siguiente figura (el proceso detallado se explicará en detalle en la sección sobre los principios subyacentes del proceso de escritura)
Aunque translog se utiliza para evitar la pérdida de datos, también existe el riesgo de pérdida de datos .
-
Explicación detallada de la escritura translog.
Como se puede ver en el diagrama de flujo de escritura anterior, el translog tiene una copia en la memoria caché y en el disco, y solo es confiable cuando el translog en la memoria se vacía en el disco a través de la llamada al sistema fsync.
Hay dos modos para ejecutar operaciones de descarga translog: asíncrono y sincrónico. El modo predeterminado es el modo síncrono . Este modo se puede ajustar a través del parámetro index.translog.durability , y el tiempo para la ejecución de descarga automática se puede controlar a través del parámetro index.translog .sync_interval .intervalo.
#异步模式 index.translog.durability=async #同步模式 index.translog.durability=requestCuando está en modo síncrono , de forma predeterminada se realizará una operación fsync después de cada solicitud de escritura. Este proceso ocurre tanto en el fragmento principal como en el fragmento de réplica. Esto significa que toda la solicitud se sincroniza con el fragmento principal y el fragmento de réplica. no obtendrá una respuesta 200 hasta que el translog esté en el disco del segmento. (Es decir, en este modo, si la solicitud de escritura tiene éxito, significa que estos datos se han escrito en el translog del disco, lo que garantiza la confiabilidad de los datos).
Cuando está en modo asincrónico , la operación fsync se realizará una vez cada 5 segundos de forma predeterminada y esta acción es asincrónica. Esto significa que incluso si su solicitud de escritura obtiene una respuesta 200, no significa que los datos de esta solicitud se hayan descartado. .disco al translog en el disco, es decir, esta operación no es confiable. (Si se corta la alimentación en cinco segundos, esta parte de los datos se perderá).
Aviso
La operación de vaciado translog de Elasticsearch está predeterminada en modo síncrono. Aunque se realiza una operación de vaciado translog cada vez que se modifican los datos, el costo es mucho menor que realizar una operación de vaciado de segmento cada vez que se modifican los datos. Por lo tanto, se utiliza el mecanismo de compensación translog. Es una solución que equilibra el rendimiento y la seguridad de los datos. A menos que existan requisitos especiales, el modo síncrono se utiliza de forma predeterminada .
4.4.4 Fusión de segmentos
-
Introducción y proceso
En la Sección 4.4.2, introdujimos que la operación de actualización ejecutada cada segundo creará un nuevo segmento. Después de un largo período de acumulación, habrá una gran cantidad de segmentos en el índice. Cuando el número de segmentos es demasiado grande, No solo ocupará demasiados recursos del servidor, sino que también afectará el rendimiento de la recuperación.
Como se mencionó anteriormente, cada vez que realice una búsqueda, se consultarán los datos que cumplan con las condiciones de consulta en todos los segmentos y luego se fusionarán los conjuntos de resultados consultados en cada segmento, lo que más lenta será la recuperación.
Elasticsearch utiliza la fusión de segmentos para resolver el problema de demasiados segmentos. Hay un proceso en segundo plano en Elasticsearch que es específicamente responsable de la fusión de segmentos y realizará operaciones de fusión de segmentos con regularidad.
El proceso operativo de fusión de segmentos es el siguiente:
- Fusione varios segmentos pequeños en un nuevo segmento grande. Durante la fusión, los documentos eliminados (documentos correspondientes a los identificadores de documentos almacenados en el archivo .del) o las versiones antiguas de documentos actualizados no se escribirán en el nuevo párrafo.
- Vacíe el nuevo archivo de segmento en el disco
- Identifique todos los archivos de segmentos nuevos en este punto de confirmación y excluya los archivos de segmentos antiguos y fusionados
- Abrir un nuevo archivo de segmento para uso en búsquedas
- Después de que todas las solicitudes de recuperación se hayan transferido de los archivos de segmentos pequeños a los archivos de segmentos grandes, elimine los archivos de segmentos antiguos.
El proceso anterior es transparente para los usuarios y Elasticsearch lo ejecutará automáticamente al indexar y buscar documentos. Los segmentos que se fusionarán pueden ser índices que se han enviado en el disco o segmentos que aún no se han enviado en la memoria. Durante el proceso de fusión, las funciones actuales de indexación y búsqueda no se interrumpirán .
-
Impacto en el rendimiento de la fusión de segmentos
De la introducción anterior al proceso de fusión de segmentos, podemos ver que el proceso de fusión de segmentos no solo implica la lectura de segmentos y la generación de nuevos segmentos, sino que también implica la operación de descarga de segmentos, por lo que si no se controla la fusión de segmentos, Consumirá muchos recursos de E/S y CPU y también afectará el rendimiento de la búsqueda.
En Elasticsearch, solo se pueden fusionar diez segmentos a la vez de forma predeterminada. Si la capacidad del segmento es superior a 5 GB, no participará en la fusión de segmentos y la velocidad predeterminada del hilo de fusión es 20 MB/S.
Podemos ajustar las reglas de fusión de segmentos a través de los siguientes parámetros.
#更改配速为100MB/s { "persistent" : { "indices.store.throttle.max_bytes_per_sec" : "100mb" } } #设置优先被合并的段的大小，默认为2MB index.merge.policy.floor_segment #设置一次最多合并的段数量，默认为10个 index.merge.policy.max_merge_at_once #设置可被合并的段的最大容量，默认为5GB index.merge.policy.max_merged_segment
4.4.5 Explicación detallada del proceso de escritura
En la Sección 4.2.8.1, aprendimos el proceso general del proceso de escritura. Aprendimos cómo Elasticsearch procesa las solicitudes de escritura iniciadas por el cliente en un entorno de clúster en su conjunto. En esta sección, el blogger resumirá el proceso de escritura en función del procesamiento específico de cada nodo después de recibir la solicitud de escritura.
El proceso de escritura se resume de la siguiente manera:
- El cliente envía una solicitud de escritura al nodo coordinador.
- El nodo coordinador realiza el cálculo de enrutamiento (consulte la sección 4.2.7 para obtener más detalles) en función del parámetro de enrutamiento (si no se especifica, el valor predeterminado es la ID del documento) y calcula la ubicación del fragmento principal al que pertenece el documento.
- El nodo coordinador reenvía la solicitud de escritura al nodo donde se encuentra el fragmento principal.
- Después de que el nodo donde se encuentra el fragmento principal recibe la solicitud de escritura, ingresa al proceso de escritura de un solo nodo.
- Después de que el nodo donde se encuentra el fragmento primario haya procesado la solicitud de escritura, reenviará la solicitud de escritura en paralelo a todos los nodos donde se encuentran sus fragmentos de réplica. Después de que estos nodos reciban la solicitud, realizarán el mismo procesamiento.
- Después de que los nodos donde se encuentran todos los fragmentos de réplica procesen la solicitud de escritura, los resultados del procesamiento se devolverán al nodo donde se encuentra el fragmento principal, y el nodo donde se encuentra el fragmento principal devolverá los resultados del procesamiento al nodo coordinador.
- El nodo coordinador devuelve los resultados al cliente.
El proceso de escritura detallado de un solo nodo en Elasticsearch se muestra en la siguiente figura.
La descripción del texto es la siguiente:
-
Escribir datos en la memoria caché (**búfer de índice)**
-
Agregar datos al registro de transacciones ( translog )
-
De forma predeterminada , la operación de actualización se realiza una vez por segundo para actualizar los datos de la memoria caché a la **Caché del sistema de archivos (caché del sistema operativo)**, generar un segmento ( segmento ) y abrir el segmento para la búsqueda del usuario, y en al mismo tiempo la memoria caché ( búfer de índice ).
-
De forma predeterminada, el translog en la memoria se escribe ( vacía ) en el disco a través de la llamada al sistema fsync cada vez que se escriben datos .
El modo síncrono consiste en sincronizar con el disco cada vez que se escriben datos.
El modo asíncrono es fsync al disco cada 5 segundos
-
De forma predeterminada, cada 30 minutos o después de que el tamaño del translog supere los 512 M , se ejecutará una descarga para escribir los datos del sistema de archivos en el disco.
- Generar nuevos segmentos y escribir en el disco.
- Genere un nuevo punto de confirmación que contenga el nuevo segmento y escríbalo en el disco
- Eliminar el translog antiguo y generar un nuevo translog
-
Elasticsearch iniciará el proceso de fusión , fusionará segmentos pequeños y medianos en segundo plano y reducirá el número de segmentos de índice. Este proceso se realizará en la memoria caché y el disco del sistema de archivos.
4.4.6 Explicación detallada del proceso de lectura
El proceso de lectura se resume en lo siguiente:
- El cliente envía una solicitud de lectura al nodo de coordinación.
- El nodo coordinador realiza el cálculo de enrutamiento (consulte la sección 4.2.7 para obtener más detalles) según el parámetro de enrutamiento (si no se especifica, el valor predeterminado es la ID del documento) y calcula la ubicación del fragmento al que pertenece el documento.
- Utilice el algoritmo de sondeo aleatorio por turnos para seleccionar aleatoriamente uno de los fragmentos al que pertenece el documento (fragmento primario o fragmento de réplica) y reenvíe la solicitud al nodo donde se encuentra el fragmento.
- Una vez que el nodo recibe la solicitud, ingresa al proceso de lectura de un solo nodo.
- Este nodo devuelve los resultados de la consulta al nodo coordinador.
- El nodo de coordinación devuelve los resultados de la consulta al cliente.
El proceso de lectura de un solo nodo de Elasticsearch se muestra en la siguiente figura
La descripción del texto es la siguiente:
- El nodo recibe la solicitud de lectura de datos.
- Consulte los datos del caché de translog de acuerdo con el campo de identificación del documento en la solicitud. Si se consultan los datos, el resultado se devolverá directamente.
- Si no se encuentra ningún resultado en el paso 2, los datos se consultan desde el translog en el disco. Si se consultan los datos, el resultado se devuelve directamente.
- Si no se encuentra ningún resultado en el paso 3, los resultados se consultan desde cada segmento del disco. Si se encuentran los datos, los resultados se devuelven directamente.
- Después de los pasos anteriores, si no se encuentra ningún resultado, se devolverá nulo.
Tenga en cuenta que cuando Elasticsearch lee datos, primero intentará obtenerlos del translog y luego del segmento . Esto se debe a que, como mencionamos anteriormente, las operaciones de escritura/modificación/eliminación de todos los documentos se registrarán en el translog. primero. Luego se escribe en el segmento mediante operaciones de actualización y vaciado. Por lo tanto, los últimos datos del documento se registrarán en el translog. Por lo tanto, si los datos de destino se encuentran en el translog, simplemente devuélvalos directamente. Si no, intente obtener del segmento.
4.4.7 Explicación detallada del proceso de búsqueda
El proceso de búsqueda aquí se refiere a buscar , tenga cuidado de distinguirlo del proceso de lectura presentado anteriormente. El proceso de lectura se refiere a tomar el ID del documento para buscar datos a través del índice directo . El proceso de búsqueda está relacionado con el proceso de búsqueda y searchType .
El valor predeterminado de searchType es Consulta y luego Obtener
Puede entenderse brevemente como: primero obtenga la identificación del documento a través del índice invertido y luego busque los datos a través del índice directo según la identificación del documento.
Hay cuatro tipos de búsqueda, como se indica a continuación:
-
Consulta y recuperación
Las solicitudes de consulta se envían a todos los fragmentos del índice y, cuando regresa cada fragmento, el documento del elemento (documento) y la información de clasificación calculada se devuelven juntos.
Este método de búsqueda es el más rápido. Porque en comparación con los siguientes métodos de búsqueda, este método de consulta solo necesita consultar el fragmento una vez. Sin embargo, la suma del número de resultados devueltos por cada fragmento puede ser n veces el tamaño requerido por el usuario.
-
Consultar y luego recuperar (predeterminado)
Este modo de búsqueda es un proceso de dos pasos.
- Realice una solicitud a todos los fragmentos y cada fragmento devolverá solo información "suficiente" (se estima que está relacionada con la clasificación, la clasificación y la puntuación) (tenga en cuenta que el documento no está incluido) y luego lo reordenará y lo resumirá de acuerdo con la puntuación. devuelto por cada fragmento Clasificación, tome los documentos de primer tamaño.
- Vaya al fragmento correspondiente para obtener el documento. El documento devuelto de esta forma es igual al tamaño solicitado por el usuario.
-
Consulta y recuperación DFS
Este método tiene un paso de frase dispersa inicial más que el primer método. Con este paso, la precisión de la puntuación puede ser mayor.
-
Consulta DFS y luego recuperar
Este método tiene un paso de frase dispersa inicial más que el segundo método.
Generalmente, se puede utilizar el modo predeterminado.
A continuación, aprenderemos el proceso de búsqueda utilizando el modo Consulta y luego recuperación .
El proceso de búsqueda se divide en dos etapas, Consulta (etapa de consulta) y Fetch (etapa de obtención) .
-
Consulta
-
Una vez que el nodo de coordinación recibe la solicitud de búsqueda, la transmite a todos los fragmentos (incluidos los fragmentos primarios y los fragmentos de réplica).
-
Cada fragmento realiza la búsqueda de forma independiente, utiliza el índice invertido para realizar coincidencias y crea una cola de resultados priorizados (que incluye la identificación del documento y todos los valores de los campos involucrados en la clasificación, como _score).
En esta etapa, se consultará el caché de segmentos en el caché del sistema operativo . En este momento, es posible que algunos datos aún estén en la memoria, por lo que Elasticsearch es una búsqueda casi en tiempo real. (Puede consultar la introducción anterior para comprender)
-
Cada fragmento devuelve su cola de resultados priorizados al nodo coordinador.
-
El nodo de coordinación crea una nueva cola de resultados de clasificación por prioridad, clasifica los resultados globales y obtiene una lista de resultados de clasificación (incluidos todos los valores de campo ordenados y los ID de documentos).
-
Ingrese a la etapa de recuperación.
-
-
Buscar
- El nodo coordinador envía múltiples solicitudes GET a los fragmentos relevantes según la lista de resultados ordenados.
- Después de que cada fragmento recibe la solicitud GET, ejecuta el proceso de lectura descrito anteriormente, obtiene información detallada del documento según el ID del documento y la devuelve al nodo coordinador.
- El nodo coordinador devuelve los resultados al cliente.
referencia