airborne12 opened a new pull request, #69879:
URL: https://github.com/apache/doris/pull/69879
### What problem does this PR solve?
Issue Number: None
Related PR: None
Problem Summary: A SNII dictionary larger than the resident threshold (256
KB) is read block by
block on demand. Every exact term lookup reads the term's DICT block (64 KB
target), decompresses
it with zstd, checks its CRC and parses its anchors, and the request-scoped
DictBlockCache keeps
nothing across queries. Every query therefore pays this again for every term
in every segment.
On a 99M-row AgentLogs table with 722 segments, counting one frequent term
spent 68 ms of index
time on these lookups against 16 ms for V3, and stack samples of
postings-only and phrase queries
showed 7-14% of SNII time in decompressing dictionary blocks alone.
A SNII reader that the searcher cache keeps now keeps its recent exact
lookups as well: a bounded
LRU of up to 32 terms per reader, each at most 64 bytes long with at most
256 bytes of inline
postings, which also remembers terms its dictionary turned out not to hold.
`lookup()` and
`lookup_batch()` check it before they read a block, so a batch reads only
the blocks of the terms
it does not hold. The cache's full footprint, about 25 KB, is reserved in
the reader's searcher
cache charge when the reader is inserted, as norms are, so the memory stays
accounted. Only
readers kept by the searcher cache enable it, and only when their dictionary
is read on demand.
The entries live inside the reader, so they go away with it and never
outlive the file they
describe.
Caching the decoded blocks instead was not chosen: an exact lookup touches
one 64 KB block per
segment, so blocks would cost about 46 MB per hot term and column on that
table, while a kept
lookup costs a few hundred bytes. Keeping blocks in the searcher cache would
also count against
its fd-derived entry limit and push readers out. Prefix and pattern walks
over the dictionary are
not covered.
Hot latency on the 99M-row table, cache off/on interleaved in one BE process:
| Query | Off -> On |
|---|---|
| phrase 'retry budget depleted' (DS2) | 0.60 |
| AND of two terms in two columns (A4) | 0.74-0.79 |
| one term in two columns (A3) | 0.80 |
| count of one frequent term (A2) | 0.84 |
| regexp, its matched terms looked up again (DS9) | 0.89 |
| phrase prefix (DS4) | 0.93 |
| the other 19 queries | 0.92-1.05, within run-to-run noise |
Against V3 on the same data (SNII/V3), DS2 went from 1.29 to 0.81, A4 from
1.24 to 0.95, A3 from
1.21 to 1.01 and A2 from 1.07 to 0.97.
### Release note
Speed up repeated SNII term lookups on large dictionaries.
### Check List (For Author)
- Test: Unit Test (SniiTermLookupCacheTest: repeated single and batch
lookups skip the block,
bounds and the up-front charge, off by default and for resident
dictionaries, concurrent
lookups match an uncached reader; with lookups never served from the
cache, three of them
fail; all 1508 *Snii* tests pass under ASAN). Manual test: the hot A/B
above.
- Behavior changed: No
- Does this need documentation: No
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
