That's a nearly 3.8X speedup!
But beyond speedups there are also new features, and here I'll describe the new
DrillSideways class being developed
under LUCENE-4748.
In the typical faceted search UI, you'll see a column to the left of
your search results showing each field (Price, Manufacturer, etc.)
enabled for refinement, displaying the unique values or ranges along
with their counts. The count tells you how many matches from your
current search you'll see if you drill down on that value or
range, by clicking it and adding that filter to your current search.
If you go shopping
for Internal
SSDs at Newegg you'll see something like the drill down on the
left.
If you click on one of those values at Newegg, say 129GB - 256GB, you'll notice that the field then disappears from the drill down options and jumps to the top of the page, as part of the search breadcrumb, where the only thing you can do with it is drill up by clicking the (X) to remove the filter. What if you drill down on several fields, but then want to explore alternate values for those fields? You can't really do that: you're stuck. This is a poor user experience, and I often find myself making excessive use of the back button to explore different options on sites that only offer drill down and drill up: the UI is too restrictive. Overstock.com is another example of a pure drill down/up UI.
Other sites improve on this by offering drill sideways, or
the option to pick alternative or additional facet values for a field
you've previously drilled down on.
For example, try searching for an LED television at Amazon, and look at the Brand field, seen in the image to the right: this is a multi-select UI, allowing you to select more than one value. When you select a value (check the box or click on the value), your search is filtered as expected, but this time the field does not disappear: it stays where it was, allowing you to then drill sideways on additional values. Much better!
LinkedIn's
faceted search, seen on the left, takes this even further: not
only are all fields drill sideways and multi-select, but there is also
a text box at the bottom for you to choose a value not shown in the
top facet values.
To recap, a single-select field only allows picking one value at a time for filtering, while a multi-select field allows picking more than one. Separately, drilling down means adding a new filter to your search, reducing the number of matching docs. Drilling up means removing an existing filter from your search, expanding the matching documents. Drilling sideways means changing an existing filter in some way, for example picking a different value to filter on (in the single-select case), or adding another or'd value to filter on (in the multi-select case).
Whether the field offers drill sideways is orthogonal to whether the field is multi-select. For example, look at the date field at Search-lucene.com: it's a single-select field, but allows for drill sideways (unfortunately the counts seem to be buggy!).
Implementing Drill Sideways
How can one implement drill sideways? It's tricky because, once you've drilled into a specific value for a given field, the other values in that field will of course have zero drill down count since they were filtered out of the result set. So how do you compute those other counts?A straightforward solution is the "hold one out" approach: if the original query is "foo", and you've drilled down on three fields (say A:a, B:b and C:c), then to compute the facet count for each of the fields A, B and C you re-run the query, computing drill down counts, each time with only the other fields filtered.
For example, the facet counts for A are the drill down counts from the query +foo +B:b +C:c (A:a is left out), while the facet counts for B are the drill down counts from the query +foo +A:a +C:c (B:b is left out), etc. You must also separately run the query with all filters (+foo +A:a +B:b +C:c) to get the actual hits. With Solr you explicitly specify this hold-on-out yourself as part of the facet request.
While this approach will produce the correct counts, it's costly because now you're running 4 queries instead of 1. You may be able to speed this up by using bitsets instead: produce a bitset of all matching documents for just the query "foo", then a bitset for each of the drill downs A, B and C, and then intersect the bitsets as above, and count facets for the resulting docs. Solr uses an approach like this, caching the bitsets across requests.
Yet another approach, and the one we took on LUCENE-4748, is to execute a single query that matches both hits as well as near-misses, which are documents that matched all but one of the filters. This is actually a standard
BooleanQuery, where
the original query is a MUST clause, and each filter is a SHOULD
clause, with minNumberShouldMatch set to the number of
drill down filters minus 1. Then, when each match is collected, if
all filters match, it's a true hit and we collect the document
accordingly and increment the drill down counts. But if it's a
near-miss, because exactly one filter failed, then we instead
increment drill sideways counts against that one field that didn't
match.
Note that when you first drill down on a given field, the resulting drill sideways counts for that field will be the same as the drill down counts just before you drilled down. If the UI can save this state then a small optimization would be to avoid counting the drill sideways counts for the just-drilled-down field, and instead reuse the previous drill down counts.
The
DrillSideways class is obviously very new, so I'm
sure there are some exciting bugs in it (though it does have a
good randomized
test). Feedback and patches are welcome!
