Some theory

Data update in Lucene and Solr has one disadvantage – when you submit index updates they can’t be seen until commit operation is run. The problem is that commit is costly in terms of performance and intense commiting may cause performance problems. So, when you need your data to be visible right after being change you may be forced to choose – either performance, or fast updates. In order to address that Lucene and Solr are working towards enabling Near Real Time (NRT) searching. In Lucene we have that possibility, in Solr 4.0 we will also be able to use that and not only that.

Configuration

In order to use Realtime Get functionality we need to configure the following Solr features:

Transaction log

The first thing to configure is the transaction log writing. In order to do that you need to add the following to your updateHandler configuration:

<updateLog>
  <str name="dir">
The above entry says, that the directory holding transaction log will be located in the same directory where the index directory is located.
Realtime Get handler
The second thing that needs to be done, to see the Realtime Get in action, is the appropriate handler configuration (or adding component to your already defined handler). To do that add the following to your solrconfig.xml file:

<requestHandler name="/get" class="solr.RealTimeGetHandler">
  <lst name="defaults">
    <str name="omitHeader">true</str>
  </lst>
</requestHandler>
The above entry it's nothing unusual - it just add a new request handler implementing solr.RealTimeGetHandler class, which enables checking the transaction log.
Action
To check how Realtime Get works I decided to do a simple test. The first thing I did is indexing one file (from the ones that are available in the exampledocs directory) with the use of the following bash command:

curl 'http://localhost:8983/solr/update' -d @hd.xml -H 'Content-type:application/xml'
Of course I did not send the commit operation after indexing. As we could expect the following query:

http://localhost:8983/solr/select?q=*:*
didn't return search results. So let's check, if the handler registered as /get will be able to get us some results. In order to do that I send the following query:

http://localhost:8983/solr/get?id=SP2514N
And in result I got the following document:

<?xml version="1.0" encoding="UTF-8"?>
<response>
<doc name="doc">
  <str name="id">SP2514N</str>
  <str name="name">Samsung SpinPoint P120 SP2514N - hard drive - 250 GB - ATA-133</str>
  <str name="manu">Samsung Electronics Co. Ltd.</str>
  <str name="manu_id_s">samsung</str>
  <arr name="cat">
    <str>electronics</str>
    <str>hard drive</str>
  </arr>
  <arr name="features">
    <str>7200RPM, 8MB cache, IDE Ultra ATA-133</str>
    <str>NoiseGuard, SilentSeek technology, Fluid Dynamic Bearing (FDB) motor</str>
  </arr>
  <float name="price">92.0</float>
  <int name="popularity">6</int>
  <bool name="inStock">true</bool>
  <date name="manufacturedate_dt">2006-02-13T15:26:37Z</date>
  <str name="store">35.0752,-97.032</str></doc>
</response>
So Solr returned the result that wasn't added to the index - nice !
Usage possibilities
You probably noticed, that in order to fetch a document with /get handler I needed to provide it's unique identifier (or identifiers list). That's true, Realtime Get doesn't support searching, because it was not created to support full searching. This functionality is able to show us the updates of the documents which identifiers are known (so for example the ones in the index) - in example by adding the component used in solr.RealTimeGetHandler to any of your defined handler. And the good news is - you don't have to worry update performance - solr.RealTimeGet is very fast. So, if one of your problems is frequent updated you can look in the future with a smile 
Last few words
The Realtime Get functionality brings new possibilities when it comes to Solr and also on the road to the SolrCloud. With the use of transaction log one can implement automatic cluster node restore or instance NRT instance updates. As you can see Solr 4.0 is not only about search, but also about data store and bringing Solr closer to NoSQL solutions.
{solr.data.dir:}</str>

</updateLog>
The above entry says, that the directory holding transaction log will be located in the same directory where the index directory is located.
Realtime Get handler
The second thing that needs to be done, to see the Realtime Get in action, is the appropriate handler configuration (or adding component to your already defined handler). To do that add the following to your solrconfig.xml file:


The above entry it’s nothing unusual – it just add a new request handler implementing solr.RealTimeGetHandler class, which enables checking the transaction log.
Action
To check how Realtime Get works I decided to do a simple test. The first thing I did is indexing one file (from the ones that are available in the exampledocs directory) with the use of the following bash command:


Of course I did not send the commit operation after indexing. As we could expect the following query:


didn’t return search results. So let’s check, if the handler registered as /get will be able to get us some results. In order to do that I send the following query:


And in result I got the following document:


So Solr returned the result that wasn’t added to the index – nice !
Usage possibilities
You probably noticed, that in order to fetch a document with /get handler I needed to provide it’s unique identifier (or identifiers list). That’s true, Realtime Get doesn’t support searching, because it was not created to support full searching. This functionality is able to show us the updates of the documents which identifiers are known (so for example the ones in the index) – in example by adding the component used in solr.RealTimeGetHandler to any of your defined handler. And the good news is – you don’t have to worry update performance – solr.RealTimeGet is very fast. So, if one of your problems is frequent updated you can look in the future with a smile 
Last few words
The Realtime Get functionality brings new possibilities when it comes to Solr and also on the road to the SolrCloud. With the use of transaction log one can implement automatic cluster node restore or instance NRT instance updates. As you can see Solr 4.0 is not only about search, but also about data store and bringing Solr closer to NoSQL solutions.
]]>
					
					https://solr.pl/en/2012/01/09/solr-4-0-realtime-get/feed/
			0