search - elastic - match query does not support

Búsqueda elástica- search_analyzer vs index_analyzer

Question

Estaba viendo http://euphonious-intuition.com/2012/08/more-complicated-mapping-in-elasticsearch/ que explica los analizadores ElasticSearch.

No entendí la parte de tener diferentes analizadores de búsqueda e índices. El segundo ejemplo de mapeo personalizado es el siguiente:
-> el analizador de índice es un bordeNgram
-> el analizador de búsqueda es:

"full_name":{
    "filter":[
        "standard",
        "lowercase",
        "asciifolding"
    ],
    "type":"custom",
    "tokenizer":"standard"
}

si quisiéramos que la consulta "Carrera" no arrojara resultados como * ra * pport y * rac * ial debido a edgeNgram, ¿por qué indexarlo con edgeNgram en primer lugar?

Por favor explique con un ejemplo donde diferentes analizadores son útiles.

Answer 1

Para hacer referencia a la documentación oficial sobre el índice frente a los analizadores de búsqueda :

Ocasionalmente, tiene sentido usar un analizador diferente en el índice y el tiempo de búsqueda. Por ejemplo, en el momento del índice podemos querer indexar sinónimos, por ejemplo, para cada aparición de rápido también indexamos rápido, rápido y rápidamente. Pero en el tiempo de búsqueda, no necesitamos buscar todos estos sinónimos. En su lugar, solo podemos buscar la palabra que ingresó el usuario, sea rápida, rápida o rápida.

Para habilitar esta distinción, Elasticsearch también admite los parámetros index_analyzer y search_analyzer, y analizadores llamados default_index y default_search.

Tomando estos parámetros adicionales en cuenta, la secuencia completa en el tiempo del índice realmente se ve así:

• index_analyzer definido en el mapeo de campo, else
• el analizador definido en el mapeo de campo, de lo contrario
• el analizador definido en el campo _analyzer del documento, else
• el index_analyzer predeterminado para el tipo, que por defecto es
• el analizador predeterminado para el tipo, que por defecto es
• el analizador llamado default_index en la configuración del índice, que por defecto es
• el analizador nombrado por defecto en la configuración de índice, que por defecto
• el analizador llamado default_index a nivel de nodo, que se predetermina a
• el analizador nombrado por defecto a nivel de nodo, que por defecto es
• el analizador estándar

Y en el tiempo de búsqueda:

• el analizador definido en la consulta en sí, sino
• el search_analyzer definido en el mapeo de campo, else
• el analizador definido en el mapeo de campo, de lo contrario
• el valor predeterminado search_analyzer para el tipo, que por defecto es
• el analizador predeterminado para el tipo, que por defecto es
• el analizador llamado default_search en la configuración del índice, que se predetermina a
• el analizador nombrado por defecto en la configuración de índice, que por defecto
• el analizador llamado default_search en el nivel de nodo, que por defecto es
• el analizador nombrado por defecto a nivel de nodo, que por defecto es
• el analizador estándar

Answer 2

Por lo general, tiene una cadena de análisis similar tanto en tiempo de índice como en tiempo de consulta. Similar no significa exactamente lo mismo, pero generalmente la forma en que indexa los documentos refleja la forma en que los consulta.

Sin embargo, el ejemplo de los ngrams es realmente bueno, ya que es uno de los principales motivos por los que utilizaría diferentes analizadores en el índice y el tiempo de consulta.

Para las coincidencias parciales se indexa con ngramos de borde, de modo que se convierte en "elasticsearch" (con mingram 3 y maxgram 20):

"ela", "elas", "elast", "elasti", "elástico", "elásticos", "elasticse", "elástico", "elásticosear", "eleasticsearc" y "elasticsearch"

Veamos ahora el campo creado. Si consultamos el término "elástico", hay una coincidencia y obtenemos el resultado esperado. Básicamente, nos convertimos en lo que llamamos arriba del partido parcial en una coincidencia exacta, dado lo que indexamos. No es necesario aplicar ngrams a la consulta también. Si lo hiciéramos, consultaríamos todos los siguientes términos:

"ela", "elas", "elast", "elasti" y "elástico"

Eso haría que la consulta sea más compleja y llevaría a obtener resultados extraños también. Digamos que indicas el término "transcurrido" en otro documento, el mismo campo. Tendría los siguientes ngrams:

"ela", "elap", "elaps", "transcurrir", "transcurrido"

Si busca "elástico" y hace ngrams a la consulta, el término "ela" también coincidiría con este segundo documento, por lo que lo recuperaría junto con el primer documento, aunque ningún término contenga todo el término "elástico" que estaban buscando.

Sugiero que eche un vistazo a la API de análisis para jugar con diferentes analizadores y sus diferentes resultados.