2011-04-05 10 views
8

Contexto¿Cómo consigue Lucene/Solr un alto rendimiento en la búsqueda multicampo/facetada?

Ésta es una cuestión principalmente de Lucene (o posiblemente Solr) internos. El tema principal es búsqueda facetada, en la que la búsqueda puede realizarse a lo largo de múltiples dimensiones (facetas) independientes de objetos (por ejemplo, tamaño, velocidad, precio de un automóvil).

Cuando se implementa con base de datos relacional, para un gran número de facetas, los índices de múltiples campos no son útiles, ya que las facetas se pueden buscar en cualquier orden, por lo que se usa un multi-índice ordenado con pocas posibilidades, y creando todas las posibles ordenamientos de índices es insoportable.

Solr se anuncia que se adapta bien a la tarea de búsqueda facetada, que si creo correctamente tiene que estar conectada con Lucene (supuestamente) funcionando bien en consultas de campo múltiple (donde los campos de un documento se relacionan con las facetas de un objeto) .

Pregunta

El índice invertido de Lucene se pueden almacenar en una base de datos relacional, y, naturalmente, tomar las intersecciones de los documentos coincidentes también se puede lograr trivialmente con RDBMS utilizando índices de campo único.

Por lo tanto, se supone que Lucene tiene una técnica avanzada para consultas de campo múltiple además de simplemente tomar la intersección de documentos coincidentes en función del índice invertido.

Entonces la pregunta es, ¿qué es esta técnica/truco? Más ampliamente: ¿Por qué Lucene/Solr logra un mejor rendimiento de búsqueda facetada teóricamente que RDBMS podría (si es así)?

Nota: Mi primera conjetura sería que Lucene usaría algún método de partición del espacio para particionar un espacio vectorial construido a partir de los campos del documento como dimensiones, pero como tengo entendido, Lucene no se basa exclusivamente en el espacio vectorial.

Respuesta

5

facetado

Hay dos respuestas para tallar, porque hay dos tipos de facetas. No estoy seguro de que ninguno de estos sea más rápido que un RDBMS.

  1. Enum faceting. Los resultados de una consulta son un vector de bits donde el i-ésimo bit es 1 si el i-ésimo documento fue una coincidencia. La faceta también es un vector de poco, por lo que la intersección es solo AND a nivel de bit. No creo que este sea un enfoque novedoso, y la mayoría de los RDBMS probablemente lo respalden.
  2. Caché de campo. Este es solo un índice normal (no invertido). La consulta de estilo SQL que se ejecuta aquí es como:

    seleccione faceta, count (*) de field_cache donde docId en query_results grupo por las facetas

Una vez más, no creo que esto es cualquier cosa que un RDBMS normal no podría hacer. El índice es una lista de omisiones, con docId como clave.

Multi-término de búsqueda

Aquí es donde brilla Lucene. Por qué el enfoque de Lucene es tan bueno es demasiado largo para publicarlo aquí, pero puedo recomendar this post on Lucene Performance, o los documentos vinculados allí.

+0

Gracias. La publicación que señala escribe: "Las optimizaciones reales de Lucene provienen del hecho de que nunca busca todos los documentos que coinciden con la consulta, sino la parte superior k". En caso de búsqueda con facetas, creo que deben tenerse en cuenta todas las coincidencias. – ron

+0

@ron: sí, no sé si el rendimiento de las consultas facetadas de Lucene es notablemente bueno. Pero no soy un experto en esta área. – Xodarap

3

un post explicando se puede encontrar en: http://yonik.wordpress.com/2008/11/25/solr-faceted-search-performance-improvements/

El nuevo método funciona mediante la no-invirtiendo el campo indexado a ser facetas, lo que permite búsqueda rápida de los términos en el campo para cualquier documento dado. En realidad, es un enfoque híbrido: para ahorrar memoria y aumentar la velocidad, los términos que aparecen en muchos documentos (más del 5%) no se invierten, en cambio la lógica de intersección establecida tradicional se usa para obtener los conteos.

Cuestiones relacionadas