tutorial - Asignaciones de relaciones de Elasticsearch(uno a uno y uno a muchos)

puertos elasticsearch

Question

En mi servidor de búsqueda elástica tengo un índice http://localhost:9200/blog .
El índice (blog) contiene múltiples tipos.

por ejemplo: http://localhost:9200/blog/posts , http://localhost:9200/blog/tags .

En el tipo de etiquetas, he creado más de 1000 etiquetas y 10 publicaciones creadas en el tipo de publicaciones.

por ejemplo: mensajes

{
"_index":"blog",
"_type":"posts",
"_id":"1",
"_version":3,
"found":true,
"_source" : {
"catalogId" : "1",
"name" : "cricket",
"url" : "http://www.wikipedia/cricket"
}
}

por ejemplo: etiquetas

{
"_index":"blog",
"_type":"tags",
"_id":"1",
"_version":3,
"found":true,
"_source" : {
"tagId" : "1",
"name" : "game"
}
}

Quiero asignar la etiqueta existente a las publicaciones de blog (es decir, relación => mapeo).

¿Cómo asigno las etiquetas al mapeo de publicaciones?

Answer 1

Hay 4 enfoques que puede utilizar dentro de Elasticsearch para gestionar las relaciones. Están muy bien descritos en la publicación del blog de Elasticsearch - Managing Relations Inside Elasticsearch . Recomendaría leer el artículo completo para obtener más detalles sobre cada enfoque y luego seleccionar el enfoque que mejor se adapte a sus necesidades de negocios y que siga siendo técnicamente apropiado.

Aquí están los aspectos más destacados de los 4 enfoques.

Objeto interno

• Fácil, rápido, performante.
• Solo aplicable cuando se mantienen relaciones de uno a uno
• No hay necesidad de consultas especiales.

Anidado

• Los documentos anidados se almacenan en el mismo bloque de Lucene entre sí, lo que ayuda a leer / consultar el rendimiento. Leer un documento anidado es más rápido que el equivalente padre / hijo.
• La actualización de un solo campo en un documento anidado (padre o hijo anidado) obliga a ES a reindexar todo el documento anidado. Esto puede ser muy costoso para documentos anidados grandes
• Los documentos anidados de “referencia cruzada” son imposibles.
• Ideal para datos que no cambian con frecuencia.

Padre / hijo

• Los niños se almacenan por separado del padre, pero se envían al mismo fragmento. Así que los padres / hijos tienen un rendimiento ligeramente menor en lectura / consulta que anidados
• Las asignaciones padre / hijo tienen un poco más de sobrecarga de memoria, ya que ES mantiene una lista de "unión" en la memoria
• La actualización de un documento secundario no afecta a los padres ni a otros niños, lo que potencialmente puede ahorrar una gran cantidad de indexación en documentos grandes
• La clasificación / puntuación puede ser difícil para los padres / hijos, ya que las operaciones de tener hijos / tener padres pueden ser opacas a veces

Desnormalización

• ¡Consigues gestionar todas las relaciones tú mismo!
• Más flexible, más gastos administrativos
• Puede ser más o menos eficaz dependiendo de su configuración