Java Doc for IndexWriter.java in  » Search-Engine » lucene » org » apache » lucene » index » Java Source Code / Java DocumentationJava Source Code and Java Documentation

The create argument to the constructor determines whether a new index is created, or whether an existing index is opened. Note that you can open an index with create=true even while readers are using the index. The old readers will continue to search the "point in time" snapshot they had opened, and won't see the newly created index until they re-open. There are also constructors with no create argument which will create a new index if there is not already an index at the provided path and otherwise open the existing index.

In either case, documents are added with addDocument and removed with deleteDocuments. A document can be updated with updateDocument (which just deletes and then adds the entire document). When finished adding, deleting and updating documents, close should be called.

These changes are buffered in memory and periodically flushed to the Directory (during the above method calls). A flush is triggered when there are enough buffered deletes (see IndexWriter.setMaxBufferedDeleteTerms ) or enough added documents since the last flush, whichever is sooner. For the added documents, flushing is triggered either by RAM usage of the documents (see IndexWriter.setRAMBufferSizeMB ) or the number of added documents. The default is to flush when RAM usage hits 16 MB. For best indexing speed you should flush by RAM usage with a large RAM buffer. You can also force a flush by calling IndexWriter.flush . When a flush occurs, both pending deletes and added documents are flushed to the index. A flush may also trigger one or more segment merges which by default run with a background thread so as not to block the addDocument calls (see below for changing the MergeScheduler ).

The optional autoCommit argument to the constructors controls visibility of the changes to IndexReader instances reading the same index. When this is false, changes are not visible until IndexWriter.close() is called. Note that changes will still be flushed to the org.apache.lucene.store.Directory as new files, but are not committed (no new segments_N file is written referencing the new files) until IndexWriter.close is called. If something goes terribly wrong (for example the JVM crashes) before IndexWriter.close() , then the index will reflect none of the changes made (it will remain in its starting state). You can also call IndexWriter.abort() , which closes the writer without committing any changes, and removes any index files that had been flushed but are now unreferenced. This mode is useful for preventing readers from refreshing at a bad time (for example after you've done all your deletes but before you've done your adds). It can also be used to implement simple single-writer transactional semantics ("all or none").

When autoCommit is true then every flush is also a commit ( IndexReader instances will see each flush as changes to the index). This is the default, to match the behavior before 2.2. When running in this mode, be careful not to refresh your readers while optimize or segment merges are taking place as this can tie up substantial disk space.

Regardless of autoCommit, an IndexReader or org.apache.lucene.search.IndexSearcher will only see the index as of the "point in time" that it was opened. Any changes committed to the index after the reader was opened are not visible until the reader is re-opened.

If an index will not have more documents added for a while and optimal search performance is desired, then the optimize method should be called before the index is closed.

Opening an IndexWriter creates a lock file for the directory in use. Trying to open another IndexWriter on the same directory will lead to a LockObtainFailedException . The LockObtainFailedException is also thrown if an IndexReader on the same directory is used to delete documents from the index.

Expert: IndexWriter allows an optional IndexDeletionPolicy implementation to be specified. You can use this to control when prior commits are deleted from the index. The default policy is KeepOnlyLastCommitDeletionPolicy which removes all prior commits as soon as a new commit is done (this matches behavior before 2.2). Creating your own policy can allow you to explicitly keep previous "point in time" commits alive in the index for some time, to allow readers to refresh to the new commit without having the old commit deleted out from under them. This is necessary on filesystems like NFS that do not support "delete on last close" semantics, which Lucene's "point in time" search normally relies on.

Expert: IndexWriter allows you to separately change the MergePolicy and the MergeScheduler . The MergePolicy is invoked whenever there are changes to the segments in the index. Its role is to select which merges to do, if any, and return a MergePolicy.MergeSpecification describing the merges. It also selects merges to do for optimize(). (The default is LogByteSizeMergePolicy . Then, the MergeScheduler is invoked with the requested merges and it decides when and how to run the merges. The default is ConcurrentMergeScheduler .

This may be used to parallelize batch indexing.

After this completes, the index is optimized.

This is similar to addIndexes(Directory[]).

If an Exception is hit during close, eg due to disk full or some other reason, then both the on-disk index and the internal state of the IndexWriter instance will be consistent.

Returns the largest segment (measured by document count) that may be merged with other segments.

Note that this method is a convenience method: it just calls mergePolicy.getMaxMergeDocs as long as mergePolicy is an instance of LogMergePolicy .

Returns the number of segments that are merged at once and also controls the total number of segments allowed to accumulate in the index.

Note that this method is a convenience method: it just calls mergePolicy.getMergeFactor as long as mergePolicy is an instance of LogMergePolicy .

Get the current setting of whether newly flushed segments will use the compound file format.

Determines the minimal number of delete terms required before the buffered in-memory delete terms are applied and flushed.

Determines the largest segment (measured by document count) that may be merged with other segments. Small values (e.g., less than 10,000) are best for interactive indexing, as this limits the length of pauses while indexing to a few seconds.

Setting to turn on usage of a compound file.

Note that if an Exception is hit (for example disk full) then the index will be consistent, but this document may not have been added. Furthermore, it's possible the index will have one segment in non-compound format even when using compound files (when a merge has partially succeeded).

This method periodically flushes pending documents to the Directory (every IndexWriter.setMaxBufferedDocs ), and also periodically merges segments in the index (every IndexWriter.setMergeFactor flushes). When this occurs, the method will take more time to run (possibly a long time if the index is large), and will require free temporary space in the Directory to do the merging.

The amount of free space required when a merge is triggered is up to 1X the size of all segments being merged, when no readers/searchers are open against the index, and up to 2X the size of all segments being merged when readers/searchers are open against the index (see IndexWriter.optimize() for details). The sequence of primitive merge operations performed is governed by the merge policy.

Note that each term in the document can be no longer than 16383 characters, otherwise an IllegalArgumentException will be thrown.

See IndexWriter.addDocument(Document) for details on index and IndexWriter state after an Exception, and flushing/merging temporary free space requirements.

This may be used to parallelize batch indexing. A large document collection can be broken into sub-collections. Each sub-collection can be indexed in parallel, on a different thread, process or machine. The complete index can then be created by merging sub-collection indexes with this method.

NOTE: the index in each Directory must not be changed (opened by a writer) while this method is running. This method does not acquire a write lock in each input Directory, so it is up to the caller to enforce this.

After this completes, the index is optimized.

This method is transactional in how Exceptions are handled: it does not commit a new segments_N file until all indexes are added. This means if an Exception occurs (for example disk full), then either no indexes will have been added or they all will have been.

If an Exception is hit, it's still possible that all indexes were successfully added. This happens when the Exception is hit when trying to build a CFS file. In this case, one segment in the index will be in non-CFS format, even when using compound file format.

Also note that on an Exception, the index may still have been partially or fully optimized even though none of the input indexes were added.

Note that this requires temporary free space in the Directory up to 2X the sum of all input indexes (including the starting index). If readers/searchers are open against the starting index, then temporary free space required will be higher by the size of the starting index (see IndexWriter.optimize() for details).

Once this completes, the final size of the index will be less than the sum of all input index sizes (including the starting index). It could be quite a bit smaller (if there were many pending deletes) or just slightly smaller.

See LUCENE-702 for details.

After this completes, the index is optimized.

The provided IndexReaders are not closed.

See IndexWriter.addIndexes(Directory[]) for details on transactional semantics, temporary free space required in the Directory, and non-CFS segments on an Exception.

This is similar to addIndexes(Directory[]). However, no optimize() is called either at the beginning or at the end. Instead, merges are carried out as necessary.

NOTE: the index in each Directory must not be changed (opened by a writer) while this method is running. This method does not acquire a write lock in each input Directory, so it is up to the caller to enforce this.

This requires this index not be among those to be added, and the upper bound* of those segment doc counts not exceed maxMergeDocs.

See IndexWriter.addIndexes(Directory[]) for details on transactional semantics, temporary free space required in the Directory, and non-CFS segments on an Exception.

If an Exception is hit during close, eg due to disk full or some other reason, then both the on-disk index and the internal state of the IndexWriter instance will be consistent. However, the close will not be complete even though part of it (flushing buffered documents) may have succeeded, so the write lock will still be held.

If you can correct the underlying cause (eg free up some disk space) then you can call close() again. Failing that, if you want to force the write lock to be released (dangerous, because you may then lose buffered docs in the IndexWriter instance) then you can do something like this:

 try {
 writer.close();
 } finally {
 if (IndexReader.isLocked(directory)) {
 IndexReader.unlock(directory);
 }
 }
 

Note: if autoCommit=false, flushed data would still not be visible to readers, until IndexWriter.close is called.
throws:
  CorruptIndexException - if the index is corrupt
throws:
  IOException - if there is a low-level IO error

Returns the largest segment (measured by document count) that may be merged with other segments.

Note that this method is a convenience method: it just calls mergePolicy.getMaxMergeDocs as long as mergePolicy is an instance of LogMergePolicy . Otherwise an IllegalArgumentException is thrown.

Returns the number of segments that are merged at once and also controls the total number of segments allowed to accumulate in the index.

Note that this method is a convenience method: it just calls mergePolicy.getMergeFactor as long as mergePolicy is an instance of LogMergePolicy . Otherwise an IllegalArgumentException is thrown.

This defaults to the current value of Similarity.getDefault .

Get the current setting of whether newly flushed segments will use the compound file format. Note that this just returns the value previously set with setUseCompoundFile(boolean), or the default value (true). You cannot use this to query the status of previously flushed segments.

Note that this method is a convenience method: it just calls mergePolicy.getUseCompoundFile as long as mergePolicy is an instance of LogMergePolicy . Otherwise an IllegalArgumentException is thrown.

It is recommended that this method be called upon completion of indexing. In
See Also:   environments with frequent updates, optimize is best done during low volume times, if at all.
See Also:   

See http://www.gossamer-threads.com/lists/lucene/java-dev/47895 for more discussion.

Note that this can require substantial temporary free
See Also:   space in the Directory (see See Also:   href="http://issues.apache.org/jira/browse/LUCENE-764">LUCENE-764
See Also:   for details):

See Also:   
• 
  See Also:   

  If no readers/searchers are open against the index,
  See Also:   then free space required is up to 1X the total size of
  See Also:   the starting index. For example, if the starting
  See Also:   index is 10 GB, then you must have up to 10 GB of free
  See Also:   space before calling optimize.

  
  See Also:   
• 
  See Also:   

  If readers/searchers are using the index, then free
  See Also:   space required is up to 2X the size of the starting
  See Also:   index. This is because in addition to the 1X used by
  See Also:   optimize, the original 1X of the starting index is
  See Also:   still consuming space in the Directory as the readers
  See Also:   are holding the segments files open. Even on Unix,
  See Also:   where it will appear as if the files are gone ("ls"
  See Also:   won't list them), they still consume storage due to
  See Also:   "delete on last close" semantics.

  
  See Also:   

  Furthermore, if some but not all readers re-open
  See Also:   while the optimize is underway, this will cause > 2X
  See Also:   temporary space to be consumed as those new readers
  See Also:   will then hold open the partially optimized segments at
  See Also:   that time. It is best not to re-open readers while
  See Also:   optimize is running.

  
  See Also:   

The actual temporary usage could be much less than
See Also:   these figures (it depends on many factors).

In general, once the optimize completes, the total size of the
See Also:   index will be less than the size of the starting index.
See Also:   It could be quite a bit smaller (if there were many
See Also:   pending deletes) or just slightly smaller.

If an Exception is hit during optimize(), for example
See Also:   due to disk full, the index will not be corrupt and no
See Also:   documents will have been lost. However, it may have
See Also:   been partially optimized (some segments were merged but
See Also:   not all), and it's possible that one of the segments in
See Also:   the index will be in non-compound format even when
See Also:   using compound file format. This will occur when the
See Also:   Exception is hit during conversion of the segment into
See Also:   compound format.

This call will optimize those segments present in
See Also:   the index when the call started. If other threads are
See Also:   still adding documents and flushing segments, those
See Also:   newly created segments will not be optimized unless you
See Also:   call optimize again.

Determines the minimal number of delete terms required before the buffered in-memory delete terms are applied and flushed. If there are documents buffered in memory at the time, they are merged and a new segment is created.

Disabled by default (writer flushes by RAM usage).

When this is set, the writer will flush every maxBufferedDocs added documents. Pass in IndexWriter.DISABLE_AUTO_FLUSH to prevent triggering a flush due to number of buffered documents. Note that if flushing by RAM usage is also enabled, then the flush will be triggered by whichever comes first.

Disabled by default (writer flushes by RAM usage).

Note: this silently truncates large documents, excluding from the index all terms that occur further in the document. If you know your source documents are large, be sure to set this value high enough to accomodate the expected size. If you set it to Integer.MAX_VALUE, then the only limit is your memory, but you should anticipate an OutOfMemoryError.

By default, no more than 10,000 terms will be indexed for a field.

Determines the largest segment (measured by document count) that may be merged with other segments. Small values (e.g., less than 10,000) are best for interactive indexing, as this limits the length of pauses while indexing to a few seconds. Larger values are best for batched indexing and speedier searches.

The default value is Integer.MAX_VALUE .

Note that this method is a convenience method: it just calls mergePolicy.setMaxMergeDocs as long as mergePolicy is an instance of LogMergePolicy . Otherwise an IllegalArgumentException is thrown.

The default merge policy ( LogByteSizeMergePolicy ) also allows you to set this limit by net size (in MB) of the segment, using LogByteSizeMergePolicy.setMaxMergeMB .

Note that this method is a convenience method: it just calls mergePolicy.setMergeFactor as long as mergePolicy is an instance of LogMergePolicy . Otherwise an IllegalArgumentException is thrown.

This must never be less than 2. The default value is 10.

When this is set, the writer will flush whenever buffered documents use this much RAM. Pass in IndexWriter.DISABLE_AUTO_FLUSH to prevent triggering a flush due to RAM usage. Note that if flushing by document count is also enabled, then the flush will be triggered by whichever comes first.

The default value is IndexWriter.DEFAULT_RAM_BUFFER_SIZE_MB .

Setting to turn on usage of a compound file. When on, multiple files for each segment are merged into a single file when a new segment is flushed.

Note that this method is a convenience method: it just calls mergePolicy.setUseCompoundFile as long as mergePolicy is an instance of LogMergePolicy . Otherwise an IllegalArgumentException is thrown.