HBASE-29585 Add row-level cache for the get operation by EungsopYoo · Pull Request #7291 · apache/hbase

EungsopYoo · 2025-09-10T23:17:27Z

No description provided.

wchevreuil

This is a great idea, thanks for sharing it. I do have some comments, though:

Can the RowCacheService be an implementation of BlockCache? Maybe a wrapper to the LRUBlockCache. I'm a bit worried about introducing a whole new layer for intercepting all read/write operations at the RPC service with cache specific logic, however this class is not the cache implementation itself. Seems a bit confusing to have a complete separate entry point to the cache.
Are we accepting to have same row data in multiple cache? In the current code, I haven't see any checks to avoid that. Maybe if we implement RowCacheService as a block cache implementation, so that the cache operations happen from the inner layers of the read/write operations, it would be easier to avoid duplication.
Why not simply evict the row that got mutated? I guess we cannot simply override it in the cache because mutation can happen on individual cells.
Are we accepting to have data duplicated over separate caches? I don't see any logic to avoid caching a whole block containing a region for a Get in the L2 cache, still we'll be cache the row in the row cache. Similarly, we might re-cache a row that's in the memstore in the row cache.
One problem of adding such small units (a single row) in the cache is that we need to keep a map index for each entry. So, the smaller the row in size, more rows would fit in the cache, but more key objects would be retained in the map. In your tests, assuming the default block cache size of 40% of the heap, it would give a 12.8GB of block cache. Have you managed to measure the block cache usage by the row cache, in terms of number of rows in the cache, byte size of the L1 cache and the total heap usage? Maybe wort collecting a heapdump to analyse the map index size in the heap.

wchevreuil · 2025-09-11T11:26:38Z

+
+ RegionScannerImpl scanner = getScannerInternal(region, scan, results);
+
+ // The row cache is ineffective when the number of store files is small. If the number


Can you elaborate more on this? Is it really a matter of number of files or total store file size? For a single CF table, where a given region, after major compaction, has a 10GB store file, wouldn't this be more efficient?

Get performance is more affected by the number of StoreFiles than by their size. This is because a StoreFileScanner must be created for each StoreFile, and the process of aggregating their results into a single Get result becomes increasingly complex. However, in testing, I found that when there was only one StoreFile, the row cache provided almost no performance benefit. Therefore, I added this condition to prevent the row cache from unnecessarily occupying BlockCache space.

Ahh, right, so the main gain here comes from avoiding the merge of results from different store file scanners. I guess, there could be still benefits on doing this row caching for gets only, even when only having one store file. Say, L2 cache is at capacity already, long client scans could cause evictions for blocks of gets for repeating keys.

Yes, I agree. I’ll remove the condition to cache only when the number of StoreFiles is above a threshold, and always cache the row.

Fixed in e33db29.

Get performance is more affected by the number of StoreFiles than by their size. This is because a StoreFileScanner must be created for each StoreFile, and the process of aggregating their results into a single Get result becomes increasingly complex. However, in testing, I found that when there was only one StoreFile, the row cache provided almost no performance benefit. Therefore, I added this condition to prevent the row cache from unnecessarily occupying BlockCache space.
This is true only when you have a fast I/O access to a whole store file (resides on a server's local NVMe disk or totally cached in RAM). In a disaggregated compute-storage systems (HBase/S3, for example) - this does not hold. Make sure that your tests data is not cached in RAM (limit available RAM per process, flush page cache or have a store file which is much larger than RAM of your computer). Disk-based BucketCache can be wasteful for point queries but there is another obvious benefit of a Row Cache compared to BucketCache: Its Logical vs Physical Cache. BucketCache is a Physical Cache - it caches HFile blocks. RowCache is a Logical Cache - it caches objects. Physical Cache does not survive (or poorly survives) data compactions, Logical Cache is not affected by compactions at all.

wchevreuil · 2025-09-11T13:39:57Z

+
+ private boolean tryGetFromCache(HRegion region, RowCacheKey key, Get get, List<Cell> results) {
+ RowCells row =
+ (RowCells) region.getBlockCache().getBlock(key, get.getCacheBlocks(), false, true);


RowCacheKey uses the region encoded name for indexing, whilst BlockCacheKey uses (store file name + offset). If the given row is already cached in a L2 cache block, this call will fail to fetch it and we'll cache it on the L1 too.

I initially intended for the row cache to reside only in L1 and not be cached in L2, but I haven’t actually implemented that yet. I’ll give further thought to adding this.

EungsopYoo · 2025-09-12T00:22:25Z

This is a great idea, thanks for sharing it. I do have some comments, though:

Thank you for starting the PR review.

Can the RowCacheService be an implementation of BlockCache? Maybe a wrapper to the LRUBlockCache. I'm a bit worried about introducing a whole new layer for intercepting all read/write operations at the RPC service with cache specific logic, however this class is not the cache implementation itself. Seems a bit confusing to have a complete separate entry point to the cache.

BlockCache operates at the HFile access layer, whereas the row cache needs to function at a higher layer that covers both MemStore and HFile. That’s why I implemented RowCacheService in the RPC service layer.

That said, the row cache does not actually cache HFileBlocks, yet it currently relies on the BlockCache interface. I realize this might not be appropriate. I reused the BlockCache interface to reduce the overhead of creating a separate cache implementation solely for the row cache, but in hindsight, this might not have been the best approach. It may be better to build a dedicated cache implementation specifically for the row cache.

What do you think?

Are we accepting to have same row data in multiple cache? In the current code, I haven't see any checks to avoid that. Maybe if we implement RowCacheService as a block cache implementation, so that the cache operations happen from the inner layers of the read/write operations, it would be easier to avoid duplication.

What exactly does “multiple cache” refer to? Does it mean the L1 and L2 caches in the CombinedBlockCache? If so, I haven’t really considered that aspect yet, but I’ll start looking into it.

Why not simply evict the row that got mutated? I guess we cannot simply override it in the cache because mutation can happen on individual cells.

I didn’t fully understand the intention behind your question. Could you please explain it in more detail?

Are we accepting to have data duplicated over separate caches? I don't see any logic to avoid caching a whole block containing a region for a Get in the L2 cache, still we'll be cache the row in the row cache. Similarly, we might re-cache a row that's in the memstore in the row cache.

This is in the same L1/L2 context as your comment 2, correct? If so, I haven’t considered that aspect yet, but I’ll start thinking about how to handle it.

Since the row cache is only enabled when there are at least two HFiles, rows that exist only in the MemStore are not cached. However, when there are two or more HFiles, rows in MemStore are also added again to the row cache. This is an intentional design choice, aimed at bypassing the process of generating results via SegmentScanner and StoreFileScanner, and instead serving Get requests directly from the cache.

One problem of adding such small units (a single row) in the cache is that we need to keep a map index for each entry. So, the smaller the row in size, more rows would fit in the cache, but more key objects would be retained in the map. In your tests, assuming the default block cache size of 40% of the heap, it would give a 12.8GB of block cache. Have you managed to measure the block cache usage by the row cache, in terms of number of rows in the cache, byte size of the L1 cache and the total heap usage? Maybe wort collecting a heapdump to analyse the map index size in the heap.

I slightly modified the LruBlockCache code to record the row cache size and entry count. The row cache occupies 268.67MB with 338,602 entries. The average size of a single row cache entry is 830 bytes. Within the overall BlockCache, the row cache accounts for 45% by entry count and 2% by size.

2025-09-12T09:08:44,112 INFO [LruBlockCacheStatsExecutor {}] hfile.LruBlockCache: totalSize=12.80 GB, usedSize=12.48 GB, freeSize=329.41 MB, max=12.80 GB, blockCount=752084, accesses=35942999, hits=27403857, hitRatio=76.24%, , cachingAccesses=35942954, cachingHits=27403860, cachingHitsRatio=76.24%, evictions=170, evicted=5806436, evictedPerRun=34155.50588235294, rowBlockCount=338602, rowBlockSize=268.67 MB

wchevreuil · 2025-09-12T13:00:02Z

That said, the row cache does not actually cache HFileBlocks, yet it currently relies on the BlockCache interface. I realize this might not be appropriate. I reused the BlockCache interface to reduce the overhead of creating a separate cache implementation solely for the row cache, but in hindsight, this might not have been the best approach. It may be better to build a dedicated cache implementation specifically for the row cache.
What do you think?

Yeah, I had the same thought while going through the comments. Having a separate cache structure seems the best way to implement this.

Are we accepting to have same row data in multiple cache? In the current code, I haven't see any checks to avoid that. Maybe if we implement RowCacheService as a block cache implementation, so that the cache operations happen from the inner layers of the read/write operations, it would be easier to avoid duplication.
What exactly does “multiple cache” refer to? Does it mean the L1 and L2 caches in the CombinedBlockCache? If so, I haven’t really considered that aspect yet, but I’ll start looking into it.

Nevermind my previous comment. We should focus on the separate cache for rows.

Why not simply evict the row that got mutated? I guess we cannot simply override it in the cache because mutation can happen on individual cells.
I didn’t fully understand the intention behind your question. Could you please explain it in more detail?

Rather than blocking writes to the row cache during updates/bulkload, can we simply make the updates evict/override the row from the cache if it's already there? For puts, we shouldn't need to worry about barries, if we make sure we don't cache the row if it's in the memstore only, but we should to make sure to remove it from the row cache because the cache would now be stale. For bulkloads, I guess we only need to make sure to evict the rows for affected regions after the bulkload has been committed.

Are we accepting to have data duplicated over separate caches? I don't see any logic to avoid caching a whole block containing a region for a Get in the L2 cache, still we'll be cache the row in the row cache. Similarly, we might re-cache a row that's in the memstore in the row cache.
This is in the same L1/L2 context as your comment 2, correct? If so, I haven’t considered that aspect yet, but I’ll start thinking about how to handle it.
Since the row cache is only enabled when there are at least two HFiles, rows that exist only in the MemStore are not cached. However, when there are two or more HFiles, rows in MemStore are also added again to the row cache. This is an intentional design choice, aimed at bypassing the process of generating results via SegmentScanner and StoreFileScanner, and instead serving Get requests directly from the cache.

Per other comments, agree it's fine to have the row in the row cache and its' block also in the block cache. We need to decide if we want to add blocks to the block cache when doing Get, or Get should cache only in the row cache? Also, should we avoid caching if the row is the memstore? Could be challenging in the current design of caching the whole row, because memstore migh have only updates for few cells within a row.

One problem of adding such small units (a single row) in the cache is that we need to keep a map index for each entry. So, the smaller the row in size, more rows would fit in the cache, but more key objects would be retained in the map. In your tests, assuming the default block cache size of 40% of the heap, it would give a 12.8GB of block cache. Have you managed to measure the block cache usage by the row cache, in terms of number of rows in the cache, byte size of the L1 cache and the total heap usage? Maybe wort collecting a heapdump to analyse the map index size in the heap.
I slightly modified the LruBlockCache code to record the row cache size and entry count. The row cache occupies 268.67MB with 338,602 entries. The average size of a single row cache entry is 830 bytes. Within the overall BlockCache, the row cache accounts for 45% by entry count and 2% by size.
2025-09-12T09:08:44,112 INFO [LruBlockCacheStatsExecutor {}] hfile.LruBlockCache: totalSize=12.80 GB, usedSize=12.48 GB, freeSize=329.41 MB, max=12.80 GB, blockCount=752084, accesses=35942999, hits=27403857, hitRatio=76.24%, , cachingAccesses=35942954, cachingHits=27403860, cachingHitsRatio=76.24%, evictions=170, evicted=5806436, evictedPerRun=34155.50588235294, rowBlockCount=338602, rowBlockSize=268.67 MB

What if more rows get cached, over time, as more gets for different rows are executed? It could lead to many rows in the cache, and many more objects in the map to index it. In the recent past. we've seen some heap issues when having very large file based bucket cache and small compressed blocks. I guess we could face similar problems here too.

Apache9 · 2025-09-12T15:18:18Z

The design doc looks good. Skimmed the code, seems we put row cache into block cache? Minding explaining more on why we choose to use block cache to implement row cache? What is the benefit?

Thanks.

EungsopYoo · 2025-09-15T00:54:34Z

Why not simply evict the row that got mutated? I guess we cannot simply override it in the cache because mutation can happen on individual cells.
I didn’t fully understand the intention behind your question. Could you please explain it in more detail?
Rather than blocking writes to the row cache during updates/bulkload, can we simply make the updates evict/override the row from the cache if it's already there? For puts, we shouldn't need to worry about barries, if we make sure we don't cache the row if it's in the memstore only, but we should to make sure to remove it from the row cache because the cache would now be stale. For bulkloads, I guess we only need to make sure to evict the rows for affected regions after the bulkload has been committed.

When the data exists in both the MemStore and the StoreFiles, we need to store it in the row cache to avoid result merging. In that case, due to the following issues, a barrier was introduced.

Thread	Time 1	Time 2	Time 3	Time 4
th1	delete row1 from RowCache	Put row1 to Region	write row1 to RowCache
th2		delete row1 from RowCache	Put row1 to Region	write row1 to RowCache
th3	Get for row1 not from RowCache. Good	Get for row1 not from RowCache. Good	Get for row1 from stale RowCache. Bad	Get for row1 not from RowCache. Good

It would be more efficient to do as you mentioned when doing a bulkload.

Are we accepting to have data duplicated over separate caches? I don't see any logic to avoid caching a whole block containing a region for a Get in the L2 cache, still we'll be cache the row in the row cache. Similarly, we might re-cache a row that's in the memstore in the row cache.
This is in the same L1/L2 context as your comment 2, correct? If so, I haven’t considered that aspect yet, but I’ll start thinking about how to handle it.
Since the row cache is only enabled when there are at least two HFiles, rows that exist only in the MemStore are not cached. However, when there are two or more HFiles, rows in MemStore are also added again to the row cache. This is an intentional design choice, aimed at bypassing the process of generating results via SegmentScanner and StoreFileScanner, and instead serving Get requests directly from the cache.
Per other comments, agree it's fine to have the row in the row cache and its' block also in the block cache. We need to decide if we want to add blocks to the block cache when doing Get, or Get should cache only in the row cache? Also, should we avoid caching if the row is the memstore? Could be challenging in the current design of caching the whole row, because memstore migh have only updates for few cells within a row.

I already answered this in another comment, but I’ll respond here as well.

I think it’s better to put it into the BlockCache when doing a Get, according to the BlockCache setting.

It is more efficient not to create a row cache when the cells to be fetched exist only in the MemStore. However, if the cells to be fetched are in both the MemStore and the StoreFiles, then creating a row cache is efficient to avoid result merging.

I’ll give some more thought on how we can achieve this.

One problem of adding such small units (a single row) in the cache is that we need to keep a map index for each entry. So, the smaller the row in size, more rows would fit in the cache, but more key objects would be retained in the map. In your tests, assuming the default block cache size of 40% of the heap, it would give a 12.8GB of block cache. Have you managed to measure the block cache usage by the row cache, in terms of number of rows in the cache, byte size of the L1 cache and the total heap usage? Maybe wort collecting a heapdump to analyse the map index size in the heap.
I slightly modified the LruBlockCache code to record the row cache size and entry count. The row cache occupies 268.67MB with 338,602 entries. The average size of a single row cache entry is 830 bytes. Within the overall BlockCache, the row cache accounts for 45% by entry count and 2% by size.
2025-09-12T09:08:44,112 INFO [LruBlockCacheStatsExecutor {}] hfile.LruBlockCache: totalSize=12.80 GB, usedSize=12.48 GB, freeSize=329.41 MB, max=12.80 GB, blockCount=752084, accesses=35942999, hits=27403857, hitRatio=76.24%, , cachingAccesses=35942954, cachingHits=27403860, cachingHitsRatio=76.24%, evictions=170, evicted=5806436, evictedPerRun=34155.50588235294, rowBlockCount=338602, rowBlockSize=268.67 MB
What if more rows get cached, over time, as more gets for different rows are executed? It could lead to many rows in the cache, and many more objects in the map to index it. In the recent past. we've seen some heap issues when having very large file based bucket cache and small compressed blocks. I guess we could face similar problems here too.

Okay. Then I’ll take a heap dump and check the size of the map’s index.

EungsopYoo · 2025-09-15T00:58:35Z

The design doc looks good. Skimmed the code, seems we put row cache into block cache? Minding explaining more on why we choose to use block cache to implement row cache? What is the benefit?
Thanks.

I did it that way because the implementation was simpler. However, it causes confusion and makes it harder to have clear control over the row cache, so I’ve decided to create a separate RowCache implementation.

EungsopYoo · 2025-09-15T01:03:29Z

The TODOs are as follows, and I will proceed in order:

Separate the row cache implementation
Remove the condition that decides whether to put data into the row cache based on the number of StoreFiles
Do not use the row cache when the data exists only in the MemStore
Invalidate only the row cache of regions that were bulkloaded
Take a heap dump to check the index size of the map

- Implement RowCache - Initially considered modifying LruBlockCache, but the required changes were extensive. Instead, implemented RowCache using Caffeine cache. - Add row.cache.size configuration - Default is 0.0 (disabled); RowCache is enabled only if explicitly set to a value > 0. - The combined size of BlockCache + MemStore + RowCache must not exceed 80% of the heap. - Add Row Cache tab to RegionServer Block Cache UI - RowCache is not a BlockCache, but added here since there is no better place. - Add RowCache metrics - Metrics for size, count, eviction, hit, and miss are now exposed.

EungsopYoo · 2025-09-25T04:32:21Z

One problem of adding such small units (a single row) in the cache is that we need to keep a map index for each entry. So, the smaller the row in size, more rows would fit in the cache, but more key objects would be retained in the map. In your tests, assuming the default block cache size of 40% of the heap, it would give a 12.8GB of block cache. Have you managed to measure the block cache usage by the row cache, in terms of number of rows in the cache, byte size of the L1 cache and the total heap usage? Maybe wort collecting a heapdump to analyse the map index size in the heap.
I slightly modified the LruBlockCache code to record the row cache size and entry count. The row cache occupies 268.67MB with 338,602 entries. The average size of a single row cache entry is 830 bytes. Within the overall BlockCache, the row cache accounts for 45% by entry count and 2% by size.
2025-09-12T09:08:44,112 INFO [LruBlockCacheStatsExecutor {}] hfile.LruBlockCache: totalSize=12.80 GB, usedSize=12.48 GB, freeSize=329.41 MB, max=12.80 GB, blockCount=752084, accesses=35942999, hits=27403857, hitRatio=76.24%, , cachingAccesses=35942954, cachingHits=27403860, cachingHitsRatio=76.24%, evictions=170, evicted=5806436, evictedPerRun=34155.50588235294, rowBlockCount=338602, rowBlockSize=268.67 MB
What if more rows get cached, over time, as more gets for different rows are executed? It could lead to many rows in the cache, and many more objects in the map to index it. In the recent past. we've seen some heap issues when having very large file based bucket cache and small compressed blocks. I guess we could face similar problems here too.
Okay. Then I’ll take a heap dump and check the size of the map’s index.

I configured the RegionServer with a 4 GB heap, setting hfile.block.cache.size to 0.3 and row.cache.size to 0.1, then reran the same workload as before. Under these settings, the maximum RowCache capacity is approximately 400 MB. After the RowCache was fully populated, I generated and analyzed a heap dump.

RowCache Size: 409 MB
RowCache Count: 697,234 entries
Average RowCache Entry Size: 615 B
- This is reduced from 830 B previously, mainly due to a simplified RowCacheKey.
Retained Heap Size: 622 MB
- Because of the overhead associated with Caffeine’s key/value structures, the retained size on heap amounts to 52% more than the actual data size for this workload.
- I believe this is acceptable if the RowCache size is configured relatively smaller than the BlockCache, for example, around 2% of the BlockCache size. The positive impact of RowCache is already noticeable even at this smaller capacity.

Apache-HBase · 2025-10-16T08:42:03Z

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 38s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 0s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
+1 💚	hbaseanti	0m 0s		Patch does not have any anti-patterns.
			_ master Compile Tests _
+0 🆗	mvndep	0m 52s		Maven dependency ordering for branch
+1 💚	mvninstall	3m 36s		master passed
+1 💚	compile	8m 36s		master passed
+1 💚	checkstyle	1m 13s		master passed
+1 💚	spotbugs	10m 52s		master passed
+0 🆗	refguide	2m 43s		branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.
+1 💚	spotless	0m 49s		branch has no errors when running spotless:check.
-0 ⚠️	patch	1m 24s		Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 16s		Maven dependency ordering for patch
+1 💚	mvninstall	3m 12s		the patch passed
+1 💚	compile	8m 37s		the patch passed
+1 💚	javac	8m 37s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
-0 ⚠️	checkstyle	0m 33s	/buildtool-patch-checkstyle-root.txt	The patch fails to run checkstyle in root
-0 ⚠️	rubocop	0m 15s	/results-rubocop.txt	The patch generated 2 new + 411 unchanged - 0 fixed = 413 total (was 411)
+1 💚	xmllint	0m 0s		No new issues.
+1 💚	spotbugs	11m 28s		the patch passed
+0 🆗	refguide	2m 9s		patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.
+1 💚	hadoopcheck	12m 31s		Patch does not cause any errors with Hadoop 3.3.6 3.4.1.
+1 💚	spotless	0m 46s		patch has no errors when running spotless:check.
			_ Other Tests _
+1 💚	asflicense	0m 55s		The patch does not generate ASF License warnings.
		78m 59s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/14/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#7291
Optional Tests	dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless xmllint refguide rubocop
uname	Linux b239b0df022b 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / `5dad021`
Default Java	Eclipse Adoptium-17.0.11+9
refguide	https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-7291/14/yetus-general-check/output/branch-site/book.html
refguide	https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-7291/14/yetus-general-check/output/patch-site/book.html
Max. process+thread count	189 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-server hbase-shell . U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/14/console
versions	git=2.34.1 maven=3.9.8 spotbugs=4.7.3 rubocop=1.37.1 xmllint=20913
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

Apache-HBase · 2025-10-16T13:13:59Z

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 31s		Docker mode activated.
-0 ⚠️	yetus	0m 4s		Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
			_ Prechecks _
			_ master Compile Tests _
+0 🆗	mvndep	0m 41s		Maven dependency ordering for branch
+1 💚	mvninstall	3m 34s		master passed
+1 💚	compile	2m 14s		master passed
+1 💚	javadoc	3m 15s		master passed
+1 💚	shadedjars	6m 15s		branch has no errors when building our shaded downstream artifacts.
-0 ⚠️	patch	6m 56s		Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 16s		Maven dependency ordering for patch
+1 💚	mvninstall	3m 10s		the patch passed
+1 💚	compile	2m 17s		the patch passed
+1 💚	javac	2m 17s		the patch passed
+1 💚	javadoc	3m 16s		the patch passed
+1 💚	shadedjars	6m 11s		patch has no errors when building our shaded downstream artifacts.
			_ Other Tests _
+1 💚	unit	311m 7s		root in the patch passed.
		350m 58s

Subsystem	Report/Notes
Docker	ClientAPI=1.43 ServerAPI=1.43 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/14/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR	#7291
Optional Tests	javac javadoc unit compile shadedjars
uname	Linux 43b3bd1d7b5e 5.4.0-1103-aws #111~18.04.1-Ubuntu SMP Tue May 23 20:04:10 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / `5dad021`
Default Java	Eclipse Adoptium-17.0.11+9
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/14/testReport/
Max. process+thread count	8062 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-server hbase-shell . U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/14/console
versions	git=2.34.1 maven=3.9.8
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

wchevreuil · 2025-10-16T14:19:42Z

@Apache9 OK. I’ll create a feature branch and develop the work on sub-branches, merging them step by step. It seems someone who has permission to create branches should make the feature branch, right?
@wchevreuil I’ll address the review comments in a new branch.

I've created a new branch labeled HBASE-29585. @EungsopYoo, please open PRs on that branch. If we are planning to break down this feature development into more granular tasks, please open subtask jira tickets under the original HBASE-29585 one.

EungsopYoo · 2025-10-19T23:39:37Z

@wchevreuil
I've opened a new PR. Please review it.
#7398

…ually evicted rows

Apache-HBase · 2025-10-21T04:10:16Z

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 12s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 1s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
+1 💚	hbaseanti	0m 0s		Patch does not have any anti-patterns.
			_ master Compile Tests _
+0 🆗	mvndep	0m 24s		Maven dependency ordering for branch
+1 💚	mvninstall	4m 49s		master passed
+1 💚	compile	13m 17s		master passed
+1 💚	checkstyle	2m 34s		master passed
+1 💚	spotbugs	15m 46s		master passed
+0 🆗	refguide	3m 20s		branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.
+1 💚	spotless	1m 5s		branch has no errors when running spotless:check.
-0 ⚠️	patch	1m 46s		Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 18s		Maven dependency ordering for patch
+1 💚	mvninstall	4m 40s		the patch passed
+1 💚	compile	13m 38s		the patch passed
+1 💚	javac	13m 38s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
-0 ⚠️	checkstyle	2m 39s	/results-checkstyle-root.txt	root: The patch generated 6 new + 27 unchanged - 0 fixed = 33 total (was 27)
-0 ⚠️	rubocop	0m 6s	/results-rubocop.txt	The patch generated 2 new + 411 unchanged - 0 fixed = 413 total (was 411)
+1 💚	xmllint	0m 0s		No new issues.
+1 💚	spotbugs	17m 10s		the patch passed
+0 🆗	refguide	3m 2s		patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.
+1 💚	hadoopcheck	14m 9s		Patch does not cause any errors with Hadoop 3.3.6 3.4.1.
+1 💚	spotless	0m 57s		patch has no errors when running spotless:check.
			_ Other Tests _
+1 💚	asflicense	1m 3s		The patch does not generate ASF License warnings.
		109m 3s

Subsystem	Report/Notes
Docker	ClientAPI=1.48 ServerAPI=1.48 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/17/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#7291
Optional Tests	dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless xmllint refguide rubocop
uname	Linux a49162c0b9f9 6.8.0-1024-aws #26~22.04.1-Ubuntu SMP Wed Feb 19 06:54:57 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / `7cc5d2a`
Default Java	Eclipse Adoptium-17.0.11+9
refguide	https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-7291/17/yetus-general-check/output/branch-site/book.html
refguide	https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-7291/17/yetus-general-check/output/patch-site/book.html
Max. process+thread count	162 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-server hbase-shell . U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/17/console
versions	git=2.34.1 maven=3.9.8 spotbugs=4.7.3 rubocop=1.37.1 xmllint=20913
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

Apache-HBase · 2025-10-21T11:52:00Z

💔 -1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 12s		Docker mode activated.
-0 ⚠️	yetus	0m 4s		Unprocessed flag(s): --brief-report-file --spotbugs-strict-precheck --author-ignore-list --blanks-eol-ignore-file --blanks-tabs-ignore-file --quick-hadoopcheck
			_ Prechecks _
			_ master Compile Tests _
+0 🆗	mvndep	0m 22s		Maven dependency ordering for branch
+1 💚	mvninstall	4m 34s		master passed
+1 💚	compile	2m 55s		master passed
+1 💚	javadoc	4m 29s		master passed
+1 💚	shadedjars	6m 40s		branch has no errors when building our shaded downstream artifacts.
-0 ⚠️	patch	7m 17s		Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 16s		Maven dependency ordering for patch
+1 💚	mvninstall	4m 13s		the patch passed
+1 💚	compile	3m 4s		the patch passed
+1 💚	javac	3m 4s		the patch passed
+1 💚	javadoc	4m 30s		the patch passed
+1 💚	shadedjars	6m 43s		patch has no errors when building our shaded downstream artifacts.
			_ Other Tests _
-1 ❌	unit	486m 23s	/patch-unit-root.txt	root in the patch failed.
		530m 4s

Subsystem	Report/Notes
Docker	ClientAPI=1.48 ServerAPI=1.48 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/17/artifact/yetus-jdk17-hadoop3-check/output/Dockerfile
GITHUB PR	#7291
Optional Tests	javac javadoc unit compile shadedjars
uname	Linux 9aa6c025319d 6.8.0-1024-aws #26~22.04.1-Ubuntu SMP Wed Feb 19 06:54:57 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / `7e2718a`
Default Java	Eclipse Adoptium-17.0.11+9
Test Results	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/17/testReport/
Max. process+thread count	3225 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-server hbase-shell . U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/17/console
versions	git=2.34.1 maven=3.9.8
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

Apache-HBase · 2025-10-21T17:47:47Z

🎊 +1 overall

Vote	Subsystem	Runtime	Logfile	Comment
+0 🆗	reexec	0m 15s		Docker mode activated.
			_ Prechecks _
+1 💚	dupname	0m 1s		No case conflicting files found.
+0 🆗	codespell	0m 0s		codespell was not available.
+0 🆗	detsecrets	0m 0s		detect-secrets was not available.
+1 💚	@author	0m 0s		The patch does not contain any @author tags.
+1 💚	hbaseanti	0m 0s		Patch does not have any anti-patterns.
			_ master Compile Tests _
+0 🆗	mvndep	0m 33s		Maven dependency ordering for branch
+1 💚	mvninstall	5m 55s		master passed
+1 💚	compile	16m 18s		master passed
+1 💚	checkstyle	3m 11s		master passed
+1 💚	spotbugs	19m 26s		master passed
+0 🆗	refguide	3m 59s		branch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.
+1 💚	spotless	1m 13s		branch has no errors when running spotless:check.
-0 ⚠️	patch	1m 59s		Used diff version of patch file. Binary files and potentially other changes not applied. Please rebase and squash commits if necessary.
			_ Patch Compile Tests _
+0 🆗	mvndep	0m 20s		Maven dependency ordering for patch
+1 💚	mvninstall	4m 57s		the patch passed
+1 💚	compile	14m 40s		the patch passed
+1 💚	javac	14m 40s		the patch passed
+1 💚	blanks	0m 0s		The patch has no blanks issues.
-0 ⚠️	checkstyle	2m 50s	/results-checkstyle-root.txt	root: The patch generated 6 new + 27 unchanged - 0 fixed = 33 total (was 27)
-0 ⚠️	rubocop	0m 8s	/results-rubocop.txt	The patch generated 2 new + 411 unchanged - 0 fixed = 413 total (was 411)
+1 💚	xmllint	0m 0s		No new issues.
+1 💚	spotbugs	19m 6s		the patch passed
+0 🆗	refguide	3m 43s		patch has no errors when building the reference guide. See footer for rendered docs, which you should manually inspect.
+1 💚	hadoopcheck	16m 54s		Patch does not cause any errors with Hadoop 3.3.6 3.4.1.
+1 💚	spotless	1m 5s		patch has no errors when running spotless:check.
			_ Other Tests _
+1 💚	asflicense	1m 20s		The patch does not generate ASF License warnings.
		127m 52s

Subsystem	Report/Notes
Docker	ClientAPI=1.48 ServerAPI=1.48 base: https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/18/artifact/yetus-general-check/output/Dockerfile
GITHUB PR	#7291
Optional Tests	dupname asflicense javac spotbugs checkstyle codespell detsecrets compile hadoopcheck hbaseanti spotless xmllint refguide rubocop
uname	Linux 5875f72c3f0e 6.8.0-1024-aws #26~22.04.1-Ubuntu SMP Wed Feb 19 06:54:57 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Build tool	maven
Personality	dev-support/hbase-personality.sh
git revision	master / `7e2718a`
Default Java	Eclipse Adoptium-17.0.11+9
refguide	https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-7291/18/yetus-general-check/output/branch-site/book.html
refguide	https://nightlies.apache.org/hbase/HBase-PreCommit-GitHub-PR/PR-7291/18/yetus-general-check/output/patch-site/book.html
Max. process+thread count	163 (vs. ulimit of 30000)
modules	C: hbase-common hbase-hadoop-compat hbase-client hbase-server hbase-shell . U: .
Console output	https://ci-hbase.apache.org/job/HBase-PreCommit-GitHub-PR/job/PR-7291/18/console
versions	git=2.34.1 maven=3.9.8 spotbugs=4.7.3 rubocop=1.37.1 xmllint=20913
Powered by	Apache Yetus 0.15.0 https://yetus.apache.org

This message was automatically generated.

VladRodionov · 2026-01-13T22:09:26Z

While reading through the issue and thinking about possible design trade-offs, a few questions came to mind that may be worth considering as the implementation evolves:

Heap pressure: using Java-heap–resident structures (or reusing BucketCache metadata paths) may increase GC pressure under some workloads. ZGC certainly helps here, but I’m curious how this is expected to behave for row-sized objects with high churn.
Metadata overhead: for cache entries on the order of a single row, the relative metadata overhead can become significant compared to the payload. It would be interesting to understand how this is being evaluated or measured in the current approach.
Sparse row access: some applications primarily care about a subset of row data (for example, only the latest versions of selected cells). Google Bigtable’s row cache supports sparse rows — are similar access patterns in scope here, or is the focus on full-row caching?
In-place mutation: supporting sparse rows often implies updating cached entries in place so the cache always reflects the most recent version of the row. I’m curious whether this is within the intended scope or something to consider later.

These aren’t meant as blockers — just questions around the design space and trade-offs. Looking forward to following the progress on this issue.

EungsopYoo · 2026-01-22T23:37:55Z

@VladRodionov
Thank you for your comments. I’d like to respond to the questions you raised.

Heap pressure: using Java-heap–resident structures (or reusing BucketCache metadata paths) may increase GC pressure under some workloads. ZGC certainly helps here, but I’m curious how this is expected to behave for row-sized objects with high churn.

Although it will be clearer once we run some tests, under high-churn workloads I expect RowCache, like BlockCache, to experience significant GC pressure. In such cases, it would likely be more appropriate not to use RowCache.

Metadata overhead: for cache entries on the order of a single row, the relative metadata overhead can become significant compared to the payload. It would be interesting to understand how this is being evaluated or measured in the current approach.

That’s correct. Because the overhead is large, I plan to set the default size of RowCache to 2% of the heap, which is relatively much smaller than the 40% heap size typically allocated to BlockCache.

Sparse row access: some applications primarily care about a subset of row data (for example, only the latest versions of selected cells). Google Bigtable’s row cache supports sparse rows — are similar access patterns in scope here, or is the focus on full-row caching?
In-place mutation: supporting sparse rows often implies updating cached entries in place so the cache always reflects the most recent version of the row. I’m curious whether this is within the intended scope or something to consider later.

In this PR, I am not considering caching for sparse rows and am focusing only on caching full rows. Support for sparse row caching can be considered later.

Add row-level cache for the get operation
872f13a

EungsopYoo changed the title ~~Add row-level cache for the get operation~~HBASE-29585 Add row-level cache for the get operationSep 10, 2025