Pregunta Mapeos de relaciones Elasticsearch (uno a uno y uno a muchos)


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

p.ej.: http://localhost:9200/blog/posts, http://localhost:9200/blog/tags.

En las etiquetas, escribí más de 1000 etiquetas y 10 publicaciones en el tipo de publicaciones.

por ejemplo, publicaciones

{   
    "_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 del blog (es decir, relación => mapeo).

¿Cómo asigno las etiquetas a la asignación de publicaciones?


20
2018-05-01 06:31


origen


Respuestas:


Hay 4 enfoques que puede usar dentro de Elasticsearch para administrar las relaciones. Están muy bien delineados en la publicación del blog Elasticsearch - Gestión de relaciones dentro de Elasticsearch Recomiendo leer el artículo completo para obtener más detalles sobre cada enfoque y luego seleccionar el enfoque que mejor se adapte a las necesidades de su negocio sin dejar de ser técnicamente apropiado.

Estos son los aspectos más destacados de los 4 enfoques.

Objeto interno

  • Fácil, rápido, rendimiento
  • Solo aplicable cuando se mantienen relaciones uno-a-uno
  • Sin necesidad de consultas especiales

Anidado

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

Padre / Hijo

  • Los niños se almacenan por separado del padre, pero se enrutan al mismo fragmento. Entonces, los padres / hijos tienen un rendimiento ligeramente menor en lectura / consulta que en los anidados
  • Las asignaciones padre / hijo tienen una sobrecarga de memoria extra, ya que ES mantiene una lista de "unión" en la memoria
  • La actualización de un documento secundario no afecta al padre ni a ningún otro elemento secundario, lo que puede ahorrar una gran cantidad de indexación en documentos grandes.
  • La clasificación / puntuación puede ser difícil con el padre / hijo ya que las operaciones de Has Child / Has Parent pueden ser opacas a veces

Desnormalización

  • ¡Tienes que administrar todas las relaciones tú mismo!
  • La sobrecarga más flexible y más administrativa
  • Puede ser más o menos eficiente dependiendo de su configuración

44
2018-05-01 12:08