These are the recipes we are going to cover in this chapter:
Using the DirectoryReader to open index in Near Real-time
Using the SearcherManager to refresh IndexSearcher
Generational indexing with TrackingIndexWriter
Maintaining search sessions with SearcherLifetimeManager
Performance tuning: latency and throughput
In some search applications, it may be necessary to immediately expose any changes made to the index to attain the best user experience. For example, such applications can be forums where a user may search for his/her newly edited post to confirm that the submission is successful and see how it ranked in the search results. If the application is database-backed, post-edit searches will always be able to bring back the submitted post as index updates, and searches are mostly real-time in a single database environment, assuming reads and writes are on the same table. However, performance can take a toll if changes are frequent and the search volume is high because frequent updates can cause high IO load, which in turn contributes to performance issues. Performing a lot of searches on a frequently updated table is not ideal as collisions between read and write requests are bound to happen and updates can block read requests. The read requests backlog can queue up to a point where...
First of all, let's cover the basics. The DirectoryReader attribute that we are already familiar with actually allows you to open an index with IndexWriter with the option to include uncommitted changes. This gives you a point-in-time snapshot of the index, including any updates that are not committed yet. In a typical search application, IndexSearcher would need to be reopened periodically anyway to expose recent updates. This feature provides an option to immediately expose index updates without waiting for IndexWriter to commit first. Potentially, the search application may have to maintain multiple IndexSearchers as depicted in the following diagram:
One use case for this feature is that users may want to review their recently submitted content to see how it ranked in search results. To provide the most up-to-date index after a user submits an update, we can open a new IndexSearcher with uncommitted changes to serve queries while...
The SearcherManager is a utility class that facilitates the sharing of IndexSearcher across multiple threads. It provides the facilities to acquire and release IndexSearcher, while allowing IndexSearcher to be reopened periodically. The IndexSearcher attribute can be refreshed by calling maybeRefresh prior to acquire, though it's recommended that this method be called periodically in a separate thread to minimize impacting a query that happens to trigger a refresh. Note that it's very important to call release so SearcherManager knows when IndexSearcher is not in use so that it can be closed for a refresh.
The following diagram shows SearcherManager's main responsibilities:
The SearcherManager's constructor takes three arguments: an IndexWriter, a Boolean indicating whether to apply uncommitted deletes, and a SearcherFactory. In our example, we will use the built-in SearcherFactory. The SearcherFactory object can be extended to include custom...
A generation is analogous to versioning in a revision control system. In TrackingIndexWriter, when an index changes, a new generation is created and can be used to open the index in that particular point in time. TrackingIndexWriter is a wrapper class to IndexWriter. It provides the corresponding addDocument, updateDocument, and deleteDocument methods to keep a track of index changes. On each update, a long value is returned, reflecting the current index generation. This value can be used to acquire an IndexSearcher that includes all the updates up to this specific point (generation). This class is intended to run alongside with ControlledRealTimeReopenThread. The ControlledRealTimeReopenThread is a utility class that runs as a separate thread managing the periodic reopening of the IndexSearcher. It accepts the TrackingIndexWriter and SearcherManager in its constructor to initialize this object. The generation value returned from TrackingIndexWriter...
This is another utility class that Lucene provides out of the box, providing a facility to manage multiple IndexSearchers. Why do we need multiple IndexSearchers? Let's imagine we have multiple users in a high traffics NRT search application, searching concurrently. Also, let's assume that some of these users are also submitting changes to the index at the same time. If we periodically refresh our IndexSearcher for a NRT search, we will likely encounter a scenario where a user is paginating through a result set and at the same time, the index is updated affecting the search result. The effect can be minimal if the newly added/updated content is irrelevant to the current search terms. However, if the new content has any relevancy to the current search, the search result rankings will change. The user may see repeated results between the pages as user paginating. To ensure a good user experience, we should reuse the same IndexSearcher...
Search latency is the measure of time between the start of a query and the delivery of a search result. Throughput is the number of actions the system can sustain in a given time period. Ideally, we want latency to be one second or less and throughput, obviously, to be as high as possible. Both of these measurements are important factors in determining your hardware needs and infrastructure design.
Latency and throughput are correlated; both depend heavily on the available system resources, for example, CPU, IO, memory, and so on. In a single instance, lower latency will naturally increase throughput. When lowering latency is not attainable, we will have to resort to add more hardware to boost the number of instances to serve concurrently. Hardware sizing, at this point, will be a simple math of the desired throughput divided by a single instance's throughput to determine the number of servers that are needed for the search.
© 2015 Packt Publishing Limited All Rights Reserved
