Document-Ids and Merges

Document-Ids and Merges

Hi all,

I have a search application with 16 million documents that uses custom
scores per document using a ValueSource. These values are updated a lot
(and sometimes all at once), so I can't really write them into the index
for performance reasons. Instead, I simply have a huge array of float
values in memory and use the document ID as index in the array.
This works great as long as the index is not changed, but as soon as I
have a few new documents and deletions, index segments are merged (I
suppose) and the document IDs of existing documents change. Is there any
way to be informed when document IDs of existing documents change? If
so, is there a way to calculate the new document ID from the old one, so
I can "convert" my array to the new document IDs?

Re: Document-Ids and Merges

In general how Lucene assigns docIDs is a volatile implementation
detail: it's free to change from release to release.

Eg, the default merge policy (TieredMergePolicy) merges out-of-order
segments. Another eg: at one point, IndexSearcher re-ordered the
segments on init. Another: because ConcurrentMergeScheduler runs
different merges in different threads, they can finish in different of
orders and thus alter how subsequent merges are selected.

Really it's best if you assign your own (app-level) ID field and use
that, if you need a stable ID.

> Hi all,
>
> I have a search application with 16 million documents that uses custom
> scores per document using a ValueSource. These values are updated a lot (and
> sometimes all at once), so I can't really write them into the index for
> performance reasons. Instead, I simply have a huge array of float values in
> memory and use the document ID as index in the array.
> This works great as long as the index is not changed, but as soon as I have
> a few new documents and deletions, index segments are merged (I suppose) and
> the document IDs of existing documents change. Is there any way to be
> informed when document IDs of existing documents change? If so, is there a
> way to calculate the new document ID from the old one, so I can "convert" my
> array to the new document IDs?
>
> Any help would be greatly appreciated!
>
> Best regards,
> Christoph
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>

> Hi all,
>
> I have a search application with 16 million documents that uses custom
> scores per document using a ValueSource. These values are updated a lot
> (and sometimes all at once), so I can't really write them into the index
> for performance reasons. Instead, I simply have a huge array of float
> values in memory and use the document ID as index in the array.
> This works great as long as the index is not changed, but as soon as I
> have a few new documents and deletions, index segments are merged (I
> suppose) and the document IDs of existing documents change. Is there any
> way to be informed when document IDs of existing documents change? If so,
> is there a way to calculate the new document ID from the old one, so I can
> "convert" my array to the new document IDs?
>
> Any help would be greatly appreciated!
>
> Best regards,
> Christoph
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: java-user-unsubscribe@lucene.**apache.org<[hidden email]>
> For additional commands, e-mail: [hidden email].**org<[hidden email]>
>
>

Re: Document-Ids and Merges

Hi Shai,

That sounds interesting. However, I am unsure how I can do this. Is
there a way to store values "with a segment"? How can I get the segment
from a document ID?
Here is how my ValueSource looks like at the moment:

> Or ... move to use a per-segment array. Then you don't need to rely on doc
> IDs changing. You will need to build the array from the documents that are
> in that segment only.
>
> It's like FieldCache in a way. The array is relevant as long as the segment
> exists (i.e. not merged away).
>
> Hope this helps.
>
> Shai
> On Mar 27, 2012 9:29 AM, "Christoph Kaser"<[hidden email]> wrote:
>
>> Hi all,
>>
>> I have a search application with 16 million documents that uses custom
>> scores per document using a ValueSource. These values are updated a lot
>> (and sometimes all at once), so I can't really write them into the index
>> for performance reasons. Instead, I simply have a huge array of float
>> values in memory and use the document ID as index in the array.
>> This works great as long as the index is not changed, but as soon as I
>> have a few new documents and deletions, index segments are merged (I
>> suppose) and the document IDs of existing documents change. Is there any
>> way to be informed when document IDs of existing documents change? If so,
>> is there a way to calculate the new document ID from the old one, so I can
>> "convert" my array to the new document IDs?
>>
>> Any help would be greatly appreciated!
>>
>> Best regards,
>> Christoph
>>
>> ------------------------------**------------------------------**---------
>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.**apache.org<[hidden email]>
>> For additional commands, e-mail: [hidden email].**org<[hidden email]>
>>
>>

Re: Document-Ids and Merges

That's too bad. I thought of using my own ID-field, but I wanted to save
the additional indirection (from docId to my ID to my value).
Do document IDs remain constant for one IndexReader as long as it isn't
reopened? If so, I could precalculate the indirection.

Best regards,
Christoph

Am 27.03.2012 18:15, schrieb Michael McCandless:

> In general how Lucene assigns docIDs is a volatile implementation
> detail: it's free to change from release to release.
>
> Eg, the default merge policy (TieredMergePolicy) merges out-of-order
> segments. Another eg: at one point, IndexSearcher re-ordered the
> segments on init. Another: because ConcurrentMergeScheduler runs
> different merges in different threads, they can finish in different of
> orders and thus alter how subsequent merges are selected.
>
> Really it's best if you assign your own (app-level) ID field and use
> that, if you need a stable ID.
>
> Mike McCandless
>
> http://blog.mikemccandless.com>
> On Tue, Mar 27, 2012 at 3:29 AM, Christoph Kaser
> <[hidden email]> wrote:
>> Hi all,
>>
>> I have a search application with 16 million documents that uses custom
>> scores per document using a ValueSource. These values are updated a lot (and
>> sometimes all at once), so I can't really write them into the index for
>> performance reasons. Instead, I simply have a huge array of float values in
>> memory and use the document ID as index in the array.
>> This works great as long as the index is not changed, but as soon as I have
>> a few new documents and deletions, index segments are merged (I suppose) and
>> the document IDs of existing documents change. Is there any way to be
>> informed when document IDs of existing documents change? If so, is there a
>> way to calculate the new document ID from the old one, so I can "convert" my
>> array to the new document IDs?
>>
>> Any help would be greatly appreciated!
>>
>> Best regards,
>> Christoph
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]>> For additional commands, e-mail: [hidden email]>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>
>

Re: Document-Ids and Merges

If you are working with trunk, then I believe that ValUes is what you're
looking for. They allow you to store values at the document level, and then
read then during search either from disk or RAM. They are also segment
based.

I'm not sure how ValueSource is used (I've never used it myself and I'm not
near the code to check), but what I had in mind is something similar to
Collector.setNextReader which allows Collectors to use, e.g. a float[] for
that IndexReader (hint, look at FieldCache).

If ValueSource or ValueSourceQuery can do that, then you could use that
mechanism. If not, you can move to do the scoring at the Collector level.

Sorry for the shallow responses - I'm answering from my mobile and won't be
near the code potentially until next week. Perhaps someone else on the list
can give you some concrete examples. If not, plz continue to ask questions
and I'll do my best to answer ;).

Re: Document-Ids and Merges

On Wed, Mar 28, 2012 at 3:37 AM, Christoph Kaser
<[hidden email]> wrote:
> Thank you for your answer!
>
> That's too bad. I thought of using my own ID-field, but I wanted to save the
> additional indirection (from docId to my ID to my value).
> Do document IDs remain constant for one IndexReader as long as it isn't
> reopened? If so, I could precalculate the indirection.

Yes, the entire view of the index presented by a single IndexReader is
unchanging (not just docIDs: everything).

On reopen, a new IndexReader is returned, so the old IndexReader is
still unchanged.

So, if you can hold your arrays per-segment, and init them per-segment
(such as FieldCache, or DocValues (only in 4.0) as Shai described)
then you can safely use the docID to index those arrays just within
the context of that segment.

Re: Document-Ids and Merges

Thank you both Mike and Shai for your answers.

If anyone has a similiar problem:
I ended up using a column that provides my own "document ids", whose
values I got using the fieldcache.
I then precalculate the indirection per IndexReader and store it in a
WeakHashMap<IndexReader,float[]> to save the extra lookup.

Christoph Kaser

Am 28.03.2012 19:40, schrieb Michael McCandless:

> On Wed, Mar 28, 2012 at 3:37 AM, Christoph Kaser
> <[hidden email]> wrote:
>> Thank you for your answer!
>>
>> That's too bad. I thought of using my own ID-field, but I wanted to save the
>> additional indirection (from docId to my ID to my value).
>> Do document IDs remain constant for one IndexReader as long as it isn't
>> reopened? If so, I could precalculate the indirection.
> Yes, the entire view of the index presented by a single IndexReader is
> unchanging (not just docIDs: everything).
>
> On reopen, a new IndexReader is returned, so the old IndexReader is
> still unchanged.
>
> So, if you can hold your arrays per-segment, and init them per-segment
> (such as FieldCache, or DocValues (only in 4.0) as Shai described)
> then you can safely use the docID to index those arrays just within
> the context of that segment.
>
> Mike McCandless
>
> http://blog.mikemccandless.com>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]> For additional commands, e-mail: [hidden email]>
>