elasticsearch kibana - Consultas vs.Filtros




tutorial download (6)

No puedo ver ninguna descripción de cuándo debería usar una consulta, un filtro o alguna combinación de los dos. ¿Cuál es la diferencia entre ellos? ¿Alguien puede explicar?


Answers

Esto es lo que dice la documentación oficial:

Como regla general, se deben usar filtros en lugar de consultas:

  • para búsquedas binarias sí / no
  • para consultas sobre valores exactos

Como regla general, las consultas se deben utilizar en lugar de filtros:

  • para búsqueda de texto completo
  • donde el resultado depende de un puntaje de relevancia

Un ejemplo (pruébalo tú mismo)

Say index myindex contiene tres documentos:

curl -XPOST localhost:9200/myindex/mytype  -d '{ "msg": "Hello world!" }'
curl -XPOST localhost:9200/myindex/mytype  -d '{ "msg": "Hello world! I am Sam." }'
curl -XPOST localhost:9200/myindex/mytype  -d '{ "msg": "Hi !" }'

Consulta: qué tan bien coincide un documento con la consulta

Consulta hello sam (usando la palabra clave must )

curl localhost:9200/myindex/_search?pretty  -d '
{
  "query": { "bool": { "must": { "match": { "msg": "hello sam" }}}}
}'

Documento "Hello world! I am Sam." se le asigna una puntuación más alta que "Hello world!" , porque el primero coincide con ambas palabras en la consulta. Los documentos son calificados.

"hits" : [
   ...
     "_score" : 0.74487394,
     "_source" : {
       "name" : "Hello world! I am Sam."
     }
   ...
     "_score" : 0.22108285,
     "_source" : {
       "name" : "Hello world!"
     }
   ...

Filtro: si un documento coincide con la consulta

Filtrar hello sam (utilizando el filter palabras clave)

curl localhost:9200/myindex/_search?pretty  -d '
{
  "query": { "bool": { "filter": { "match": { "msg": "hello sam" }}}}
}'

Se devuelven los documentos que contienen hello o sam . Los documentos NO son calificados .

"hits" : [
   ...
     "_score" : 0.0,
     "_source" : {
       "name" : "Hello world!"
     }
   ...
     "_score" : 0.0,
     "_source" : {
       "name" : "Hello world! I am Sam."
     }
   ...

A menos que necesite una búsqueda de texto completo o una calificación, se prefieren los filtros porque Elasticsearch almacena en caché los filtros de uso frecuente para acelerar el rendimiento. Ver Elasticsearch: consulta y contexto del filtro.


Pocos más además de lo mismo. Primero se aplica un filtro y luego la consulta se procesa sobre sus resultados. Para almacenar la coincidencia binario verdadero / falso por documento, se utiliza algo llamado matriz de conjuntos de bits. Esta matriz BitSet está en la memoria y esto se usaría desde la segunda vez que se consulta el filtro. De esta forma, utilizando la estructura de datos array array bitset, podemos utilizar el resultado almacenado en caché.

Un punto más a tener en cuenta aquí, el caché del filtro se crea solo cuando la solicitud se ejecuta, por lo tanto, solo desde el segundo golpe, realmente obtenemos la ventaja del almacenamiento en caché.

Pero luego puedes usar una API más cálida para superar esto. Cuando registra una consulta con filtro contra una API más cálida, se asegurará de que se ejecute contra un nuevo segmento cada vez que se active. Por lo tanto, obtendremos una velocidad constante desde la primera ejecución en sí.


Filters -> ¿Este documento coincide? una respuesta binaria sí o no

Queries -> ¿Este documento coincide? ¿Qué tan bien combina? usa puntuación


La diferencia es simple: los filtros están en la memoria caché y no influyen en el puntaje, por lo tanto, son más rápidos que las consultas. Echa un vistazo here también. Digamos que una consulta generalmente es algo que los usuarios escriben y es bastante impredecible, mientras que los filtros ayudan a los usuarios a limitar los resultados de búsqueda, por ejemplo, mediante el uso de facetas.


En primer lugar, hay una distinción importante que hacer aquí: MongoDB es una base de datos de propósito general, Elasticsearch es un motor de búsqueda de texto distribuido respaldado por Lucene. La gente ha estado hablando sobre el uso de Elasticsearch como una base de datos de propósito general, pero saben que no fue su diseño original. Creo que las bases de datos y los motores de búsqueda NoSQL de propósito general se dirigen a la consolidación, pero tal como están las cosas, los dos provienen de dos campos muy diferentes.

Estamos usando MongoDB y Elasticsearch en mi compañía. Almacenamos nuestros datos en MongoDB y usamos Elasticsearch exclusivamente para sus capacidades de búsqueda de texto completo. Solo enviamos un subconjunto de los campos de datos de mongo que necesitamos consultar al elástico. Nuestro caso de uso difiere del suyo en que nuestros datos de Mongo cambian todo el tiempo: un registro, o un subconjunto de los campos de un registro, puede actualizarse varias veces al día y esto puede requerir una nueva indexación de ese registro en elástico. Solo por esa razón, usar elástico como el único almacén de datos no es una buena opción para nosotros, ya que no podemos actualizar los campos seleccionados; Tendríamos que volver a indexar un documento en su totalidad. Esta no es una limitación elástica, así es como funciona Lucene, el motor de búsqueda subyacente detrás del elástico. En su caso, el hecho de que los registros no se modifiquen una vez guardados le evita tener que tomar esa decisión. Habiendo dicho eso, si la seguridad de los datos es una preocupación, lo pensaría dos veces antes de usar Elasticsearch como el único mecanismo de almacenamiento para sus datos. Puede llegar allí en algún momento, pero no estoy seguro de que esté allí todavía.

En términos de velocidad, Elastic / Lucene no solo está a la par con la velocidad de consulta de Mongo, en su caso donde hay "muy poca constante en términos de qué campos se usan para filtrar en cualquier momento", podrían ser órdenes de magnitud más rápido, especialmente a medida que los conjuntos de datos se vuelven más grandes. La diferencia radica en las implementaciones de consulta subyacentes:

  • Elástico / Lucene utiliza el Modelo de espacio vectorial e índices invertidos para la Recuperación de información , que son formas altamente eficientes de comparar la similitud de registros con una consulta. Cuando consulta Elastic / Lucene, ya conoce la respuesta; la mayor parte de su trabajo consiste en clasificar los resultados para usted por los más probables para que coincidan con sus términos de consulta. Este es un punto importante: los motores de búsqueda, a diferencia de las bases de datos, no pueden garantizarle resultados exactos; clasifican los resultados por lo cerca que llegan a su consulta. Simplemente sucede que la mayoría de las veces, los resultados son casi exactos.
  • El enfoque de Mongo es el de un almacén de datos de propósito más general; compara documentos JSON uno contra el otro. Puede obtener un gran rendimiento de todos modos, pero debe crear cuidadosamente los índices para que coincidan con las consultas que ejecutará. Específicamente, si tiene varios campos por los cuales consultará, debe crear cuidadosamente sus claves compuestas para que reduzcan el conjunto de datos que se consultarán lo más rápido posible. Por ejemplo, su primera clave debería filtrar la mayoría de su conjunto de datos, su segundo debería filtrar aún más lo que queda, y así sucesivamente. Si sus consultas no coinciden con las claves y el orden de esas teclas en los índices definidos, su rendimiento disminuirá bastante. Por otro lado, Mongo es una verdadera base de datos, así que si la precisión es lo que necesita, las respuestas que dará serán acertadas.

Para caducar los registros antiguos, Elastic tiene una característica integrada TTL. Mongo acaba de presentarlo a partir de la versión 2.2, creo.

Como no conozco sus otros requisitos, como el tamaño esperado de los datos, las transacciones, la precisión o el aspecto de sus filtros, es difícil hacer recomendaciones específicas. Con suerte, aquí hay suficiente para que comiences.





elasticsearch