3
votes

I'm using facet queries for autocompletion.

For example:

http://localhost:8983/solr/collection1/autocomplete_en?facet.prefix=sol&...

The update handler is configured to do softcommits:

  <updateHandler class="solr.DirectUpdateHandler2">
    <updateLog>
      <str name="dir">${solr.ulog.dir:}</str>
    </updateLog>
    <autoCommit>
      <maxTime>30000</maxTime>
      <openSearcher>false</openSearcher>
    </autoCommit>
    <autoSoftCommit>
      <maxTime>1000</maxTime>
    </autoSoftCommit>
  </updateHandler>

But after updating the index the facet query is always slow.

This documentations says, that "soft commits will make documents visible, but at some cost. ... the FieldValueCache is invalidated, so facet queries will have to wait until the cache is refreshed"

see http://searchhub.org/2013/08/23/understanding-transaction-logs-softcommit-and-commit-in-sorlcloud/

So facet queries will be always slow, even after a soft commit, because the FieldValueCache has to be recalculated.

Facets with DocValues are real time compatible, but unfortunatly TextFields are not supported. see http://wiki.apache.org/solr/DocValues

I have to use filters on the queries, so I can't use the suggester component.

My questions:

  • Is there still a chance, to use the near real time search with faceting?
  • How is this problem solved in elastic search?
1

1 Answers

1
votes

Changing the facet.method could help. fc as the default is not suitable for faceting on fulltext fields.

In my case enum helped:

http://localhost:8983/solr/collection1/autocomplete_en?facet.prefix=sol&facet.method=enum...

But for larger indexes even enum could be too slow.

If you don't need filters on the queries, you should consider the suggester component: http://wiki.apache.org/solr/Suggester

Near real time is a problem, too. But in most usecases an update after an optimize could be sufficient.