Parameter cache=false

Setting the cache parameter to false we tell Solr not to cache current query results. This parameter can also be used as a filter query (fq) attribute, which tell Solr not to cache filter query results. What do we get from such behavior ? Let’s imagine the following filter as a part of the query:

fq={!frange l=10 u=100}log(sum(sqrt(popularity),100))

If we know that the queries with filter like the above one are rare, we can decide not to cache them and not change cache state for irrelevant data. To do that we add the cache=false attribute in the following way:

fq={!frange l=10 u=100 cache=false}log(sum(sqrt(popularity),100))

As I told, adding this additional attribute will result in the filter results not being cached.

Parameter cost

The additional feature of Solr 3.4 is the possibility to set filter cost in case of those filters that we don’t want to cache. Filter queries with specified cost are executed as last ones after all the cached filters. The cost attribute is specified as the integer value. Let’s look at the following example filters:

fq=cat:video&fq={!cache=false cost=50}productGroup:12&fq={!frange l=10 u=100 cache=false cost=150}log(sum(sqrt(popularity),100))

The first filter to execute will be the fq=cat:video one because it is cached. The next one to evaluate will be the one with lesser cost value, so the fq={!cache=false cost=50}. The last filter to evaluate will be the most expensive filter. In addition the last filter will operate only on documents that match the main query and all previous filters (because its cost attribute is higher than 100).

You should remember that cost attribute work only when the filter query is not cached.

To sum up

With cache and cost attributes we can control what we place in Solr cache, which is very good in most situation, when we know what queries are sent to Solr instances. Whats more, using those attributes we can improve query performance, for those queries that have filters with cost higher than 100. I think it’s worth to take a while, look at Your queries and think about if You need to cache all of those

Assumptions

In order to show how to use the local params with faceting let’s assume the following situation. In the index we have four fields defined:

• id – unique identifier,
• name – the company name,
• province – the province in which the company is located,
• city – the city where the company is located.

For the simplicity, I assumed that the fields id, province and the city are based on the string type. The field name is a text. Fields are not multivalued and the definition of types is the same as in the standard distribution of Solr.

Objective

What we want to achieve ? In addition to finding a company whose name matches the user-entered phrases, the user gives the name of the province and city. User must provide all parameter a simplification to make the example easier to understand. We want to show two types of faceting:

• cities in which the found companies are, but not narrowed to the selected province,
• all provinces in which there are companies that match the query.

Standard approach

The standard approach would rely on the generation of two queries:

q=PHRASE&fq=city:CITY&province:PROVINCE

q=PHRASE&facet=true&facet.field=city&facet.field=province

The first is responsible for the collection of companies that match the phrase entered and are narrowed to the city and province, while the second gives us the desired faceting without refinements.

Local params

Solr 1.4 brought an interesting feature – local params. In our case, what counts is that the tagging feature allows you to filter and eliminate the filters in faceting mechanism. These two queries can be replaced as follows:

q=PHRASE&fq={!tag=tagCity}city:CITY&fq={!tag=tagProvince}province:PROVINCE&facet=true&facet.field={!ex=tagCity,tagProvince}city&facet.field=!{ex=tagCity,tagProvince}province

How does it work ?

First of all, for each filter (the fq parameter) we define a unique tag by which we can refer to the filter. To do this we use the following structure {!tag=TAG_NAME}.

Then for each of the fields we want to use to do faceting we add information which filters should be excluded. In our case, we exclude the two filters in both fields when using faceting. To do this we use the following structure {!ex = TAG_NAME_1, TAG_NAME_2 ,…}.

A few words at the end

Of course, the functionality of local params is not only the faceting and the possibility of filter exclusion. I promise that in the future there will be another entry describing the wider opportunities offered by Solr and the local params functionality introduced in version 1.4.