Skip to content

Conditionally use sequential stored field reader in LuceneSyntheticSourceChangesSnapshot #121636

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Feb 10, 2025
Merged

Conditionally use sequential stored field reader in LuceneSyntheticSourceChangesSnapshot #121636

Changes from all commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
6eb67b2
Use sequential reader in LuceneSyntheticSourceChangesSnapshot
martijnvg Feb 4, 2025
41d4e68
iter
martijnvg Feb 4, 2025
8e9436c
added comment
martijnvg Feb 4, 2025
99623e7
Merge remote-tracking branch 'es/main' into LuceneSyntheticSourceChan…
martijnvg Feb 4, 2025
161a429
Merge remote-tracking branch 'es/main' into LuceneSyntheticSourceChan…
martijnvg Feb 6, 2025
1d0a210
pass down docids in order to determine whether to load sequential
martijnvg Feb 6, 2025
c6cc1e7
iter
martijnvg Feb 6, 2025
78f0b7e
iter2
martijnvg Feb 6, 2025
0f8dca1
Merge remote-tracking branch 'es/main' into LuceneSyntheticSourceChan…
martijnvg Feb 7, 2025
9a7a3e7
iter3
martijnvg Feb 7, 2025
447de83
Merge remote-tracking branch 'es/main' into LuceneSyntheticSourceChan…
martijnvg Feb 10, 2025
31b81c0
added comment
martijnvg Feb 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
26 changes: 24 additions & 2 deletions ...er/src/main/java/org/elasticsearch/index/engine/LuceneSyntheticSourceChangesSnapshot.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -9,6 +9,8 @@

package org.elasticsearch.index.engine;

import com.carrotsearch.hppc.IntArrayList;
Copy link
Contributor

@lkts lkts Feb 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you intend to use this namespace (seems odd since it comes from a testing tool)?

Copy link
Member Author

@martijnvg martijnvg Feb 10, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think hppc may have originated from the randomized testing framework that both Elasticsearch and Lucene use today. However it is currently a standalone high performance primitive collection library: https://github.com/carrotsearch/hppc, which does have other production usage in Elasticsearch.

Copy link
Contributor

@kkrik-es kkrik-es Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about using the Lucene one: package org.apache.lucene.internal.hppc

Copy link
Member Author

@martijnvg martijnvg Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Lucene core library only forked a subset of the hppc primitive collection library and IntArrayList is included. But the javadocs says it forked from version 0.10.0 and Elasticsearch is uses version 0.8.1 of that library. I see most Elasticsearch usages of hppc use the dependency directly.


import org.apache.lucene.index.LeafReaderContext;
import org.apache.lucene.search.FieldDoc;
import org.apache.lucene.search.ScoreDoc;
Expand Down Expand Up @@ -191,8 +193,28 @@ private Translog.Operation[] loadDocuments(List<SearchRecord> documentRecords) t
maxDoc = leafReaderContext.reader().maxDoc();
} while (docRecord.docID() >= docBase + maxDoc);

leafFieldLoader = storedFieldLoader.getLoader(leafReaderContext, null);
leafSourceLoader = sourceLoader.leaf(leafReaderContext.reader(), null);
// TODO: instead of building an array, consider just checking whether doc ids are dense.
Copy link
Member

@tlrx tlrx Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is some knowledge in the PR description and comments that would deserve to be captured in the code as a comment, explaining why we always provide the docs ids set.

// Note, field loaders then would lose the ability to optionally eagerly loading values.
IntArrayList nextDocIds = new IntArrayList();
for (int j = i; j < documentRecords.size(); j++) {
Copy link
Member

@tlrx tlrx Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As far as I understand we're not increasing the complexity of the method by iterating on documentRecords again here (as we already iterates on documentRecords in the outer loop), because we only compute nextDocIds for 1 leaf reader. Can you confirm?

Copy link
Member Author

@martijnvg martijnvg Feb 10, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we only compute the docids for the current lead reader. If docid is higher then or equal to docbase + maxDoc then it means current document record belongs to the next leaf reader.

var record = documentRecords.get(j);
if (record.isTombstone()) {
continue;
}
int docID = record.docID();
if (docID >= docBase + maxDoc) {
break;
}
int segmentDocID = docID - docBase;
nextDocIds.add(segmentDocID);
}

// This computed doc ids arrays us used by stored field loader as a heuristic to determine whether to use a sequential
// stored field reader (which bulk loads stored fields and avoids decompressing the same blocks multiple times). For
// source loader, it is also used as a heuristic for bulk reading doc values (E.g. SingletonDocValuesLoader).
int[] nextDocIdArray = nextDocIds.toArray();
leafFieldLoader = storedFieldLoader.getLoader(leafReaderContext, nextDocIdArray);
leafSourceLoader = sourceLoader.leaf(leafReaderContext.reader(), nextDocIdArray);
Copy link
Contributor

@jimczi jimczi Feb 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another side effect of providing the array of document IDs is that some field loaders may choose to load their values eagerly. I don't see this as a problem, but I wanted to point out that we would lose this behavior if we implement the TODO above.

Copy link
Member Author

@martijnvg martijnvg Feb 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed. I will update the TODO to include that perspective.

Copy link
Contributor

@jimczi jimczi Feb 7, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that some doc values loaders already apply this strategy when doc ids are provided and there is a single value per field:

elasticsearch/server/src/main/java/org/elasticsearch/index/mapper/SortedSetDocValuesSyntheticFieldLoaderLayer.java

Line 55 in b6facb2

* The singleton optimization is mostly about looking up ordinals

setNextSourceMetadataReader(leafReaderContext);
}
int segmentDocID = docRecord.docID() - docBase;
Expand Down