indexing - multiple - maps elasticsearch

Elasticsearch múltiples analizadores para un solo campo

Question

Almazo diferentes tipos de documentos en un solo índice con un mapeo estricto y predefinido. Todos ellos tienen algún campo (por ejemplo, "cuerpo"), pero me gustaría que se analizaran de forma ligeramente diferente cuando se indexan (por ejemplo, para usar diferentes filtros de tokens para documentos específicos) y se tratan de la misma manera durante la búsqueda. Por lo que yo sé, los analizadores no se pueden especificar por documento.

Lo que también consideré usar:

1. Campos de objeto con subcampos analizados de forma diferente para tipos de documentos, por lo que cada documento tiene solo un subcampo lleno (como, "body.mail", "body.html"). El problema es que no pude buscar en todo el campo "cuerpo" que miraría a través de todos sus subcampos (para no romper la aplicación existente).
2. Nueva reencarnación de campos múltiples (para tener un campo "cuerpo" con un analizador genérico y "correo", "html", etc. dentro de él). Hovewer, no estoy seguro si es posible usarlos directamente durante la indexación e indirectamente durante la búsqueda (por ejemplo, para guardar el objeto con {"mail":"smth"} para usar un analizador de índice específico, luego busque por "query":{"body":"smth"} para usar el analizador de búsqueda genérico).
3. Para separar "cuerpo" en varios campos con diferentes asignaciones, elimínelos de _all y establezca copy_to en un solo campo de body . No estoy seguro, pero agregará una sobrecarga de índice sustancial debido a la copia.

Answer 1

Creo que puedes usar campos múltiples. Con campos múltiples puede definir analizadores (tanto de indexación como de búsqueda) para cada subcampo, y hacer la búsqueda en los campos correspondientes según los requisitos de las aplicaciones. En general, el analizador de índice puede diferenciar de un campo a otro, lo mismo para el analizador de búsqueda.

{ "your_type" : { "properties":{ "body" : { "type" : "string", "index" : "analyzed", "index_analyzer" : "index_body_analyzer", "search_analyzer" : "search_body_analyzer", "fields" : { "mail" : { "type" : "string", "index" : "analyzed", "index_analyzer" : "index_bodymail_analyzer", "search_analyzer" : "search_bodymail_analyzer" }, "html": { "type" : "string", "index" : "analyzed", "index_analyzer" : "index_bodyhtml_analyzer", "search_analyzer" : "search_bodyhtml_analyzer" } } } } }

Answer 2

Como mencioné en los comentarios, lo que quieres no es posible. Su requisito, en una frase, es: tener los mismos datos analizados de múltiples maneras, pero buscarlos como un solo campo porque esto rompería la aplicación existente.

             -- body.html          
             -- body.email
body field ---- body.content     --- all searched as "body"
            ...
             -- body.destination
             -- body.whatever

• Su primera opción son los campos múltiples que tienen este propósito exacto en mente: tener los mismos datos analizados de múltiples maneras. El problema es que no puede buscar "body" y espera que ES busque body.html , body.email ... Incluso si esto fuera posible, desea que se body.email una búsqueda con diferentes analizadores. De nuevo, no es posible. Esta opción requiere que cambie la aplicación y busque cada campo en un multi_match o en query_string .

• Su segunda opción, la reincarnation of multi-fields , tampoco funcionará porque no puede hacer referencia a body y ES, en segundo plano, para que coincida con el mail , el content , etc.

• La tercera opción - usar copy_to - no funcionará porque copiar a otro campo "X" significa indexar los datos que se están copiando será analizado con el analizador de X , y esto rompe su requisito de tener los mismos datos analizados de manera diferente.

• Podría haber una cuarta opción - "path": "just_name" de multi_fields - que a primera vista debería funcionar. Es decir, puede tener 3 campos múltiples (correo electrónico, contenido, html) que tienen un subcampo body . Tener "path": "just_name" permite buscar solo el body incluso si el body es un subcampo de muchos otros campos. Pero esto no es posible porque este tipo de campos múltiples no aceptará diferentes analizadores para el mismo body .

De cualquier manera, debe cambiar algo en sus requisitos, ya que no funcionarán de la manera que lo desee.

Dicho esto, tengo curiosidad por ver qué consultas estás usando en tu aplicación. Sería un cambio simple ( sí, tendrá que cambiar su aplicación ) de consultar body campo del body al body.* consulta body.* En un multi_match .

Y tengo otra solución para ti: crear múltiples índices, un índice para cada analizador de tu body . Por ejemplo, para mail , content y html usted define tres índices:

PUT /multi_fields1
{
  "mappings": {
    "test": {
      "properties": {
        "body": {
          "type": "string",
          "index_analyzer": "whitespace",
          "search_analyzer": "standard"
        }
      }
    }
  }
}
PUT /multi_fields2
{
  "mappings": {
    "test": {
      "properties": {
        "body": {
          "type": "string",
          "index_analyzer": "standard",
          "search_analyzer": "standard"
        }
      }
    }
  }
}
PUT /multi_fields3
{
  "mappings": {
    "test": {
      "properties": {
        "body": {
          "type": "string",
          "index_analyzer": "keyword",
          "search_analyzer": "standard"
        }
      }
    }
  }
}

Verá que todos ellos tienen el mismo type y el mismo nombre de campo - body - pero diferentes index_analyzer s. Luego defines un alias:

POST _aliases
{
  "actions": [
    {"add": {
        "index": "multi_fields1",
        "alias": "multi"}},
    {"add": {
        "index": "multi_fields2",
        "alias": "multi"}},
    {"add": {
        "index": "multi_fields3",
        "alias": "multi"}}
  ]
}

Nombre su alias igual que su índice actual. La aplicación no necesita cambiar, usará el mismo nombre para la búsqueda de índice, pero este nombre no apuntará a un índice, sino a un alias que a su vez se refiere a sus múltiples índices. Lo que debe cambiar es cómo indexa los documentos, porque los documentos html deben ir en el índice multi_fields1 por ejemplo, un documento de email debe estar indexado en el índice multi_fields2 etc.

Cualquiera que sea la solución que encuentre / elija, sus requisitos deben cambiar porque la forma en que la desea no es posible.