Reflexiones profundas sobre la entrevista de ES

1 artículo recomendado

20.000 palabras de explicación detallada para entender Elasticsearch a fondo

2 ¿Qué es un índice invertido y por qué se llama así?

El índice invertido es una estructura de datos diseñada para una búsqueda rápida de texto completo. Se utiliza ampliamente en motores de búsqueda, de los cuales Elasticsearch (ES para abreviar) es un usuario importante.

2.1 ¿Qué es un índice invertido?

Los índices tradicionales (como los de libros o los índices B-Tree de bases de datos) son "directos": se asignan desde "documentos hasta elementos de vocabulario". En otras palabras, busca un documento y luego enumera los elementos de vocabulario que contiene.

Por el contrario, el índice invertido asigna elementos de vocabulario a documentos. Esto significa que para cada elemento de vocabulario único en el índice, hay una lista de documentos relacionados que contienen ese elemento de vocabulario.

Por ejemplo, considere el siguiente conjunto de documentos simples:

1. Apple is tasty.
2. Banana is tasty.
3. Apple and banana are fruits.

Un índice invertido simple podría ser:

Apple -> 1, 3
Banana -> 2, 3
tasty -> 1, 2
...

2.2 ¿Por qué se llama “índice invertido”?

El nombre proviene de su oposición a la "indexación directa". Un índice directo asigna documentos directamente a los elementos de vocabulario que contienen, mientras que un índice invertido hace lo contrario: asigna elementos de vocabulario a los documentos que los contienen.

2.2 ¿Por qué utilizar índice invertido?

Los índices invertidos son particularmente útiles para búsquedas de texto completo porque:

1. Velocidad : permite encontrar rápidamente documentos que contengan elementos de vocabulario específicos.
2. Eficiencia espacial : mantenga índices únicamente para elementos de vocabulario únicos y asócielos con documentos relacionados, lo que evita la duplicación.
3. Clasificación y relevancia : utilizando el índice invertido, es fácil clasificar los resultados de búsqueda según la frecuencia de los términos, la frecuencia de los documentos, etc.

Como motor distribuido de búsqueda y análisis, Elasticsearch hace un uso extensivo de índices invertidos para lograr sus capacidades de búsqueda de texto eficientes y de alta velocidad.

3 Índice FST interno de ES

Para encontrar rápidamente un término, Elasticsearch primero clasifica todos los términos y luego busca el término según el método de dicotomía. La complejidad del tiempo es logN, como buscar en un diccionario: este es el diccionario de términos.

Ahora parece que es muy similar al árbol de prefijos y comparte prefijos, pero FST también puede compartir sufijos . Pero si hay demasiados términos, el diccionario de términos será muy grande y no será práctico almacenarlo en la memoria, por lo que tenemos el índice de términos.

Al igual que la página de índice de un diccionario, qué términos comienzan con A y en qué página se encuentran, se puede entender que el índice de términos es un árbol.

Este árbol no contiene todos los términos, contiene algunos prefijos de términos. A través del índice de términos, puede localizar rápidamente una compensación en el diccionario de términos y luego buscar secuencialmente desde esta posición.

Utilice el método FST para comprimir el índice de términos en la memoria. FST almacena todos los términos en bytes. Este método de compresión puede reducir efectivamente el espacio de almacenamiento y hacer que el índice de términos sea suficiente para caber en la memoria. Sin embargo, este método también causará la necesidad para buscar Más recursos de CPU.

La tecnología de compresión también se utiliza para tablas invertidas almacenadas en disco para reducir el espacio ocupado por el almacenamiento.

3.1 ¿Qué es FST en ES?

En Elasticsearch, FST (Finite State Transducer) es una estructura de datos que se utiliza para optimizar y comprimir el diccionario de términos. Es un tipo especial de máquina de estados finitos que puede representar no solo una clave (en el contexto de Elasticsearch, una clave suele ser un término o término), sino también el valor asociado con esa clave.

Aquí hay algunos puntos centrales sobre FST en Elasticsearch:

1. Compresión : FST es muy adecuado para comprimir diccionarios porque puede compartir prefijos y sufijos. Este método de compresión es muy eficaz teniendo en cuenta que muchos términos del vocabulario comparten prefijos y sufijos comunes.

2. Búsqueda rápida : además de las ventajas de almacenamiento, FST también ofrece capacidades de búsqueda rápida. Cuando un usuario consulta un término, Elasticsearch puede encontrar rápidamente los metadatos u otra información relacionada correspondiente al término a través de FST.

3. Almacenamiento de claves y valores : a diferencia de los árboles de prefijos tradicionales (trie), FST no solo almacena términos (claves) sino también los valores asociados a ellos. En Elasticsearch, estos valores pueden ser metadatos sobre el término, como su posición en el índice invertido.

4. Reducir el uso de memoria : debido a sus características de compresión, FST puede reducir en gran medida el uso de memoria del Diccionario de términos. Esto permite almacenar en caché más datos en la memoria, mejorando así el rendimiento de las consultas.

En resumen, en Elasticsearch, FST es una estructura de datos eficiente que se utiliza para representar y comprimir el Diccionario de términos, lo que hace que el almacenamiento del Diccionario de términos sea más eficiente y las consultas más rápidas.

3.2 Por qué el árbol de prefijos también es una máquina de estados finitos (FSM)

Para ser precisos, el árbol de prefijos (Trie) no es un FST (Transductor de estados finitos), pero todos pertenecen a la categoría de máquinas de estados finitos. FST es una extensión de máquinas de estados finitos que puede representar tanto claves como valores. Sin embargo, tanto Trie como FST son estructuras de datos basadas en máquinas de estados finitos, y ambas pueden representar efectivamente conjuntos de claves, lo que también es la similitud entre ellas.

Echemos un vistazo más de cerca a sus diferencias y conexiones:

1. Árbol de prefijos (Trie) :

   • Trie es una estructura de datos de árbol diseñada para almacenar una colección de cadenas.
   • Optimiza el espacio de almacenamiento al compartir un prefijo común.
   • Cada nodo representa un carácter y la ruta desde el nodo raíz hasta un nodo hoja representa una cadena.
   • Los intentos no almacenan directamente valores asociados con claves, pero los valores se pueden adjuntar a nodos hoja o a algunos nodos específicos.

2. Convertidor de estados finitos (FST) :

   • FST es una extensión de máquinas de estados finitos que puede representar transiciones (es decir, claves) entre estados y los valores de salida asociados con cada transición.
   • FST puede compartir no sólo prefijos sino también sufijos, comprimiendo aún más los datos.
   • En FST, un estado puede representar un prefijo o sufijo de una cadena, o una cadena completa.
   • FST representa el valor asociado con la clave directamente en su estructura.

Dado que FST puede compartir prefijos y sufijos y representar directamente claves y valores, es más flexible y eficiente que Trie, especialmente cuando representa grandes cantidades de datos.

En resumen, aunque Trie y FST son estructuras de datos basadas en máquinas de estados finitos y tienen las características de prefijos compartidos, FST proporciona más funciones y una mayor eficiencia de almacenamiento. En algunos contextos, como la implementación de Elasticsearch, se prefiere FST debido a sus capacidades de compresión y representación.

3.3 Diferencias entre árbol de prefijos y FST

FST y el árbol de prefijos (Trie) son similares en la estrategia de compartir prefijos. Ambos almacenan información estableciendo una ruta para cada carácter de la cadena. En esta estructura, las palabras con el mismo prefijo comparten rutas de almacenamiento hasta que sus caracteres comienzan a diferir.

Sin embargo, FST tiene las siguientes diferencias principales con respecto a los árboles de prefijos tradicionales:

1. Compartir sufijos : además de compartir prefijos, FST también intenta compartir sufijos. Esto significa que, a diferencia de un árbol de prefijos, que puede almacenar sufijos de palabras similares varias veces, FST intenta reutilizar y compartir estos sufijos, lo que reduce aún más el espacio de almacenamiento necesario.

2. Almacenamiento de valores : FST también puede almacenar valores asociados con claves. Esto permite que el FST se vea como un mapa clave-valor, donde la clave es el término y el valor puede ser cualquier dato relevante, como la posición del término en el índice invertido. En el contexto de Elasticsearch, estos suelen ser los metadatos del término.

3. Compresión : FST también emplea una variedad de técnicas de compresión para reducir los requisitos de almacenamiento reales.

En general, si bien FST y los árboles de prefijos son similares en la estrategia básica de compartir prefijos, FST incluye más optimizaciones y extensiones que lo hacen más eficiente en ciertas aplicaciones.

3.4 ¿Cómo logra FST compartir sufijos?

Analicemos en detalle el uso compartido de sufijos.

Los sufijos compartidos son más comunes en conjuntos de palabras complejos. Considere un conjunto de palabras más complejo, como por ejemplo: ["attempt", "attempts", "attempted", "attempting", "doing", "seated"].

En estas palabras vemos "attempt"que se comparten prefijos, pero también los sufijos "s", "ed"y "ing".

Para crear un FST que tenga en cuenta el uso compartido de sufijos:

1. Desde el estado inicial , primero nos conectamos a los caracteres a, luego a t,,,, en secuencia .temp
2. Hasta ahora hemos representado palabras "attempt".
3. Desde "attempt"el último carácter "t", podemos pasar a tres sufijos diferentes:
   • "s"expresar"attempts"
   • "ed"expresar"attempted"
   • "ing"expresar"attempting"
4. Al crear un nodo en el árbol para "hacer", el nodo d->o se creará en secuencia hasta el nivel inferior, y luego el puntero del nodo o apuntará al nodo ing en 3. En este momento, ing realiza el intercambio de sufijos.
5. De la misma forma se establecen cuatro niveles de nodos para las entradas sentadas, y ed directamente reutiliza el sufijo ya establecido en 3.

Cada sufijo se almacena solo una vez en el FST, lo que permite compartir sufijos.

Compartir prefijos y sufijos es clave para la eficiencia de FST. En conjuntos de datos reales, este intercambio puede comprimir en gran medida los requisitos de almacenamiento, especialmente cuando el conjunto de palabras contiene muchas variaciones y derivados.

Como se muestra en la figura siguiente, puede ver el método para compartir sufijos en el ejemplo anterior.

3 Utilice ES para encontrar el proceso

3.1 Primero descubra la estructura de datos principal de ES

3.2 Proceso de búsqueda utilizando ES como motor de búsqueda

Elasticsearch (ES) es un motor de búsqueda basado en la biblioteca Lucene. Cuando realiza una búsqueda en ES, pasa por los siguientes pasos principales:

1. Análisis de consultas :

   • El usuario emite una solicitud de consulta, normalmente una estructura JSON.
   • ES analiza esta solicitud y convierte la declaración de consulta a un formato interno adecuado para el procesamiento de Lucene.
   • Esto incluye analizar la cadena de consulta, identificar el tipo de consulta (por ejemplo match, term, rangeetc.) y otros posibles parámetros de consulta.

2. Análisis de texto :

   • Si la consulta implica una búsqueda de texto, se analiza el texto ingresado.
   • El analizador dividirá el texto en términos individuales, también llamados tokens, y puede realizar otras operaciones como poner minúsculas, eliminar palabras vacías o aplicar derivaciones.
   • Este proceso garantiza que los términos de la consulta y los términos del índice tengan el mismo formato.

3. Buscar diccionario de términos :

   • Para cada término, ES buscará primero en el Diccionario de términos para encontrar los metadatos y la información de ubicación del término. Por lo general, utiliza FST (transductor de estado finito) para optimizar la velocidad de búsqueda.

4. Búsqueda de índice invertido :

   • Una vez que se encuentra un término, ES consultará el índice invertido para encontrar todos los ID de documentos que contienen el término.
   • Para consultas de varios términos, ES hace esto para cada término y combina los resultados según el tipo de consulta (por ejemplo, consulta booleana).

5. Puntuación y clasificación :

   • Utilizando el algoritmo BM25 (predeterminado) u otros algoritmos de relevancia, ES calcula una puntuación para cada documento coincidente.
   • Esta puntuación representa la relevancia del documento para la consulta.
   • Todos los documentos coincidentes se clasifican según sus puntuaciones.

6. Obtener documentación :

   • ES recupera la versión completa del documento que coincide con la puntuación más alta del índice principal.
   • Se pueden devolver todos o parte de los campos según las necesidades de la consulta.

7. Resaltado y agregación (si se solicita):

   • Si la solicitud de consulta contiene instrucciones para resaltar, ES marcará la parte coincidente de la consulta.
   • Si la solicitud contiene agregación, ES calculará estadísticas basadas en los campos especificados y el tipo de agregación.

8. Resultados devueltos :

   • ES construye una respuesta JSON que contiene los documentos coincidentes, puntuaciones, posibles aspectos destacados y resultados de agregación y la devuelve al cliente.

Este es el proceso de búsqueda básico de ES. Por supuesto, las operaciones reales pueden implicar una mayor complejidad, como el procesamiento de fragmentación, consultas de múltiples nodos y fusión de resultados, aplicación de filtros, etc.

3.3.1 ¿Los motores de búsqueda de navegadores generales utilizan ES?

No. Los principales motores de búsqueda en navegadores como Google, Bing, Yahoo, etc. utilizan su propia tecnología de búsqueda patentada. Elasticsearch se utiliza normalmente para búsquedas en sitios web, análisis de registros, monitoreo de aplicaciones en tiempo real y otros escenarios, y no está diseñado para búsquedas web globales.

3.3.2 ¿El resultado devuelto por ES es la información de metadatos del documento correspondiente al docid? ¿O el contenido del documento?

Los resultados devueltos por ES pueden ser los metadatos del documento o el contenido real del documento. Al ejecutar una consulta de búsqueda, puede especificar qué campos deben devolverse como resultados. Si no se especifica, ES devolverá el documento completo de forma predeterminada.

3.3.3 ¿Qué es el algoritmo BM25 de ES?

BM25 es un algoritmo moderno de clasificación de documentos basado en probabilidades que se considera más eficiente que el método tradicional TF-IDF. BM25 considera la frecuencia de términos (TF) y la frecuencia inversa de documentos (IDF) para calcular la puntuación de relevancia de un documento, pero en comparación con TF-IDF, tiene un límite superior para términos de alta frecuencia, lo que puede evitar el uso excesivo de ciertos términos. Afecta la puntuación de relevancia del documento.

3.3.4 Obtención de documentos: ¿Cuál es el índice principal aquí?¿Cuál es la diferencia entre índice y FST?

Cuando nos referimos al "índice maestro" de Elasticsearch, nos referimos a la estructura de datos en la que se almacenan los documentos , similar a la forma en que están los nodos de índice en el sistema operativo. El nodo de índice maestro solo almacena la información de metadatos del documento y un puntero. a la ubicación del documento . Aquí, los documentos se almacenan y recuperan por su identificación. FST es una estructura de datos que se utiliza para almacenar y buscar términos en un vocabulario. En pocas palabras, el índice principal se centra en el documento completo, mientras que el FST se centra en los términos del documento.

3.3.5 ¿Por qué solo se devuelve el campo departamento?¿Qué contiene el campo aquí?

En algunos escenarios, para mejorar la eficiencia y reducir la transmisión de la red, es posible que solo le interesen ciertos campos del documento en lugar de todo el documento. Por ejemplo, si su documento es un perfil de usuario con múltiples campos, pero solo desea el nombre y la dirección de correo electrónico, puede especificar que solo se devuelvan esos dos campos. Al consultar ES, puede utilizar el parámetro "_source" para especificar qué campos devolver. "Campo" aquí se refiere a cualquier atributo dentro del documento, como título, autor, fecha de publicación, etc.

4. ¿Los motores de búsqueda de navegadores generales utilizan ES?

No. Los principales motores de búsqueda en navegadores como Google, Bing, Yahoo, etc. utilizan su propia tecnología de búsqueda patentada. Elasticsearch se utiliza normalmente para búsquedas en sitios web, análisis de registros, monitoreo de aplicaciones en tiempo real y otros escenarios, y no está diseñado para búsquedas web globales.

5 Por qué ES es casi en tiempo real

Por qué ES es casi en tiempo real

6 Cómo utilizar ES

¿Cómo se utiliza ElasticSearch en el proyecto?

6.1 ¿Debería construirse Elasticsearch como un proyecto separado y usarse como una búsqueda de texto completo, o debería usarse directamente en el proyecto?

Depende de tus necesidades y de la complejidad del proyecto. Muchas empresas y proyectos optan por ejecutar Elasticsearch como un servicio o microservicio independiente, independiente de la aplicación principal. El beneficio de esto es que se puede ampliar, mantener y actualizar independientemente de la aplicación principal, logrando así el desacoplamiento. Pero si su aplicación es más pequeña o simplemente desea crear un prototipo rápidamente, puede integrar Elasticsearch directamente en la aplicación.

6.2 Al agregar nuevos datos, ¿es necesario insertarlos en es al mismo tiempo que se insertan en mysql?

Si confía en Elasticsearch para búsquedas u otras operaciones que requieren lecturas rápidas, cuando inserte datos en MySQL, también debe insertar esos datos en Elasticsearch. De esta manera, se asegura de que el índice de Elasticsearch esté actualizado cuando los usuarios intenten buscar contenido recién agregado. Hay varias formas de hacerlo, como utilizar la sincronización de archivos de registro o utilizar herramientas y bibliotecas como Logstash o Debezium.

Cuando agrega nuevos datos a MySQL y desea que se puedan buscar en Elasticsearch, debe asegurarse de que los datos también estén sincronizados con Elasticsearch. Existen varios métodos comunes para activar la sincronización de datos:

1. Escrituras dobles iniciadas por el cliente : después de que la aplicación (cliente) inserta datos en MySQL, también puede ser responsable de enviar los mismos datos a Elasticsearch. El desafío de este enfoque es garantizar que las escrituras en ambos lados sean exitosas; de lo contrario, pueden ocurrir inconsistencias en los datos.

2. Monitoreo y sincronización de binlog de MySQL : utilice herramientas como Debezium o Logstash para monitorear el binlog (registro binario) de MySQL. Cuando se detectan nuevos cambios en los datos, los cambios se envían automáticamente a Elasticsearch. Este método es más confiable que la doble escritura del lado del cliente porque garantiza que los datos se puedan sincronizar correctamente incluso si hay un problema con la aplicación.

3. Sincronización periódica de datos : establezca una tarea programada, como verificar MySQL en busca de datos nuevos cada pocos minutos y sincronizarlos con Elasticsearch. Esto es adecuado para escenarios donde los requisitos de datos en tiempo real no son altos.

4. Activadores : configure activadores en MySQL para activar ciertas operaciones de sincronización cuando se insertan o modifican nuevos datos. Pero este método puede afectar el rendimiento de MySQL y requiere trabajo adicional para garantizar una sincronización exitosa.

En general, el método a elegir depende de sus necesidades específicas y de la arquitectura de su sistema. Pero, por lo general, el método de monitoreo de binlog se adopta ampliamente debido a su relativa confiabilidad y baja latencia.

6.3 Al realizar una búsqueda, ¿devuelve directamente los resultados de búsqueda de es o necesita volver a mysql y verificar nuevamente según la identificación en los resultados de es?

Nuevamente, esto depende de su aplicación y necesidades. En algunos escenarios, es posible que los usuarios solo necesiten metadatos obtenidos de Elasticsearch, por lo que devolver los resultados de Elasticsearch directamente es suficiente. En otros casos, es posible que sea necesario devolver información más detallada y el ID proporcionado por Elasticsearch se puede utilizar para buscarlo en MySQL.

Acerca del uso de MySQL: Elasticsearch está diseñado principalmente para búsqueda y análisis y no pretende reemplazar las bases de datos relacionales tradicionales. MySQL (u otro RDBMS) proporciona funciones transaccionales, de integridad, de respaldo y de recuperación en las que Elasticsearch no es bueno o no admite. Elasticsearch está dirigido principalmente a la búsqueda y análisis rápidos de grandes cantidades de datos. Entonces, en términos generales, MySQL se utiliza como almacén de datos principal, mientras que Elasticsearch se utiliza como herramienta de búsqueda y análisis.

7 escenarios de aplicación de ES en el sistema de venta flash

7.1 ¿Qué parte de mi sistema de venta flash puede utilizar este ES?

Elasticsearch (ES) se utiliza principalmente para buscar y analizar grandes cantidades de datos. En un sistema de venta flash, dicha funcionalidad puede no ser fundamental, pero todavía hay algunos lugares que pueden beneficiarse de ES:

1. Búsqueda de productos : si su sistema de venta flash tiene una gran cantidad de productos o múltiples actividades de venta flash, ES puede ayudar a los usuarios a encontrar rápidamente los productos que les interesan. Los usuarios pueden buscar eficientemente por palabras clave, marcas, categorías, etc.

2. Análisis de registros : los sistemas de venta flash suelen enfrentarse a un tráfico enorme. Con ES, puede realizar análisis en tiempo real de los registros del sistema y descubrir rápidamente cualquier problema, cuello de botella o ataque potencial.

3. Análisis del comportamiento del usuario : al enviar datos de comportamiento de navegación, clics y compras de los usuarios a ES, puede realizar un análisis en profundidad para comprender los intereses y patrones de comportamiento de los usuarios y optimizar la estrategia de las actividades de venta flash en consecuencia.

4. Monitoreo de inventario : aunque MySQL u otras bases de datos relacionales son la primera opción para administrar el inventario, cuando se enfrenta a un tráfico enorme, ES puede brindarle una instantánea casi en tiempo real del estado del inventario, ayudándolo a monitorear y ajustar las estrategias.

5. Sistema de recomendación : Basado en el historial de búsqueda y compras del usuario, ES puede ayudarlo a implementar un sistema de recomendación básico para recomendar productos que puedan ser de interés para el usuario.

6. Sistema de alarma : puede establecer ciertos umbrales o patrones en ES y enviar alertas cuando se alcancen estas condiciones. Por ejemplo, cuando el inventario de un artículo cae por debajo de cierta cantidad o cuando se detecta tráfico anormal.

No obstante, para las funciones principales de un sistema de venta flash, como la reducción de inventario, el procesamiento de pedidos, etc., es más adecuada una base de datos relacional tradicional o una solución distribuida específica. El principal valor de ES son las capacidades de búsqueda y análisis que proporciona.

7.2 Cómo utilizar ES para implementar la función de búsqueda de productos

7.2.1 Si quiero implementar esta función en mi sistema personal de venta flash, ¿cómo debo usarla?

Para implementar la función de búsqueda de productos en el sistema de venta flash y utilizar Elasticsearch (ES), puedes seguir los siguientes pasos:

a.Sincronización de datos :

Cuando se agregan nuevos productos a la actividad de venta flash (generalmente almacenada en MySQL), estos datos de productos se sincronizan con Elasticsearch al mismo tiempo. Puede utilizar herramientas como Logstash, Debezium, etc. para sincronizar datos de MySQL a Elasticsearch, o escribir datos en ambos al mismo tiempo en el código de su capa de aplicación.

b. Diseño de estructura de datos :

En Elasticsearch, debe definir una estructura de índice adecuada para los datos del producto, considerar qué campos deben indexarse, qué campos pueden usarse para filtrar, etc.

c.Interfaz de búsqueda :

En su sistema de venta flash, proporcione a los usuarios una interfaz de búsqueda. Cuando un usuario ingresa una palabra clave e inicia una solicitud de búsqueda, su sistema debe iniciar una consulta a Elasticsearch y devolver los resultados de la búsqueda al usuario.

7.2.2 En este sistema, ¿cuál es la relación entre ES, mysql y redis, y cuál es el flujo de datos entre los tres?

1a. MySQL :

• Función principal : almacenar datos básicos, como información del producto, información del usuario, datos de pedidos, etc.
• Relación con Elasticsearch : Como principal fuente de datos, los datos de productos nuevos o actualizados se sincronizan desde MySQL con Elasticsearch.

2b. Búsqueda elástica (ES) :

• Función principal : Proporciona una función de búsqueda de productos de texto completo y de alta velocidad.
• Flujo de datos :
  • Desde MySQL : los datos de productos nuevos o actualizados se sincronizan con ES.
  • Al frente : cuando el usuario inicia una solicitud de búsqueda, el sistema consulta ES y devuelve los resultados al usuario.

3c. Redis :

• Función principal : debido a las características de alta concurrencia de las actividades de venta flash, Redis se usa a menudo para funciones como almacenamiento en caché, recuento de inventario y limitación de corriente.
• Relación con MySQL : el inventario de productos, los registros de compras de los usuarios, etc. se pueden almacenar en caché en Redis para proporcionar velocidades de lectura y escritura más rápidas. Cuando el inventario cambia, como por ejemplo, la venta flash es exitosa, los datos pueden escribirse primero en Redis y sincronizarse nuevamente con MySQL en el momento apropiado.
• Relación con Elasticsearch : Por lo general, no existe una interacción directa de datos entre los dos. Sin embargo, en algunos escenarios, como la recomendación de productos en tiempo real basada en el comportamiento del usuario, los datos del comportamiento del usuario en Redis se pueden utilizar para consultar Elasticsearch.

4 Resumen:

• Cuando se agregan nuevos productos: Aplicación -> MySQL -> Elasticsearch.
• Cuando un usuario busca: Aplicar consulta -> Elasticsearch -> Aplicar devuelve resultados al usuario.
• Venta flash u operación de alta concurrencia: Aplicación -> Redis -> (sincronización retrasada o por lotes) -> MySQL.

Esta arquitectura permite que cada tecnología aproveche sus mejores fortalezas al tiempo que garantiza la integridad de los datos y la alta disponibilidad del sistema.

7.3 Cuando se agregan nuevos productos a la actividad de venta flash (generalmente almacenados en MySQL), estos datos de productos se sincronizan con Elasticsearch al mismo tiempo. Si la actualización del inventario en la base de datos es exitosa, pero la actualización de ES falla, ¿qué se debe hacer? ?

Cuando las actualizaciones de MySQL tienen éxito pero las actualizaciones de Elasticsearch fallan, este es un problema típico de coherencia de datos del sistema distribuido. A continuación se muestran algunas estrategias de resolución de uso común:

• Mecanismo de reintento : si el error se debe a problemas temporales de red u otros motivos transitorios, simplemente puede volver a intentar actualizar Elasticsearch.
• Registro : registre todas las operaciones de actualización fallidas para que los administradores puedan intervenir o reprocesar manualmente estas operaciones fallidas mediante scripts.
• Utilice una cola : coloque la operación de actualización en una cola de mensajes, como RabbitMQ o Kafka. El consumidor saca la operación de la cola e intenta actualizar Elasticsearch. Si falla, puedes volver a ponerlo en la cola y volver a intentarlo más tarde.

7.4 En Elasticsearch, debe definir una estructura de índice adecuada para los datos del producto, considerar qué campos deben indexarse, qué campos pueden usarse para filtrar, etc. ¿Puedes ayudarme a diseñar una estructura de índice?

{
    
    
  "mappings": {
    
    
    "properties": {
    
    
      "product_id": {
    
    
        "type": "keyword"
      },
      "product_name": {
    
    
        "type": "text",
        "analyzer": "standard"
      },
      "description": {
    
    
        "type": "text",
        "analyzer": "standard"
      },
      "price": {
    
    
        "type": "float"
      },
      "stock": {
    
    
        "type": "integer"
      },
      "category": {
    
    
        "type": "keyword"
      },
      "brand": {
    
    
        "type": "keyword"
      },
      "tags": {
    
    
        "type": "keyword"
      },
      "created_at": {
    
    
        "type": "date"
      }
    }
  }
}

7.4.1 Sí, los campos marcados con "type": "text"y "analyzer": "standard"serán analizados en Elasticsearch y generarán términos (Terms). El analizador "estándar" realiza una serie de pasos de procesamiento en el texto, incluida la segmentación de palabras, la conversión de minúsculas y la eliminación de algunos signos de puntuación comunes.

Por ejemplo, supongamos que hay un campo con el valor "¡ElasticSearch es excelente!" Utilizando el analizador "estándar", este texto podría dividirse en tres términos elasticsearch: isy great.

Cuando utilizamos estos términos durante la búsqueda, Elasticsearch utilizará estos términos generados para hacer coincidir, implementando así la función de búsqueda de texto.

Además, los "type": "keyword"campos marcados como , no se analizan, sino que se almacenan e indexan en su conjunto. Esto significa que los valores de estos campos se tratarán como una entrada única, lo cual es adecuado para campos que no requieren segmentación de palabras, como etiquetas, categorías, etc.

7.5 Problemas con consultas de aplicaciones:

De hecho, lo que se devuelve de las consultas de Elasticsearch es una cadena JSON estructurada. Hay varias razones para utilizar un servidor empresarial como nivel medio para realizar consultas:

• Seguridad : permitir que el front-end se comunique directamente con Elasticsearch puede exponer los detalles de Elasticsearch, que pueden ser aprovechados por usuarios malintencionados.
• Flexibilidad : la lógica de consulta se puede cambiar o mejorar fácilmente utilizando un servidor empresarial como nivel intermedio.
• Equilibrio de carga y almacenamiento en caché : el servidor empresarial puede realizar el almacenamiento en caché de resultados de consultas, equilibrio de carga y otras optimizaciones.

7.6 Ejemplo de servidor empresarial que envía una solicitud ES:

Usando la biblioteca cliente Elasticsearch de Java como ejemplo:

import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.client.RestClient;
import org.elasticsearch.client.indices.CreateIndexRequest;
import org.elasticsearch.action.index.IndexRequest;
import org.elasticsearch.action.search.SearchRequest;
import org.elasticsearch.action.search.SearchResponse;
import org.elasticsearch.action.delete.DeleteRequest;
import org.elasticsearch.index.query.QueryBuilders;
import org.elasticsearch.search.builder.SearchSourceBuilder;

public class ESExample {
    
    
    public static void main(String[] args) throws IOException {
    
    
        // 创建Elasticsearch客户端
        RestHighLevelClient client = new RestHighLevelClient(
                RestClient.builder(
                        new HttpHost("localhost", 9200, "http")));

        // 插入数据
        IndexRequest indexRequest = new IndexRequest("products");
        indexRequest.id("1");
        String jsonString = "{" +
                "\"product_name\":\"电视\"," +
                "\"price\":2999.99," +
                "\"stock\":100" +
                "}";
        indexRequest.source(jsonString, XContentType.JSON);
        client.index(indexRequest, RequestOptions.DEFAULT);

        // 查询数据
        SearchRequest searchRequest = new SearchRequest("products");
        SearchSourceBuilder searchSourceBuilder = new SearchSourceBuilder();
        searchSourceBuilder.query(QueryBuilders.matchQuery("product_name", "电视"));
        searchRequest.source(searchSourceBuilder);
        SearchResponse searchResponse = client.search(searchRequest, RequestOptions.DEFAULT);
        searchResponse.getHits().forEach(hit -> System.out.println(hit.getSourceAsString()));

        // 删除数据
        DeleteRequest deleteRequest = new DeleteRequest("products", "1");
        client.delete(deleteRequest, RequestOptions.DEFAULT);

        client.close();
    }
}

En este ejemplo, primero nos conectamos al servicio Elasticsearch, luego creamos una consulta de coincidencia simple para buscar productos que contengan "TV" en el nombre del producto y, finalmente, imprimimos los datos de origen para cada producto exitoso.

7.6.1 Si quiero insertar varios productos de este tipo, ¿debo agregarlos en productos?

Sí, si desea insertar varios productos, agregará productsvarios documentos bajo el mismo índice. Cada documento tiene un ID único, que en este ejemplo está codificado en "1". Pero en realidad, cada artículo debe tener una identificación única para que usted pueda identificarlo y hacer referencia a él de manera única.

Si desea insertar varios elementos por lotes, puede utilizar Elasticsearch BulkRequestpara realizar varias operaciones a la vez, lo que suele ser más eficiente que enviar cada solicitud individualmente.

A continuación se muestra un ejemplo de una inserción masiva:

BulkRequest bulkRequest = new BulkRequest();

// 第一个商品
IndexRequest firstProduct = new IndexRequest("products");
firstProduct.id("1");
String firstProductJson = "{" +
        "\"product_name\":\"电视\"," +
        "\"price\":2999.99," +
        "\"stock\":100" +
        "}";
firstProduct.source(firstProductJson, XContentType.JSON);
bulkRequest.add(firstProduct);

// 第二个商品
IndexRequest secondProduct = new IndexRequest("products");
secondProduct.id("2");
String secondProductJson = "{" +
        "\"product_name\":\"冰箱\"," +
        "\"price\":3999.99," +
        "\"stock\":50" +
        "}";
secondProduct.source(secondProductJson, XContentType.JSON);
bulkRequest.add(secondProduct);

// ... 添加更多的商品

client.bulk(bulkRequest, RequestOptions.DEFAULT);

De esta manera, todos los elementos se almacenarán en productsel índice y cada elemento tendrá su ID única. Cuando consulta productsel índice, obtiene todos los elementos almacenados en él.

7.6.2 Los productos aquí son equivalentes a espacios de nombres. Cada espacio tiene un FST. Todos los campos marcados como texto y palabra clave en este espacio formarán parte del FST. ¿Es esto cierto?

Casi, pero hay algunos detalles que es necesario aclarar:

1. Índice : en Elasticsearch, productses un índice , no solo un espacio de nombres. Este índice contiene asignaciones (que definen los tipos de datos y otras propiedades de los campos) y datos de documentos.

2. FST : FST (Finite State Transformer) es una estructura de datos utilizada por Elasticsearch para comprimir y almacenar términos, utilizada principalmente en diccionarios de términos . Pero no todos los campos tendrán un FST. Sólo los campos indexados (como los marcados con texto keyword) tendrán entradas en el diccionario de términos, por lo que pueden usar FST.

3. Tipos de mapeo : en versiones anteriores de Elasticsearch, un índice podía tener múltiples tipos de mapeo, lo que permitía que el mismo índice almacenara documentos con diferentes estructuras. Pero a partir de Elasticsearch 7.0, los índices solo pueden tener un tipo de mapeo, lo que hace que el uso del índice sea más simple e intuitivo.

4. Campos y FST : para textcampos de tipo, Elasticsearch los dividirá en palabras y los almacenará en el diccionario de términos. Estos términos se utilizan para construir el FST. Para keywordcampos de tipo, el valor completo del campo se trata como un único término y se almacena en el diccionario de términos.

5. Múltiples campos : a veces es posible que desee indexar un campo como text(para segmentación de palabras y búsqueda) y como (para agregación o coincidencia exacta). keywordElasticsearch le permite hacer esto a través de los llamados "campos múltiples". Por ejemplo, un campo puede considerarse principalmente text, pero también puede tener un keywordsubcampo.

En resumen, los campos productsmarcados como texty en el índice keywordse agregarán al diccionario de términos, y este diccionario se puede comprimir y almacenar usando FST.

7.6 ¿Qué método de sincronización de MySQL a ES utilizan actualmente los principales fabricantes? Hablemos del proceso de sincronización específico.

Cuando las grandes empresas ("grandes empresas") eligen el método de sincronización de MySQL a Elasticsearch, generalmente toman una decisión en función de sus propias necesidades comerciales, la pila de tecnología existente y los requisitos de estabilidad de datos/tiempo real. A continuación se muestran algunos métodos de sincronización comunes y las razones por las que las empresas más grandes podrían adoptarlos:

1. Complemento JDBC para Logstash :

   • Ventajas : Configuración simple, fácil de iniciar, sin necesidad de un trabajo de desarrollo extenso.
   • Desventajas : Puede que no sea adecuado para necesidades de sincronización en tiempo real porque generalmente se basa en encuestas.
   • Escenarios aplicables : las empresas que no tienen altos requisitos para la sincronización de datos en tiempo real o que inicialmente están probando Elasticsearch pueden elegir este método.

2. Debezium y Kafka :

   • Ventajas : Basado en CDC (Change Data Capture), los cambios en la base de datos se pueden capturar en tiempo real y, combinados con Kafka, pueden garantizar una alta confiabilidad y escalabilidad de los datos.
   • Desventajas : Requiere componentes adicionales (como Kafka) y trabajo de configuración, y puede requerir más esfuerzos operativos.
   • Escenarios aplicables : las empresas que tienen requisitos de sincronización de datos en tiempo real y ya tienen una infraestructura Kafka pueden elegir este método.

3. Conexión Kafka :

   • Ventajas : Al igual que Debezium, Kafka Connect también se basa en CDC, pero es un componente oficial de Kafka y está más estrechamente integrado con Kafka.
   • Desventajas : También requiere infraestructura Kafka.
   • Escenarios aplicables : las empresas que ya utilizan Kafka y desean simplificar aún más la integración pueden considerar este enfoque.

4. Herramientas de sincronización personalizadas :

   • Ventajas : Completamente personalizado según las necesidades específicas de la empresa, el proceso de sincronización se puede optimizar en profundidad.
   • Desventajas : Altos costos de desarrollo y mantenimiento.
   • Escenarios aplicables : las empresas con necesidades de sincronización específicas o que esperan una integración profunda pueden desarrollar sus propias herramientas de sincronización.

En general, diferentes empresas pueden elegir diferentes métodos según sus propios escenarios comerciales y antecedentes técnicos. Por ejemplo, las empresas que ya utilizan Kafka a escala podrían elegir Debezium o Kafka Connect. Las empresas que no tienen altos requisitos en tiempo real o desean experimentar rápidamente pueden probar primero el complemento JDBC de Logstash.

En las grandes empresas de Internet, debido a que el tiempo real y la estabilidad de los datos son críticos, los métodos basados ​​en CDC (como Debezium y Kafka Connect) son más populares. Pero al mismo tiempo, algunas grandes empresas también pueden desarrollar herramientas de sincronización personalizadas para sus necesidades específicas.

7.7 Para el sistema de venta flash, ¿son altos los requisitos de datos en tiempo real?

Para el sistema de venta flash, los requisitos de datos en tiempo real son muy altos. Las actividades de venta flash generalmente implican prisa por comprar cantidades limitadas de productos en un tiempo limitado, por lo que los requisitos de tiempo real en varios aspectos clave son particularmente importantes:

1. Inventario en tiempo real : en las actividades de venta flash, la cantidad de bienes en el inventario es muy crítica. Si el sistema no puede actualizar y retroalimentar la información del inventario en tiempo real, puede provocar una sobreventa (es decir, la cantidad real vendida excede el inventario). La sobreventa no sólo puede generar devoluciones de cargo y una reducción de la satisfacción del cliente, sino que también puede enfrentar riesgos legales.

2. Procesamiento de pedidos en tiempo real : una vez que el usuario hace clic en el botón "Comprar", el sistema debe procesar inmediatamente el pedido y confirmar si se puede completar la transacción. Cualquier retraso puede resultar en una experiencia de usuario degradada e incluso puede provocar una falla del sistema.

3. Comentarios de los usuarios en tiempo real : durante las actividades de venta flash, los usuarios siempre quieren saber en tiempo real si han adquirido el producto con éxito. Cualquier retraso o información engañosa puede provocar la insatisfacción del usuario.

4. Monitoreo y ajuste del tráfico : dado que las actividades de venta flash generalmente generan una gran cantidad de tráfico, el sistema necesita monitorear las condiciones del tráfico en tiempo real y poder realizar ajustes rápidos para hacer frente a posibles picos de tráfico.

5. Notificaciones y mensajes en tiempo real : los usuarios deben recibir notificaciones en tiempo real sobre el inicio de las actividades de venta flash, cambios de inventario u otra información relacionada para garantizar que no se pierdan ningún momento clave.

Teniendo en cuenta los requisitos en tiempo real mencionados anteriormente, los sistemas de venta flash generalmente necesitan adoptar soluciones técnicas de alto rendimiento y baja latencia, y están diseñados teniendo en mente una alta concurrencia y alta disponibilidad.

7.8 ¿Cómo Kafka Connect realiza la sincronización de datos de MySQL a ES (sincronización de productos en el sistema de venta flash)?

Kafka Connect es una herramienta extensible para importar datos de diferentes sistemas de origen a Apache Kafka y exportar datos de Kafka a los sistemas de destino. Para lograr la sincronización de datos de MySQL a Elasticsearch, puede usar Kafka Connect con un conector específico (Conector). El siguiente es el proceso general de pasos de implementación:

1. Utilice el conector Debezium para MySQL :

   • Debezium es una herramienta CDC (Captura de datos de cambios) de código abierto que puede capturar y monitorear eventos de cambios en la base de datos.
   • Para MySQL, Debezium escucha su binlog para capturar cambios de datos y publica estos eventos de cambio en el tema de Kafka.

2. Descripción del conector Kafka Connect Elasticsearch :

   • Kafka Connect tiene un conector oficial de Elasticsearch, que puede consumir datos de temas de Kafka y escribir en Elasticsearch.

3. Pasos :

   a. Configure Debezium Connector para MySQL :

   • Asegúrese de que la función binlog de MySQL esté activada.
   • Configure Debezium y especifique los parámetros relacionados con MySQL.
   • Inicie Debezium Connector, momento en el que comenzará a escuchar MySQL en busca de cambios de datos y los enviará al tema de Kafka especificado.

   b.设置 Conector Kafka Connect Elasticsearch :

   • Configure el conector y especifique los parámetros relacionados con Elasticsearch, como la dirección, el nombre del índice, etc.
   • Especifique de qué tema de Kafka leer datos.
   • Inicie Elasticsearch Connector, que obtendrá datos del tema de Kafka especificado y los escribirá en Elasticsearch.

4. Operación :

   • Una vez configurados los pasos anteriores, Debezium capturará cualquier cambio de datos que realice en MySQL (como inserciones, actualizaciones o eliminaciones) y lo enviará a Elasticsearch a través de Kafka.

5. Cosas a tener en cuenta :

   • Asegúrese de que el clúster de Kafka tenga suficientes recursos y capacidad para manejar los cambios de datos capturados desde MySQL.
   • Considere estrategias de partición y replicación para temas de Kafka para garantizar una alta disponibilidad y durabilidad de los datos.
   • En un entorno de producción, es posible que deba considerar la transformación de datos, el filtrado u otra lógica, que se puede procesar utilizando la API Transform de Kafka Connect.

El uso de Kafka Connect para la sincronización de datos de MySQL a Elasticsearch no solo garantiza la naturaleza en tiempo real de los datos, sino que también utiliza Kafka como un búfer para reducir la presión del sistema y garantizar la confiabilidad de los datos.

7.9 Utilice el canal de productos de sincronización de datos de código abierto de Alibaba para actualizar la práctica de datos mysql en ES.

¿Cómo sincroniza MySQL los datos con ES en tiempo real? ¡Pruebe este artefacto de código abierto de Alibaba!