Ejecutar conexiones de unión tipo SQL en un sistema distribuido como Elasticsearch es relativamente costoso, sin embargo, Elasticsearch nos proporciona dos formas de conexión basadas en la expansión horizontal. Esta oración está tomada del sitio web oficial de Elasticsearch.Desde la perspectiva de "sin embargo", muestra que aún podemos usarlo en ciertos escenarios y bajo ciertas circunstancias.
1. Resumen de unión
1. Analogía de relación
En las bases de datos relacionales, tome MySQL como ejemplo, especialmente en los sistemas del lado B donde la cantidad de datos no es particularmente grande, a menudo usamos la palabra clave join para realizar consultas asociadas en dos o más tablas relacionadas. Sin embargo, cuando la cantidad de datos alcanza cierto nivel, el rendimiento de las consultas suele ser un problema. Dado que es puede realizar cientos de millones de consultas por segundo (determinado por la cantidad de fragmentos), sincronizar datos con es es una de las soluciones que podemos usar.
Entonces no puedo evitar preguntar, debido a la decisión del escenario empresarial, ¿pueden asociarse las dos tablas que deben asociarse y consultarse antes?
La respuesta es sí, es también proporciona consultas asociadas similares a las bases de datos relacionales, pero tiene diferencias y limitaciones obvias con respecto a las consultas asociadas de datos relacionales.
2. Escenarios de uso
Si las dos tablas asociadas originalmente de la base de datos relacional se sincronizan con es, por lo general, habrá dos escenarios de demandas de consulta en nuestro desarrollo comercial
escena 1
Apelación: muestra los datos detallados de la dimensión de la tabla secundaria (incluidas las condiciones de los campos en la tabla principal y la tabla secundaria)
Solución: para este tipo de requisitos de consulta, podemos convertir la tabla padre-hijo asociada original en una tabla grande y ancha con los campos de la tabla padre-hijo mezclados, lo que no solo puede cumplir con las condiciones de la consulta, sino también garantizar la consulta. Rendimiento También es una de las soluciones de almacenamiento de uso común
escena 2
Apelación: muestra los datos detallados de la dimensión de la tabla principal (incluidas las condiciones de los campos en la tabla principal y la tabla secundaria)
Solución: Sin embargo, para este tipo de solicitud de consulta, los resultados detallados de la tabla principal deben consultarse a través de las condiciones de la tabla secundaria. La solución de almacenamiento de tabla ancha en el escenario 1 son los datos detallados de la tabla secundaria y lo que Lo que quiero al final son los datos detallados de la tabla principal.Obviamente, la solución de almacenamiento para el Escenario 1 no es satisfactoria. Si tenemos que usar el esquema de almacenamiento del Escenario 1, necesitamos realizar una operación de agrupación o colapso en los resultados de la tabla ancha para obtener los resultados de la tabla principal.
En este momento, podemos usar la función de unión proporcionada por es para completar la consulta de apelación del escenario 2, y también cumple con la consulta de apelación del escenario 1
3. Restricciones de uso
Dado que es es una base de datos de documentos distribuida, los datos existen naturalmente en múltiples fragmentos. Los campos de unión naturalmente no se pueden usar como uniones en bases de datos relacionales. Para garantizar un buen rendimiento de las consultas en es, la mejor práctica es configurar el modelo de datos como un documento desnormalizado y construir una tabla ancha a través de la redundancia de campos, es decir, almacenarla en un índice. Se deben cumplir las siguientes condiciones:
(1) Los documentos padre-hijo (datos) deben almacenarse en el mismo índice
(2) Los documentos padre-hijo (datos) deben almacenarse en el mismo fragmento y asociarse asociando el ID del documento principal
(3) Solo se puede incluir un campo de combinación en un índice, pero puede haber múltiples relaciones
(4) En el mismo índice, una relación principal puede corresponder a múltiples relaciones secundarias, y una relación secundaria solo puede corresponder a una relación principal
4. Problemas de rendimiento
Por supuesto, el rendimiento de la consulta de combinación se verá afectado hasta cierto punto. Con has_child/has_parent, el rendimiento de la consulta disminuirá a medida que aumente el número de documentos secundarios coincidentes que apuntan al documento principal único. La primera oración al comienzo de este artículo se tomó de la descripción del sitio web oficial de ES.De la descripción oficial de ES, se puede ver que la pérdida de rendimiento de la consulta de unión de asociación es relativamente grande.
Sin embargo, en el proceso de uso por parte del autor, bajo la premisa de 5 fragmentos, y la tabla principal es del orden de 100,000, y el volumen de datos de la tabla secundaria es del orden de decenas de millones, el tiempo que consume de la consulta asociada todavía se completa dentro de los 100 ms, todavía es aceptable para muchos escenarios en el lado B.
Si hay un escenario similar, se recomienda que hagamos una prueba de rendimiento por adelantado de acuerdo con la cantidad de fragmentos y el tamaño estimado del volumen de datos futuro antes de su uso, para evitar que el rendimiento disminuya significativamente cuando el número alcanza un cierto nivel en el futuro, y cambiar la solución de almacenamiento en ese momento no vale la pena perder. .
2. Mapeo
1. Ejemplos
Aquí tomamos la actividad del cupón y los detalles del cupón como ejemplo. Se pueden emitir decenas de millones de cupones en una actividad del cupón, por lo que existe una relación de uno a muchos entre la actividad del cupón y los detalles del cupón.
Campos de la tabla de actividades de cupones
| campo | ilustrar |
|---|---|
| actividad_id | ID de actividad |
| nombre de la actividad | Nombre del evento |
Campos de programación de cupones
| campo | ilustrar |
|---|---|
| cupón_id | ID de cupón |
| cupón_cantidad | Denominación del cupón |
| actividad_id | Clave foránea - ID de actividad |
2. Interpretación del mapeo
Los campos del tipo de combinación se utilizan principalmente para crear una relación padre-hijo en el mismo índice. Defina un conjunto de relaciones padre-hijo a través de relaciones, cada una de las cuales contiene un nombre de relación padre y uno o más nombres de relación hijo
activity_coupon_field es un campo asociado, que define un conjunto de relaciones de combinación internamente.
tipo especifica que la relación es unión, escritura fija
relaciones define la relación padre-hijo, el nombre del tipo de padre de la actividad, el nombre del subtipo de cupón, todos los nombres tienen su propio nombre
{
"mappings": {
"properties": {
"activity_coupon_field": {
"type": "join",
"relations": {
"activity": "coupon"
}
},
"activity_id": {
"type": "keyword"
},
"activity_name": {
"type": "keyword"
},
"coupon_id": {
"type": "long"
},
"coupon_amount": {
"type": "long"
}
}
}
}
3. Insertar datos
1. Inserte el documento principal
Al colocar los datos del documento principal, generalmente especificamos la ID del documento de acuerdo con ciertas reglas, de modo que sea fácil obtener la ID del documento principal cuando cambien los datos del documento secundario. Por ejemplo, aquí usamos el valor de activity_id: activity_100 como ID principal
PUT /coupon/_doc/activity_100
{
"activity_id": 100,
"activity_name": "年货节5元促销优惠券",
"activity_coupon_field": {
"name": "activity"
}
}
2. Insertar subdocumento
El ID del documento principal se especificó anteriormente y el ID_actividad ya está incluido en la tabla secundaria, por lo que es fácil obtener el ID del documento principal.
Al colocar los datos del subdocumento, debe especificar el ID del documento principal, que es el _id en el documento principal, para que los datos principal-secundario establezcan una relación. Al mismo tiempo, especifique el campo de enrutamiento como el ID del documento principal, lo que garantiza que los datos principales y secundarios estén en el mismo fragmento.
PUT /coupon/_doc/coupon_12345678?routing=activity_id_100
{
"coupon_id": 12345678,
"coupon_amount": "5",
"activity_id": 100,
"activity_coupon_field": {
"name": "coupon",
"parent": "activity_id_100" //父ID
}
}
4. Consulta de asociación
1. consulta has_parent (padre verifica hijo)
Consultar datos de subdocumentos calificados de acuerdo con el campo de condición del documento principal
Por ejemplo: consulta de cupones que contienen las palabras "Festival de Compras de Año Nuevo" y ya se han recibido
{
"query": {
"bool": {
"must": [{
"parent_type": "activity",
"has_parent": {
"query": {
"bool": {
"must": [{
"term": {
"status": {
"value": 1
}
}
}, {
"wildcard": {
"activity_name": {
"wildcard": "*年货节*"
}
}
}]
}
}
}
}]
}
}
}
2. consulta has_child (consulta secundaria principal)
Datos del documento principal que se califican en función del campo de condición del documento secundario
Por ejemplo: consulta id_cupón=12345678 en la que existe actividad de cupones
{
"query": {
"bool": {
"must": [{
"has_child": {
"type": "coupon",
"query": {
"bool": {
"must": [{
"term": {
"coupon_id": {
"value": 12345678
}
}
}]
}
}
}
}]
}
}
}
参考：Consultas de unión | Guía de búsqueda elástica [7.9] | Elástico
Si hay alguna inexactitud en el texto anterior, deje un mensaje para corregirlo.
Autor: JD Retail Li Zhenqian
Fuente de contenido: comunidad de desarrolladores de JD Cloud