Principios arquitectónicos de la búsqueda elástica del motor de búsqueda distribuido
Casi tiempo real tiene dos significados:
Un clúster contiene varios nodos y la configuración determina a qué clúster pertenece cada nodo.
El nodo es un nodo en el clúster. Los nodos también tienen nombres, que se asignan aleatoriamente de forma predeterminada. El nodo predeterminado se unirá a un clúster llamado elasticsearch. Si inicia un grupo de nodos directamente, automáticamente formarán un grupo de búsqueda elástica. Por supuesto, un nodo también puede formar un grupo de búsqueda elástica.
El documento es la unidad de datos más pequeña del sistema experto. Un documento puede contener 1 dato de cliente, 1 dato de categoría de producto y 1 dato de pedido, generalmente representados por una estructura de datos json. Se pueden almacenar varios documentos por tipo en el índice.
Hay varios campos en un documento, cada uno de los cuales es un campo de datos.
Cuando el clúster es tiene varios nodos, un nodo será elegido automáticamente como nodo maestro. Este nodo maestro en realidad realiza algún trabajo de administración, como mantener los metadatos del índice y cambiar las identidades de los fragmentos primarios y los fragmentos de réplica. Si el nodo maestro deja de funcionar, 1 nodo será reelegido como nodo maestro. Si falla un nodo no principal, el nodo principal transfiere la identidad del fragmento principal en el nodo fallido a un fragmento de réplica en otra máquina. Luego, si la máquina caída se repara y reinicia, el nodo maestro controlará la asignación de los fragmentos de réplica faltantes, sincronizará los datos modificados posteriormente, etc., y devolverá el clúster a la normalidad. Para decirlo de manera más simple, es 1, lo que significa que si un nodo no principal deja de funcionar, el fragmento principal de este nodo desaparecerá. Bien, el maestro cambiará el fragmento de réplica correspondiente al fragmento principal (en otras máquinas) al fragmento principal. Si se repara el fallo, el nodo reparado ya no es el fragmento principal, sino una réplica del fragmento.
Un índice se puede dividir en varios fragmentos, cada uno de los cuales almacena una parte de los datos. Dividirlo en varios fragmentos es beneficioso. En primer lugar, admite el escalado horizontal. Por ejemplo, si su volumen de datos es 3T y hay tres fragmentos, cada fragmento tendrá 1T de datos. Si el volumen de datos ahora aumenta a 4T, cómo expandirlo es muy simple. Reconstruya el índice 1 con cuatro fragmentos e importe los datos. El segundo es mejorar el rendimiento. Los datos se distribuyen en varios fragmentos, es decir, varios servidores, y todas las operaciones se ejecutan en paralelo y se distribuyen en varias máquinas, lo que mejora el rendimiento y el rendimiento. Entonces, los datos de este fragmento en realidad tienen múltiples copias de seguridad, lo que significa que cada fragmento tiene un fragmento principal, que es responsable de escribir los datos, pero también hay múltiples fragmentos de réplica. Después de que el fragmento principal escriba datos, los datos se sincronizarán con varios otros fragmentos de réplica.
Con este esquema de replicación, los datos de cada fragmento tienen múltiples copias de seguridad. Si una máquina se estropea, no importa. Hay otras copias de los datos en otras máquinas, por lo que están altamente disponibles.
Resumen: La distribución es de dos puntos, 1. La expansión horizontal se logra mediante fragmentación; 2. La alta disponibilidad se logra mediante el mecanismo de copia.
Conceptos básicos
Proceso de escritura de datos: El cliente selecciona un nodo para enviar la solicitud a través de hash. Este nodo se denomina nodo de coordinación. El nodo coordinador enruta el docmount y reenvía la solicitud al fragmento primario correspondiente, que maneja la solicitud y sincroniza los datos con todos los fragmentos de réplica. En este momento, el nodo coordinador informa al cliente después de descubrir que el fragmento principal y todos los fragmentos de réplica han sido procesados.
El cliente envía una solicitud de obtención a cualquier nodo, entonces este nodo se denomina nodo de coordinación. Coordina los nodos para enrutar documentos y reenviar solicitudes a los nodos apropiados. En este momento, se utilizará un algoritmo de sondeo aleatorio para seleccionar aleatoriamente uno de los fragmentos primarios y los fragmentos de réplica para que la carga de solicitudes de lectura esté equilibrada. El nodo que recibe la solicitud devuelve el documento al nodo coordinador, y el nodo coordinador. devuelve el documento al cliente.
Lo más poderoso de es es la búsqueda de texto completo, es decir, si tienes tres datos, por ejemplo.
1.java es muy divertido.
2.java es difícil de aprender.
3.j2ee es particularmente bueno
Busca según la palabra clave java para encontrar documentos que contengan java.
En el proceso de actualización/eliminación de datos, la primera son las operaciones de escritura y fusión, y luego el proceso de actualización:
1. El proceso de escritura es consistente con lo anterior;
2. El proceso de actualización es ligeramente diferente.
El llamado índice invertido consiste en dividir primero el contenido de sus datos en palabras, dividir cada oración en palabras clave una por una y luego registrar en qué datos marcados con identificación aparece cada palabra clave.
Luego podrás encontrar los datos correspondientes de otros lugares según esta identificación. Este es el formato de datos y el método de búsqueda del índice invertido. Este método de buscar datos a través de un índice invertido también se denomina recuperación de texto completo.
El índice invertido es nuestro índice invertido común, que consta principalmente de dos partes:
Diccionario de datos ordenados (incluida la palabra $Término y su frecuencia de aparición).
El registro correspondiente a la palabra $Term (es decir, el archivo donde se encuentra esta palabra)
Cuando buscamos, primero descomponemos el contenido de la búsqueda y luego encontramos el correspondiente en el diccionario $ Término para encontrar el contenido del archivo relevante para la búsqueda.
Esencialmente, un campo almacenado es un simple par clave-valor. De forma predeterminada, los campos almacenados son falsos y ElasticSearch almacena el código fuente JSON de todo el archivo.
¿Cuándo necesitas especificar explícitamente el atributo de la tienda? No es necesario en la mayoría de los casos. Obtener valores de _source es rápido y eficiente. Si su documento es largo y almacenar _source u obtener los campos de _source es costoso, puede establecer explícitamente el atributo de almacenamiento de algunos campos en sí. Las desventajas son las mencionadas anteriormente: suponga que almacena 10 campos, si desea obtener los valores de estos 10 campos, necesita varios IO para obtenerlos de los campos almacenados, solo se necesita uno y _source está comprimido.
En este momento, puede especificar que ciertos campos almacenados sean verdaderos, lo que significa que los datos de este campo se almacenarán por separado (en realidad hay dos copias, una para el campo de origen y otra para el campo de almacenamiento). ). En este momento, si la solicitud devuelve campo1 (tienda: Sí), es reconocerá que el campo1 se ha almacenado, por lo que no se cargará desde _source, sino desde el bloque de almacenamiento de campo1.
Doc_values es esencialmente un almacén de columnas serializadas. Esta estructura es muy adecuada para operaciones como agregación, clasificación y acceso a scripts. Y este método de almacenamiento también es muy conveniente para la compresión, especialmente para tipos numéricos. Esto reduce el espacio en disco y aumenta la velocidad de acceso. ElasticSearch puede leer todos los valores del documento en el índice en la memoria para su operación.
Los valores_doc existen en el disco.
En ES, solo se crearán índices invertidos para los campos de tipo texto de forma predeterminada. Para varios otros tipos, también se crearán índices directos cuando se creen índices invertidos. Por supuesto, es admite la personalización. Aquí, este índice ortogonal es en realidad el valor Doc.
Ese es el índice dinámico mencionado anteriormente.
Los datos escritos en es en realidad se escriben en el archivo del disco. Al realizar consultas, el sistema operativo almacena automáticamente en caché los datos del archivo del disco en la caché del sistema de archivos.
El motor de búsqueda de ES depende en gran medida del caché del sistema de archivos subyacente. Si almacena en caché más memoria para el sistema de archivos e intenta permitir que la memoria almacene todos los archivos de datos de índice de archivos de segmentos idx, entonces la memoria básicamente estará ocupada cuando realice la búsqueda y el rendimiento será muy alto. ¿Qué tan grande puede ser la brecha de desempeño? En muchas de nuestras pruebas y pruebas de estrés anteriores, si toma el disco, definitivamente son segundos y el rendimiento de la búsqueda es definitivamente segundos, 1 segundo, 5 segundos, 10 segundos. Pero si tomamos como ejemplo el caché del sistema de archivos y la memoria pura, el rendimiento es generalmente un orden de magnitud mayor que el del disco, básicamente en el nivel de milisegundos, desde unos pocos milisegundos hasta cientos de milisegundos.
Entonces, ¿cómo podemos ahorrar espacio en la caché del sistema de archivos?
Al escribir datos en ES, se debe considerar la minimización de datos. Cuando una fila de datos supera los 30 campos, no es necesario escribir todos los datos en ES, simplemente recupere las columnas clave requeridas. Cuantos más datos se puedan almacenar en caché. Por lo tanto, es mejor controlar que los datos escritos por cada máquina sean menores, iguales o ligeramente mayores que el espacio de caché del sistema de archivos. Si desea buscar datos masivos, puede considerar utilizar la arquitectura ES+Hbase.
Utilice Hbase para almacenar datos masivos y luego, después de que ES busque el ID del documento, va a Hbase para consultar los datos de la fila especificada según el ID del documento.
Cuando los datos escritos por cada máquina son mucho mayores que el sistema operativo de caché, de modo que no se pueden colocar demasiados datos en el caché, entonces algunos datos activos se pueden vaciar en el caché.
Para aquellos datos que cree que son activos y a los que se accede con frecuencia, es mejor crear un sistema especial de precalentamiento de caché, es decir, acceder a los datos activos con anticipación a intervalos regulares para permitir que los datos ingresen al archivo. caché del sistema. Así que la próxima vez que alguien venga de visita, el rendimiento definitivamente será mucho mejor.
Separe los datos activos y los datos fríos, escríbalos en índices diferentes y luego asegúrese de vaciar los datos del índice activo en la memoria caché.
En ES, es mejor no utilizar operaciones complejas de tablas de asociación. Cuando se necesita tal escenario, los datos se pueden asociar al crear el índice. Por ejemplo, en MySQL, debe consultar los datos relevantes de dos tablas según la ID relevante: seleccione a.name de una combinación b, b.age donde a.id = b.id, y coloque directamente los datos relevantes en un documento al escribir es Simplemente dale clic.
La paginación de ES es bastante complicada. ¿Por qué? Por ejemplo, si tiene 10 datos por página y ahora desea consultar la página número 100, encontrará que los primeros 1000 datos en realidad se almacenan en cada fragmento en 1 nodo de coordinación. Si tiene cinco fragmentos, habrá 5000 datos y luego el nodo coordinador trabajará en estos 5000 datos.
Distribuido, hay que comprobar 10 datos en 100 páginas. Es imposible decir que a partir de cinco fragmentos, cada fragmento verificará 2 datos y finalmente los fusionará en 10 datos en el nodo de coordinación, ¿verdad? Debe encontrar 1000 datos de cada fragmento, luego ordenar, filtrar, etc. según sus necesidades y finalmente paginar nuevamente para obtener 100 páginas de datos. Al pasar las páginas, cuanto más profundiza, más datos devuelve cada fragmento y más tiempo tarda el nodo de coordinación en procesarse, lo cual es muy engañoso. Entonces, cuando use es para paginar, encontrará que cuanto más retroceda, más lento se volverá.
Ya nos hemos encontrado con este problema antes. Cuando se utiliza la paginación ES, se necesitan decenas de milisegundos para las primeras páginas. Cuando se accede a 10 o docenas de páginas, básicamente se necesitan de 5 a 10 segundos para encontrar una página de datos.
¿Una solución?
1) Paginación sin profundidad: Dígale al gerente de producto que su sistema no permite pasar la página a tanta profundidad. De forma predeterminada, cuanto más profunda sea la página, peor será el rendimiento. ) En la aplicación o cuenta pública de WeChat, la paginación se logra mediante el menú desplegable, es decir, obtener la última página al desplegar, lo que se puede lograr a través de la API de desplazamiento
El desplazamiento generará una instantánea de; todos los datos para usted una vez, y luego cada vez que regrese a una página, moverá el cursor scroll_id para obtener la página siguiente. El rendimiento será mucho mayor que el rendimiento de paginación mencionado anteriormente, medido básicamente en milisegundos. Pero la desventaja de solo 1 es que es adecuado para escenarios como pasar de página desplegable en Weibo y no puede saltar a ninguna página a voluntad. En otras palabras, no puede avanzar a la página 10, luego a la página 120 y luego volver a la página 58. No puedes saltar de página a voluntad. Por lo tanto, muchos productos de aplicaciones ahora no le permiten pasar las páginas a voluntad, y también hay algunos sitios web donde solo puede desplazarse hacia abajo página por página.
Al inicializar, debe especificar el parámetro de desplazamiento para indicarle a ES cuánto tiempo guardar el contexto de esta búsqueda. Debe asegurarse de que los usuarios no sigan desplazándose durante horas, o podrían fallar debido a tiempos de espera.
Además de usar la API de desplazamiento, también puedes usar search_after. La idea de search_after es utilizar los resultados de la página anterior para ayudar a recuperar los datos de la página siguiente. Evidentemente, este método no permite pasar las páginas a voluntad, sino sólo una página a la vez. Al inicializar, debe utilizar un campo con solo 1 valor como campo de clasificación.