Important Note – at this point this functionality is only available in version 4.0, Solr, which is the development version. To use this version you need to download the code from trunk of Lucene/Solr SVN repository.

A few words at the beginning

In many projects in which I had the opportunity to deal with there was a need to use a hierarchical faceting. One of the simplest example is the requirement of showing the cities in the provinces and the number of documents in both provinces, as well as in various cities. Till recently, with no changes in the structure of data, it was impossible to achieve such functionality. Now it is possible

Indexing

In order not to unnecessarily complicate the described functionality I decided to use the sample XML documents that are available in the directory /exampledocs of the example deployment. I also didn’t modify the schema.xml file, or solrconfig.xml, so that configurations are standard. So thats all when it comes to configuration. So we can start the indexing process (I called the command from the directory $SOLR_HOME/exampledocs/):

./post.sh *.xml

After seeing several screens of information, and we have our data indexed.

The mechanism

It is not difficult to use hierarchical faceting. Solr creators gave us to use two additional parameters to the ones we already know:

• facet.pivot – list of comma-separated fields, which shows at which fields and in what order to calculate the structure,
• facet.pivot.mincount – the minimum number of documents there needs to be to the result to be included in faceting results. The default value is 1.

So let’s try it.

Queries

At the beginning of the try with two fields. I query for all the documents from the index and add the parameter facet.pivot=cat,inStock to say Solr that I want to get the results of the hierarchical faceting, where the first level of the hierarchy is the cat field, and the second level is the inStock field. The query looks as follows:

http://localhost:8983/solr/select/?q=*:*&facet=true&facet.pivot=cat,inStock

To shorten the listing I omitted the part responsible for the search results along with a header.

<?xml version="1.0" encoding="UTF-8"?>
<response>
.
.
.
<result name="response" numFound="19" start="0"/>
<lst name="facet_counts">
  <lst name="facet_queries"/>
  <lst name="facet_fields"/>
  <lst name="facet_dates"/>
  <lst name="facet_ranges"/>
  <lst name="facet_pivot">
    <arr name="cat,inStock">
      <lst>
        <str name="field">cat</str>
        <str name="value">electronics</str>
        <int name="count">17</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">13</int>
          </lst>
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">4</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">memory</str>
        <int name="count">6</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">6</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">connector</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">graphics card</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">hard drive</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">monitor</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">search</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
      <lst>
        <str name="field">cat</str>
        <str name="value">software</str>
        <int name="count">2</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">2</int>
          </lst>
        </arr>
      </lst>
    </arr>
  </lst>
</lst>
</response>

The presentation of faceting results has changed in this case. For each of the main level we have the markers defining the field (the tag with the attribute name=”field”), value (the tag with the attribute name=”value”) and the number of documents (the tag with the attribute name=”count”). Next there is the the second level hierarchy (tag with the attribute name=”pivot”). The second level contains the same elements as the first level – name, value and the number of documents with a given value.

Let’s see how this mechanism can deal with more levels of depth. To check that I run the following query:

http://localhost:8983/solr/select/?q=*:*&facet=true&facet.pivot=cat,inStock,features

I omitted the response header with the results, leaving the faceting results only. In addition, due to the length of the faceting results I only show one level one level faceting:

<?xml version="1.0" encoding="UTF-8"?>
<response>
.
.
.
<result name="response" numFound="19" start="0"/>
<lst name="facet_counts">
  <lst name="facet_queries"/>
  <lst name="facet_fields"/>
  <lst name="facet_dates"/>
  <lst name="facet_ranges"/>
  <lst name="facet_pivot">
    <arr name="cat,inStock,features">
      <lst>
        <str name="field">cat</str>
        <str name="value">electronics</str>
        <int name="count">17</int>
        <arr name="pivot">
          <lst>
            <str name="field">inStock</str>
            <bool name="value">true</bool>
            <int name="count">13</int>
            <arr name="pivot">
              <lst>
                <str name="field">features</str>
                <str name="value">2</str>
                <int name="count">7</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">3</str>
                <int name="count">7</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">lcd</str>
                <int name="count">5</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">x</str>
                <int name="count">5</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">ca</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">latenc</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">tft</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">v</str>
                <int name="count">4</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">0</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">1</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">25</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">30</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">5</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">7</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">8</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">time</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">up</str>
                <int name="count">3</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">000</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">19</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">20</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">2336</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">27</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">275</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">6</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">75</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">activ</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">built</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">cach</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">color</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">flash</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">heat</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">heatspread</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">matrix</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">mb</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">ms</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">photo</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">resolut</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">seek</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">speed</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">spreader</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">unbuff</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">usb</str>
                <int name="count">2</int>
              </lst>
            </arr>
          </lst>
          <lst>
            <str name="field">inStock</str>
            <bool name="value">false</bool>
            <int name="count">4</int>
            <arr name="pivot">
              <lst>
                <str name="field">features</str>
                <str name="value">0</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">1</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">16</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">2</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">20</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">3</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">9</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">90</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">adapt</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">car</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">clock</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">direct</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">directx</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">dual</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">dvi</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">express</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gddr</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">ghz</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gl</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gpu</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">gpuvpu</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">hdtv</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">mb</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">mhz</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">open</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">opengl</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">out</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">pci</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">power</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">vpu</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">white</str>
                <int name="count">2</int>
              </lst>
              <lst>
                <str name="field">features</str>
                <str name="value">x</str>
                <int name="count">2</int>
              </lst>
            </arr>
          </lst>
        </arr>
      </lst>
    </arr>
  </lst>
</lst>
</response>

As shown in the example, also in this case Solr had no problems with the correct calculation of the hierarchy. The above example is almost the same, in the context of data available, as the previous example, it only contains one more level of depth.

A few words at the end

In my opinion this is one of the more useful features for “ordinary” user. Unfortunately, so far only available in development version of Solr. I have not found any information about whether it is planned to transfer this functionality to version 1.5 of Solr, which is named branch_3x branch in SVN. However, it is important that this functionality was commited, and sooner or later Solr users will be able to use it.

One of the few sources of information about faceting is Solr wiki – to be more specific – the page at: http://wiki.apache.org/solr/SimpleFacetParameters. The following article is an extension to the information available on the wiki website.

Solr faceting mechanism can be divided into four basic types:

• field faceting,
• query faceting,
• date faceting,
• range facteing.

To turn Solr faceting mechanism on, one need to pass facet parameter with the value true.

Field faceting

First type of faceting. This type of faceting categorize documents found due to specified field. With this type of faceting we are able to get a number of documents found for example in each category or geographical location. Faceting by field is characterized by a large number of options which configure its behavior. This are the parameters available for use:

• facet.field – parameter specifying which field will be used to perform faceting. This parameter can be specified multiple times. Remember that adding multiple facet.field parameters to the query can affect performance.
• facet.prefix – restricts faceting results to those that begin with the specified prefix. The parameter can be defined for each field specified by the facet.field parameter – you can do it, by adding a parameter like this: facet.field_name.prefix. This parameter is a relatively simple way to implement autocomplete mechanism.
• facet.sort – specifies how to sort faceting results. If You use Solr version lower than 1.4, this parameter takes values of true or false indicating successively – sort by the number of results and sort by index order (in the case of ASCII this means alphabetical sorting). If however You are using Solr version 1.4 or higher You should use count value (meaning the same as true), or index value (meaning the same as false). The default value for this parameter is true/count when facet.limit set to 0 or false/index for other values of facet.limit parameter. The parameter can be defined for each field specified by the facet.field parameter.
• facet.limit – parameter specifying how many unique values of faceting results to display. A negative value for this parameter mean no limit. Please note that the larger the limit, the more memory you need and the longer query execution. Default parameter value is 100. The parameter can be defined for each field specified by the facet.field parameter.
• facet.offset – parameter defining from offset (from the first faceting result) of presented faceting results. Default parameter value is 0. This parameter is designed to help implementing faceting result paging. The parameter can be defined for each field specified by the facet.field parameter.
• facet.mincount – parameter specifying the minimum size of result to be included in faceting results. The default value is 0. The parameter can be defined for each field specified by the facet.field parameter.
• facet.missing – parameter specifying whether, in addition to standard faceting results, number of documents without a value in the specified field should be included. This parameter can take values of true or false. The default parameter value is false. The parameter can be defined for each field specified by the facet.field parameter.
• facet.method – parameter introduced in Solr 1.4. It takes the value of enum or fc. Specifies a method for faceting calculation. Setting this parameter to enum effects in using term enumeration to calculate faceting results. This method is proven to be most efficient when dealing with fields with small number of unique terms. The second method, labeled fc, is the standard method for faceting calculation. It takes all the results and iterate over all documents in the result set. The parameter can be defined for each field specified by the facet.field parameter. The default value is fc for all the fields not based on Boolean type.
• facet.enum.cache.minDf – parameter with strange sounding name specifying the minimum number of matching documents to a single term to the fc method to be used for faceting result calculation. I know it sounds strange but i do not know how to explain it easier

These are the parameters of field faceting. In case of most parameters I have written that there is a possibility to define their values for each field specified by facet.field parameter. How does it look like ? Suppose we have a query like this:

q=solr&facet=true&facet.field=category&facet.field=location

It is a simple query for ‘solr’ term with faceting mechanism turned on. There are two facet fields defined – category and location. Lets say, that we would like to have 200 facet results for category field sorted by count and 50 facet results for location field sorted alphabetically. To do that we add the following fragment to the query shown above:

facet.category.limit=200&facet.category.sort=count&facet.location.limit=50&facet.location.sort=index

As shown we can easily modify facet mechanism behavior for individual facet fields.

Query faceting

Facet mechanism based on a single parameter – facet.query to which we give a query. The query passed to the parameter must be constructed so that standard Lucene query parser can understand it. An example use of this parameter is, for example query a group of pricing, which could look like:

facet.query=price: [0+TO+100]

Note, however, that each added facet.query parameter is another query to Lucene, which means performance loss. Many facet.query parameters in a query can be painful to Solr.

There is one more thing worth mentioning when talking about query faceting – there is a possibility to define your own parser to parse facet.query parameter value. To use your own parser, for example, called myParser parameter passed to Solr should look like this:

facet.query={!myParser}aaa

Date faceting

New faceting functionality introduced in Solr 1.3. Date faceting allows you to calculate faceting results including all the intricacies of processing dates. Please note that date faceting can only be used with fields based on the type solr.DateField. Now let’s get on with the parameters associated with date faceting:

• facet.date – like facet.field parameter, this parameter is used to identify fields where dates faceting should be used. As in the case of facet.field parameter you can specify this parameter several times to allow date faceting on many fields in one query.
• facet.date.start – parameter specifying the lower limit of date on which the faceting calculation should be started. This parameter can be defined for each field specified by the facet.date parameter. This parameter is mandatory when using facet.date and should be defined for each facet.date parameter.
• facet.date.end – parameter defining the upper limit of the date, on which the faceting calculation should be ended. This parameter can be defined for each field specified by the facet.date parameter. This parameter is mandatory when using facet.date and should be defined for each facet.date parameter.
• facet.date.gap – parameter specifying date compartments to be generated for the defined boundaries. This parameter is mandatory when using facet.date and should be defined for each facet.date parameter. The parameter can be defined for each field specified by the facet.date parameter.
• facet.date.hardend – parameter taking values true and false, telling Solr what to do in the case when the parameter facet.date.gap is not evenly splitting the compartments. If we set this parameter to true the last compartment generated by facet.date.gap parameter can be wider than the boundary defined by facet.date.end parameter. If we set this parameter to false (default value) the last compartment generated by facet.date.gap parameter can be smaller then the rest of the ranges. The parameter can be defined for each field specified by the facet.date parameter.
• facet.date.other – parameter specifying what values besides the standard ones (ranges) should be added to results of date faceting. The parameter can be defined for each field specified by the facet.date parameter. The parameter can take following values:
  • before – in addition to the standard date faceting results, there will be one more – number of documents with a date before the one defined in the facet.date.start parameter,
  • after – in addition to the standard date faceting results, there will be one more – number of documents with the date after the one defined in the facet.date.end parameter,
  • between – in addition to the standard date faceting results, there will be one more – number of documents with the date between facet.date.start and facet.date.end parameters,
  • all – a shortcut to define all the above,
  • none – none of the additional results will be added to date faceting results.
• facet.date.include – parameter that will be introduced in Solr 4.0. It allows of closing or opening of the compartments defined by the boundaries and the gap. The parameter will accept the following values:
  • lower – each of the resulting compartment will contain its lower limit,
  • upper – each of the resulting compartment will contain its upper limit,
  • egde – the first and last interval will include its external borders – that is, for the first lower and upper range for the last interval,
  • outer – a parameter specifying that the compartments defined by the values before and after of the facet.date.other parameter will contain its borders, even if other compartments already contain these borders,
  • all – a parameter that causes the inclusion of all of the above options.

That is how we can modify the behavior of the date faceting. Now, some example of using this kind of faceting:

q=solr&facet=true&facet.date=addDate&facet.date.start=NOW/DAY-30DAYS&facet.date.end=NOW/DAY%2B30DAYS&facet.date.gap=%2B1DAY

What does the above query do ? We turn the faceting mechanism on, we define date faceting for addDate field. What we want to get is the compartments between 30 days before today (NOW/DAY-30DAYS) and 30 days after today (NOW/DAY+30DAYS). The compartments will be of the size of a single day.

Range faceting

Functionality which will be available in Solr 3.1. If someone want to test it right now, both the trunk and branch 3.x have this functionality implemented. This method of faceting is the extension of date faceting. This functionality works similar to date faceting – as a result we get a list of compartments constructed automatically based on parameters. Here are the list of parameters that can be used to define range faceting behavior:

• facet.range – like facet.field parameter, this parameter is used to identify fields where range faceting should be used. As in the case of facet.field parameter you can specify this parameter several times to allow range faceting on many fields in one query.
• facet.range.start – parameter specifying the lower limit of range on which the faceting calculation should be started. This parameter can be defined for each field specified by the facet.range parameter. This parameter is mandatory when using facet.range and should be defined for each facet.range parameter.
• facet.range.end – parameter defining the upper limit of the range, on which the faceting calculation should be ended. This parameter can be defined for each field specified by the facet.range parameter. This parameter is mandatory when using facet.range and should be defined for each facet.range parameter.
• facet.range.gap – parameter specifying range compartments to be generated for the defined boundaries. This parameter is mandatory when using facet.range and should be defined for each facet.date parameter. The parameter can be defined for each field specified by the facet.date parameter.
• facet.range.hardend – parameter taking values true and false, telling Solr what to do in the case when the parameter facet.range.gap is not evenly splitting the compartments. If we set this parameter to true the last compartment generated by facet.range.gap parameter can be wider than the boundary defined by facet.range.end parameter. If we set this parameter to false (default value) the last compartment generated by facet.range.gap parameter can be smaller then the rest of the ranges. The parameter can be defined for each field specified by the facet.rangeparameter.
• facet.range.other – parameter specifying what values besides the standard ones (ranges) should be added to results of range faceting. The parameter can be defined for each field specified by the facet.range parameter. The parameter can take following values:
  • before – in addition to the standard range faceting results, there will be one more – number of documents with a values lower than the one defined in the facet.range.start parameter,
  • after – in addition to the standard range faceting results, there will be one more – number of documents with the values higher than the one defined in the facet.range.end parameter,
  • between – in addition to the standard range faceting results, there will be one more – number of documents with the values between facet.range.start and facet.range.end parameters,
  • all – a shortcut to define all the above,
  • none – none of the additional results will be added to range faceting results.
• facet.range.include – parameter allowing closing or opening of the compartments defined by the boundaries and the gap. The parameter will accept the following values:
  • lower – each of the resulting compartment will contain its lower limit,
  • upper – each of the resulting compartment will contain its upper limit,
  • egde – the first and last interval will include its external borders – that is, for the first lower and upper range for the last interval,
  • outer – a parameter specifying that the compartments defined by the values before and after of the facet.range.other parameter will contain its borders, even if other compartments already contain these borders,
  • all – a parameter that causes the inclusion of all of the above options.

As you can see the range faceting parameters are almost identical to those in date faceting. The behavior is also almost identical. An example query using ranges faceting may be the following query:

q=solr&facet=true&facet.range=price&facet.range.start=0&facet.range.end=1000&facet.range.gap=100

So, we went through all of the types of faceting. But thats not all. Users of Solr version 1.4 and higher have the opportunity to use the so-called LocalParams.

LocalParams and faceting

Suppose we have a requirement. We have a query that returns search results for the term ‘solr’ and in which we have defined two filters, one for category and one for the country of origin of the document. In addition to the search results we want to enable navigation through the regions and categories, but we would like them not to be dependend on each other. That is, we want to give the opportunity to navigate through the regions for the term ‘solr’ but we dont want it to be limited to the selected category, and vice versa. To do it in Solr version 1.3 or earlier, we would write the following query:

q=solr&fq=category:search&fq=region:poland
q=solr&facet=true&facet.field=category&facet.field=region

Two queries, because first we have to get narrowed search results, on the other hand we need the faceting result not to be narrowed by filters. For Solr version 1.4 or higher, we can shorten this to one query. For this purpose, we use the possibility of tagging and exclusion of tagged parameters. First we change the query as follows:

q=solr&fq={!tag=categoryFQ}fq=category:search&fq={!tag=regionFQ}region:poland

For now, the search results will not change. We added tags to the filters in the above query so we can later exclude them in faceting. Then we modify the second query as follows:

q=solr&facet=true&facet.field={!ex=categoryFQ,regionFQ}category&facet.field={!ex=categoryFQ,regionFQ}region

So far the faceting results will not change. We added exclusions to the facet.field parameters, so filters named categoryFQ and regionFQ will not be taken into consideration when calculating faceting results.

Then we combine the modified query, so it should look as follows:

q=solr&fq={!tag=categoryFQ}fq=category:search&fq={!tag=regionFQ}region:poland&facet=true&facet.field={!ex=categoryFQ,regionFQ}category&facet.field={!ex=categoryFQ,regionFQ}region

I`ll write more about LocalParams in a future entries.

A few words at the end

I hope that this article approached the possibility of using Solr faceting, both in earlier versions of Solr, in the present, as well as those that arise in the nearest future.

1. Lack of filters

One of the fundamental errors that I encounter from time to time is the lack of filters, which in context of query means no fq parameter. Let us remember that filters are out friends Remember that because of filters Solr cache is used more optimally. Filter do not affect relevance of the document in the context of query and search results (score factor), and thus, we can perform filtering without fear of the change in the score value of individual documents (useful for example in e-commerce for product groups narrowing).

2. Logical conditions and q parameter

Another of the “sins” that I come across quite often is a one with close relationship with the previous point. It’s not a bug in the literal sense, but it is an area where a simple change will have a significant influence on performance. Assuming that the default logical operator is OR, imagine your query in the form of: q=(java+design+patterns)+AND+category:books+AND+promotion:true+AND+publisher:ABC. This query is correct from the perspective of the application logic, where we get the appropriate group search results. But what if we also want to optimally use Solr cache and thus boost performance. The anserw is quite simple – move some of the terms to filters. By changing out a query to q=java+design+patterns&fq=category:books&fq=promotion:true&fq=publisher:ABC Solr benefit from two types of cache – queryDocumentCache to retrieve documents for a query with parameter q and the filterCache for each of the filters. With the change of the query we were able to optimize the query to use two types of cache and in addition to optimize the entries of queryDocumentsCache (due to the shortening of the query parameter q).

3. Hugh numbers of facet queries

Another “sin” associated with handling groups of documents. Quite often, especially, in applications that can categorize products in many ways, I have met queries with a lot of facet.query parameters that correspond to the grouping of documents. Grouping by price, location, product groups, and so on. A good example is grouping by price where the business customer can set the price ranges for each category and then application must group products by those ranges. This leads to queries that have 100, 200 or more facet.query parameters added. Please remember that each facet.query has an impact on efficiency, not to mention 100 or 200 of them. If we are interested in a quick response from Solr we can not make such a queries. In such cases, I always propose modifying the index structure if needed, and they are needed in most cases. Some modifications (like defining ranges at index time) allows to eliminate tens or hundreds of facet.query for one facet.field parameter. But this method is associated to another problem – explanation for the customer, why “re-index button” must be pressed after range changes. As a rule, however, performance testing at high loads and large variety of queries speak for themselves.

4. Facet limits

The problem appears in the line where Solr meets business logic. An example of this “sin” is a simple list of categories that a customer wants to have displayed depending on user location on the website. When we have a small numbers of categories we do not have a problem, but what about thousands of categories. Very often, I met with the approach taken by the developers to retrieve all categories of Solr (with increased facet.limit parameter compared to the default value) and choose the right categories in the application that is using Solr. I think this approach can generate problems – first of all faceting requires memory, second aggregating of facet elements need time, and of course getting all of the 50.000 categories with it’s counts can be painful to Solr. If we want a fast queries, try to use the parameter facet.limit reasonable. If You need many facet results try to build your application so it can use facet.offset parameter and therfore use paging. If this is not possible, at least configure Your container to have enough memory to handle parallel queries and get ready to have queries that can perform longer when having high facet.limit value.

5. Downloading of unnecessary data

Very common problem is the retrieval of all information, not just those that we need. Of course, the problem does not apply to deployments where Sole offers information such as, for example, only the product ID. However, a large number of deployments that I’ve deal with was based almost entirely on Solr, and hence Solr index was made up of multiple stored fields. Developers using Solr very rarely used the parameter fl and the possibility of limiting the fields that are returned. In extreme cases, this led to problems with the amount of data that had to be sent over the network.

6. Many requests to obtain count of groups of documents

In some applications more important than the actual search capabilities were the navigation, where users can browse document repository by it’s feature, like department, category, subcategory, and so on. Very often, in addition to names there are also numbers displayed – the numbers of documents with this feature. I met cases were the number of documents were obtained using a separate query. Effect – 100 categories displayed on a web page led to 100 separate queries to Solr. Do not go this way, if You have to modify the Solr index to use the facet mechanism. Maybe at that time it will be more work, but certainly in the long run this is worth it.

A few words at the end

Please note that these are just examples that I think are fairly universal, at least, which I quite often encountered during my work. They are not all the errors that happen when using the Solr, but I hope to highlight some of the mistakes people tend to make and how to go around them.