org.apache.lucene.index
Class IndexWriter

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.

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 setMaxBufferedDeleteTerms(int))
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 setRAMBufferSizeMB(double)) 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. Note that flushing just moves the
internal buffered state in IndexWriter into the index, but
these changes are not visible to IndexReader until either
commit() or close() is called. 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).

If an index will not have more documents added for a while and optimal search
performance is desired, then either the full optimize
method or partial optimize(int) 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.

NOTE: if you hit an
OutOfMemoryError then IndexWriter will quietly record this
fact and block all future segment commits. This is a
defensive measure in case any internal state (buffered
documents and deletions) were corrupted. Any subsequent
calls to commit() will throw an
IllegalStateException. The only course of action is to
call close(), which internally will call rollback(), to undo any changes to the index since the
last commit. You can also just call rollback()
directly.

NOTE: IndexWriter instances are completely thread
safe, meaning multiple threads can call any of its
methods, concurrently. If your application requires
external synchronization, you should not
synchronize on the IndexWriter instance as
this may cause deadlock; use your own (non-Lucene) objects
instead.

NOTE: If you call
Thread.interrupt() on a thread that's within
IndexWriter, IndexWriter will try to catch this (eg, if
it's in a wait() or Thread.sleep()), and will then throw
the unchecked exception ThreadInterruptedException
and clear the interrupt status on the thread.

Nested Class Summary

static class

IndexWriter.IndexReaderWarmer
If getReader() has been called (ie, this writer
is in near real-time mode), then after a merge
completes, this class can be invoked to warm the
reader on the newly merged segment, before the merge
commits.

close()
Commits all changes to an index and closes all
associated files.

void

close(boolean waitForMerges)
Closes the index with or without waiting for currently
running merges to finish.

void

commit()
Commits all pending changes (added & deleted
documents, optimizations, segment merges, added
indexes, etc.) to the index, and syncs all referenced
index files, such that a reader will see the changes
and the index updates will survive an OS or machine
crash or power loss.

doAfterFlush()
A hook for extending classes to execute operations after pending added and
deleted documents have been flushed to the Directory but before the change
is committed (new segments_N file written).

protected void

doBeforeFlush()
A hook for extending classes to execute operations before pending added and
deleted documents are flushed to the Directory.

isLocked(Directory directory)
Returns true iff the index in the named directory is
currently locked.

int

maxDoc()
Returns total number of docs in this index, including
docs not yet flushed (still in the RAM buffer),
not counting deletions.

void

maybeMerge()
Expert: asks the mergePolicy whether any merges are
necessary now and if so, runs the requested merges and
then iterate (test again if merges are needed) until no
more merges are returned by the mergePolicy.

void

message(String message)
Prints a message to the infoStream (if non-null),
prefixed with the identifying information for this
writer and the thread that's calling it.

DEFAULT_TERM_INDEX_INTERVAL

MAX_TERM_LENGTH

public static final int MAX_TERM_LENGTH

Absolute hard maximum length for a term. If a term
arrives from the analyzer longer than this length, it
is skipped and a message is printed to infoStream, if
set (see setInfoStream(java.io.PrintStream)).

IndexWriter

Expert: constructs an IndexWriter with a custom IndexDeletionPolicy, for the index in d.
Text will be analyzed with a. If
create is true, then a new, empty index
will be created in d, replacing the index
already there, if any.

Parameters:

d - the index directory

a - the analyzer to use

create - true to create the index or overwrite
the existing one; false to append to the existing
index

IndexWriter

Expert: constructs an IndexWriter on specific commit
point, with a custom IndexDeletionPolicy, for
the index in d. Text will be analyzed
with a.

This is only meaningful if you've used a IndexDeletionPolicy in that past that keeps more than
just the last commit.

This operation is similar to rollback(),
except that method can only rollback what's been done
with the current instance of IndexWriter since its last
commit, whereas this method can rollback to an
arbitrary commit point from the past, assuming the
IndexDeletionPolicy has preserved past
commits.

getReader

Expert: returns a readonly reader, covering all
committed as well as un-committed changes to the index.
This provides "near real-time" searching, in that
changes made during an IndexWriter session can be
quickly made available for searching without closing
the writer nor calling commit(long).

You must close the IndexReader returned by
this method once you are done using it.

It's near real-time because there is no hard
guarantee on how quickly you can get a new reader after
making changes with IndexWriter. You'll have to
experiment in your situation to determine if it's
fast enough. As this is a new and experimental
feature, please report back on your findings so we can
learn, improve and iterate.

The resulting reader supports IndexReader.reopen(), but that call will simply forward
back to this method (though this may change in the
future).

The very first time this method is called, this
writer instance will make every effort to pool the
readers that it opens for doing merges, applying
deletes, etc. This means additional resources (RAM,
file descriptors, CPU time) will be consumed.

getReader

Expert: like getReader(), except you can
specify which termInfosIndexDivisor should be used for
any newly opened readers.

Parameters:

termInfosIndexDivisor - Subsamples which indexed
terms are loaded into RAM. This has the same effect as setTermIndexInterval(int) except that setting
must be done at indexing time while this setting can be
set per reader. When set to N, then one in every
N*termIndexInterval terms in the index is loaded into
memory. By setting this to a value > 1 you can reduce
memory usage, at the expense of higher latency when
loading a TermInfo. The default value is 1. Set this
to -1 to skip loading the terms index entirely.

ensureOpen

message

Prints a message to the infoStream (if non-null),
prefixed with the identifying information for this
writer and the thread that's calling it.

getUseCompoundFile

public boolean getUseCompoundFile()

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.

getSimilarity

setTermIndexInterval

public void setTermIndexInterval(int interval)

Expert: Set the interval between indexed terms. Large values cause less
memory to be used by IndexReader, but slow random-access to terms. Small
values cause more memory to be used by an IndexReader, and speed
random-access to terms.
This parameter determines the amount of computation required per query
term, regardless of the number of documents that contain that term. In
particular, it is the maximum number of other terms that must be
scanned before a term is located and its frequency and position information
may be processed. In a large index with user-entered query terms, query
processing time is likely to be dominated not by term lookup but rather
by the processing of frequency and positional data. In a small index
or when many uncommon query terms are generated (e.g., by wildcard
queries) term lookup may become a dominant cost.
In particular, numUniqueTerms/interval terms are read into
memory by an IndexReader, and, on average, interval/2 terms
must be scanned for each random term access.

getMergeScheduler

setMaxMergeDocs

public void setMaxMergeDocs(int maxMergeDocs)

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.

setMaxFieldLength

public void setMaxFieldLength(int maxFieldLength)

The maximum number of terms that will be indexed for a single field in a
document. This limits the amount of memory required for indexing, so that
collections with very large files will not crash the indexing process by
running out of memory. This setting refers to the number of running terms,
not to the number of different terms.

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.

getReaderTermsIndexDivisor

setMaxBufferedDocs

Determines the minimal number of documents required
before the buffered in-memory documents are flushed as
a new Segment. Large values generally gives faster
indexing.

When this is set, the writer will flush every
maxBufferedDocs added documents. Pass in 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).

Throws:

IllegalArgumentException - if maxBufferedDocs is
enabled but smaller than 2, or it disables maxBufferedDocs
when ramBufferSize is already disabled

getMaxBufferedDocs

setRAMBufferSizeMB

public void setRAMBufferSizeMB(double mb)

Determines the amount of RAM that may be used for
buffering added documents and deletions before they are
flushed to the Directory. Generally for faster
indexing performance it's best to flush by RAM usage
instead of document count and use as large a RAM buffer
as you can.

When this is set, the writer will flush whenever
buffered documents and deletions use this much RAM.
Pass in 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.

NOTE: the account of RAM usage for pending
deletions is only approximate. Specifically, if you
delete by Query, Lucene currently has no way to measure
the RAM usage if individual Queries so the accounting
will under-estimate and you should compensate by either
calling commit() periodically yourself, or by using
setMaxBufferedDeleteTerms(int) to flush by count
instead of RAM usage (each buffered delete Query counts
as one).

NOTE: because IndexWriter uses
ints when managing its internal storage,
the absolute maximum value for this setting is somewhat
less than 2048 MB. The precise limit depends on
various factors, such as how large your documents are,
how many fields have norms, etc., so it's best to set
this value comfortably under 2048.

getRAMBufferSizeMB

setMaxBufferedDeleteTerms

public void setMaxBufferedDeleteTerms(int maxBufferedDeleteTerms)

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.

getMaxBufferedDeleteTerms

setMergeFactor

public void setMergeFactor(int mergeFactor)

Determines how often segment indices are merged by addDocument(). With
smaller values, less RAM is used while indexing, and searches on
unoptimized indices are faster, but indexing speed is slower. With larger
values, more RAM is used during indexing, and while searches on unoptimized
indices are slower, indexing is faster. Thus larger values (> 10) are best
for batch index creation, and smaller values (< 10) for indices that are
interactively maintained.

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.

getMergeFactor

public int getMergeFactor()

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.

close

Commits all changes to an index and closes all
associated files. Note that this may be a costly
operation, so, try to re-use a single writer instead of
closing and opening a new one. See commit() for
caveats about write caching done by some IO devices.

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:

close

Closes the index with or without waiting for currently
running merges to finish. This is only meaningful when
using a MergeScheduler that runs merges in background
threads.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer, again. See above for details.

NOTE: it is dangerous to always call
close(false), especially when IndexWriter is not open
for very long, because this can result in "merge
starvation" whereby long merges will never have a
chance to finish. This will cause too many segments in
your index over time.

Parameters:

waitForMerges - if true, this call will block
until all merges complete; else, it will ask all
running merges to abort, wait until those merges have
finished (which should be at most a few seconds), and
then return.

numDocs

Returns total number of docs in this index, including
docs not yet flushed (still in the RAM buffer), and
including deletions. NOTE: buffered deletions
are not counted. If you really need these to be
counted you should call commit() first.

hasDeletions

addDocument

Adds a document to this index. If the document contains more than
setMaxFieldLength(int) terms for a given field, the remainder are
discarded.

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 (see above), and
also periodically triggers segment merges in the index
according to the MergePolicy in use.

Merges temporarily consume space in the
directory. The amount of space required 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
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.

Note that it's possible to create an invalid Unicode
string in java if a UTF16 surrogate pair is malformed.
In this case, the invalid characters are silently
replaced with the Unicode replacement character
U+FFFD.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

addDocument

Adds a document to this index, using the provided analyzer instead of the
value of getAnalyzer(). If the document contains more than
setMaxFieldLength(int) terms for a given field, the remainder are
discarded.

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

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

updateDocument

Updates a document by first deleting the document(s)
containing term and then adding the new
document. The delete and then add are atomic as seen
by a reader on the same index (flush may happen only after
the add).

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

updateDocument

Updates a document by first deleting the document(s)
containing term and then adding the new
document. The delete and then add are atomic as seen
by a reader on the same index (flush may happen only after
the add).

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

optimize

Requests an "optimize" operation on an index, priming the index
for the fastest available search. Traditionally this has meant
merging all segments into a single segment as is done in the
default merge policy, but individual merge policies may implement
optimize in different ways.

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

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

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

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

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

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

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

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

optimize

Just like optimize(int), except you can
specify whether the call should block until the
optimize completes. This is only meaningful with a
MergeScheduler that is able to run merges in
background threads.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

expungeDeletes

Just like expungeDeletes(), except you can
specify whether the call should block until the
operation completes. This is only meaningful with a
MergeScheduler that is able to run merges in
background threads.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

expungeDeletes

Expunges all deletes from the index. When an index
has many document deletions (or updates to existing
documents), it's best to either call optimize or
expungeDeletes to remove all unused data in the index
associated with the deleted documents. To see how
many deletions you have pending in your index, call
IndexReader.numDeletedDocs()
This saves disk space and memory usage while
searching. expungeDeletes should be somewhat faster
than optimize since it does not insist on reducing the
index to a single segment (though, this depends on the
MergePolicy; see MergePolicy.findMergesToExpungeDeletes(org.apache.lucene.index.SegmentInfos).). Note that
this call does not first commit any buffered
documents, so you must do so yourself if necessary.
See also expungeDeletes(boolean)

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

maybeMerge

Expert: asks the mergePolicy whether any merges are
necessary now and if so, runs the requested merges and
then iterate (test again if merges are needed) until no
more merges are returned by the mergePolicy.
Explicit calls to maybeMerge() are usually not
necessary. The most common case is when merge policy
parameters have changed.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

rollback

Close the IndexWriter without committing
any changes that have occurred since the last commit
(or since it was opened, if commit hasn't been called).
This removes any temporary files that had been created,
after which the state of the index will be the same as
it was when commit() was last called or when this
writer was first opened. This also clears a previous
call to prepareCommit().

deleteAll

This method will drop all buffered documents and will
remove all segments from the index. This change will not be
visible until a commit() has been called. This method
can be rolled back using rollback().

NOTE: this method is much faster than using deleteDocuments( new MatchAllDocsQuery() ).

addIndexesNoOptimize

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.

NOTE: while this is running, any attempts to
add or delete documents (with another thread) will be
paused until this method completes.

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.

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 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.

This requires this index not be among those to be added.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

prepareCommit

Expert: prepare for commit, specifying
commitUserData Map (String -> String). This does the
first phase of 2-phase commit. This method does all
steps necessary to commit changes since this writer
was opened: flushes pending added and deleted docs,
syncs the index files, writes most of next segments_N
file. After calling this you must call either commit() to finish the commit, or rollback() to revert the commit and undo all changes
done since the writer was opened.

You can also just call commit(Map) directly
without prepareCommit first in which case that method
will internally call prepareCommit.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.

Parameters:

commitUserData - Opaque Map (String->String)
that's recorded into the segments file in the index,
and retrievable by IndexReader.getCommitUserData(org.apache.lucene.store.Directory). Note that when
IndexWriter commits itself during close(), the
commitUserData is unchanged (just carried over from
the prior commit). If this is null then the previous
commitUserData is kept. Also, the commitUserData will
only "stick" if there are actually changes in the
index to commit.

commit

Commits all pending changes (added & deleted
documents, optimizations, segment merges, added
indexes, etc.) to the index, and syncs all referenced
index files, such that a reader will see the changes
and the index updates will survive an OS or machine
crash or power loss. Note that this does not wait for
any running background merges to finish. This may be a
costly operation, so you should test the cost in your
application and do it only when really necessary.

Note that this operation calls Directory.sync on
the index files. That call should not return until the
file contents & metadata are on stable storage. For
FSDirectory, this calls the OS's fsync. But, beware:
some hardware devices may in fact cache writes even
during fsync, and return before the bits are actually
on stable storage, to give the appearance of faster
performance. If you have such a device, and it does
not have a battery backup (for example) then on power
loss it may still lose data. Lucene cannot guarantee
consistency on such devices.

NOTE: if this method hits an OutOfMemoryError
you should immediately close the writer. See above for details.