The goal of this page is to design/describe a more flexible indexing scheme for Lucene, as first described in #11 of Lucene2Whiteboard.

Since this is a significant change to Lucene and will require some planning, this page is intended to be the starting point of the design until some patches can be worked out.

There are currently two main areas of interest in regards to flexible indexing:

1. API for flexible Posting (indexing) options. Preliminary options, as detailed in ConversationsBetweenDougMarvinAndGrant, are:

a. <doc>+

b. <doc, boost>+

c. <doc, freq, <position>+ >+

d. <doc, freq, <position, boost>+ >+

These suggest the following booleans per field:

1. freq

2. document boost

3. position (requires freq)

4. position boost (requires position)

2. Storing Index level metadata. This can be useful for storing information about the index, such as display name, internal name, name of analyzer used (if appropriate), collection statistics outside the scope of the index itself.

Planning

ConversationsBetweenDougMarvinAndGrant

Flexible indexing implemented in 4.0-dev (trunk)

This section describes the changes committed to 4.0-dev under LUCENE-1458 and LUCENE-2111.

The overall goal is to make Lucene extensible, even at its lowest levels, on what it records into the index, and how. Your app should be able to easily store new things into the index, or, alter how existing things (doc IDs, positions, payloads, etc.) are encoded. To accomplish this, a Codec class was introduced. The Codec currently covers the postings API (fields, terms, docs, positions+payloads enumerators); other elements in the index (norms, deleted docs, stored docs/fields, term vectors) are not covered.

Changes in how postings are consumed

The first big change in flexible indexing is the consumption of the postings enumerators APIs:

Codec/CodecProvider

The second big change in flexible indexing is the Codec and CodecProvider APIs that enables apps to plug in different implementations for writing and reading postings data in the index. When you obtain an IndexWriter or IndexReader, you can optionally pass in a CodecProvider, which knows 1) which Codec should be used when writing a new segment, and 2) how to resolve the codec name (String) to a Codec instance, when reading from the index.

The default codec is StandardCodec, whose format is similar to the pre-4.0 index format, but introduces sizable improvements to how the terms index is stored. In particular the RAM required by the terms index when reading a segment has been substantially reduced. The on-disk format of the .tis/.tii files is also slightly smaller.

There are some experimental core codecs:

LUCENE-1410 has a prototype PforDelta codec, an int block codec using PFOR-DELTA encoding.

Apps can also create custom Codecs. Please report back if you do! All of these APIs are very new and need some good baking in time.