Home/ Questions/Q 4267852
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T06:57:21+00:00

Context This is a question mainly about Lucene (or possibly Solr) internals. The main

  • 0

Context

This is a question mainly about Lucene (or possibly Solr) internals. The main topic is faceted search, in which search can happen along multiple independent dimensions (facets) of objects (for example size, speed, price of a car).

When implemented with relational database, for a large number of facets multi-field indices are not useful, since facets can be searched in any order, so a specific ordered multi-index is used with low chance, and creating all possible orderings of indices is unbearable.

Solr is advertised to cope well with the faceted search task, which if I think correctly has to be connected with Lucene (supposedly) performing well on multi-field queries (where fields of a document relate to facets of an object).

Question

The inverted index of Lucene can be stored in a relational database, and naturally taking the intersections of the matching documents can also be trivially achieved with RDBMS using single-field indices.

Therefore, Lucene supposedly has some advanced technique for multi-field queries other than just taking the intersection of matching documents based on the inverted index.

So the question is, what is this technique/trick? More broadly: Why can Lucene/Solr achieve better faceted search performance theoretically than RDBMS could (if so)?

Note: My first guess would be that Lucene would use some space partitioning method for partitioning a vector space built from the document fields as dimensions, but as I understand Lucene is not purely vector space based.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Faceting

    There are two answers for faceting, because there are two types of faceting. I’m not certain that either of these are faster than an RDBMS.

    1. Enum faceting. Results of a query are a bit vector where the ith bit is 1 if the ith document was a match. The facet is also a bit vector, so intersection is just a bitwise AND. I don’t think this is a novel approach, and most RDBMS’s probably support it.

    2. Field Cache. This is just a normal (non-inverted) index. The SQL-style query that is run here is like:

      select facet, count(*) from field_cache
      where docId in query_results
      group by facet

    Again, I don’t think this is anything that a normal RDBMS couldn’t do. The index is a skip list, with the docId as the key.

    Multi-term search

    This is where Lucene shines. Why Lucene’s approach is so good is too long to post here, but I can recommend this post on Lucene Performance, or the papers linked therein.

    • 0