apache / apache/lucene

Moving to dictionaries has made stored fields slower at skipping [LUCENE-10616]

Open
#11,652 4 comments 0 reactions 0 assignees View on GitHub
legacy-jira-priority:Minor type:bug
Dominant language
Java
Stars
3.6k
Forks
1.4k
Avg merge
2d 11h
Merged PRs (30d)
88

Description

@ywelsch has been digging into a regression of stored fields retrieval that is caused by #10525.

Say your documents have two stored fields, one that is 100B and is stored first, and the other one that is 100kB, and you are only interested in the first one. While the idea behind blocks of stored fields is to store multiple documents in the same block to leverage redundancy across documents, sometimes documents are larger than the block size. As soon as documents are larger than 2x the block size, our stored fields format splits such large documents into multiple blocks, so that you wouldn't need to decompress everything only to retrieve a couple small fields.

Before #10525, BEST_SPEED had a block size of 16kB, so only retrieving the first field value would only need to decompress 16kB of data. With the move to preset dictionaries in #10525 and then #10956, we now have blocks of 80kB, so stored fields would now need to decompress 80kB of data, 5x more than before.

With dictionaries, our blocks are now split into 10 sub blocks. We happen to eagerly decompress all sub blocks that intersect with the stored document, which is why we would decompress 80kB of data, but this is an implementation detail. It should be possible to decompress these sub blocks lazily so that we would only decompress those that intersect with one of the field values that the user is interested in retrieving?

---
Migrated from [LUCENE-10616](https://issues.apache.org/jira/browse/LUCENE-10616) by Adrien Grand (@jpountz), updated Jul 26 2022
Pull requests: https://github.com/apache/lucene/pull/1003

Contributor guide

Open the contributing guide

Research direction

Start by reviewing the stored-fields changes in #10525 and #10956 and the regression described for documents larger than twice the block size. Reproduce retrieval of a small field from a document containing a 100-byte and a 100-kilobyte stored field, then verify that only subblocks intersecting requested fields are decompressed.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
performance, search
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.