OK, I’ll post the initial context here, and we can continue the detailed discussion on the JIRA.
These two implementations can certainly evolve independently, and it seems reasonable that HBASE-29585 could selectively borrow ideas (for example, around compression) from other existing work as it matures. In Carrot Cache, dictionary compression has been exercised fairly extensively, and one of the observations is that dictionary-trained compression tends to be more effective when applied at a block level rather than on individual small objects. Even if cached data remains on heap in HBASE-29585, dictionary compression could still be integrated by serializing cells into byte arrays, although the achievable savings would likely be more limited. To take fuller advantage of dictionary compression, an off-heap layout tends to work better. In Carrot Cache, small objects are grouped into contiguous blocks (configurable, default 4KB), dictionaries are trained on blocks rather than individual entries, and compression is applied at the block level. For some data distributions—particularly with many small objects—this can significantly improve memory density, in some cases on the order of ~50% compared to compressing objects individually. I’m mainly sharing this as an additional data point from a different design space; it will be interesting to see how HBASE-29585 evolves and which trade-offs make the most sense there. -Vlad On Wed, Jan 14, 2026 at 12:22 AM 张铎(Duo Zhang) <[email protected]> wrote: > For me I think some of HBASE-29585's core ideas are: > > 1. In process cache(which means no read/write error, which could > simplify the logic) > 2. Barrier based mechanism to prevent reading stale rows(See > > https://github.com/apache/hbase/blob/7b4ddd9ef736b7e0e2b19b5ca040fa3a62411206/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/RowCacheService.java > ) > > So if your implementation does not conflict with the above ideas, I > think they can work together. For example, dictionary based > compression can also be implemented in HBASE-29585? > > And if you have other opinions, I think we could discuss this here or > on the jira issue. > > Thanks. > > Vladimir Rodionov <[email protected]> 于2026年1月14日周三 02:19写道： > > > > Thanks for the pointer — I wasn’t aware of HBASE-29585 when I sent the > > note, appreciate you sharing it. > > > > From a quick look, it seems the current effort is focused on a > > Caffeine-based implementation integrated into HBase internals, which is > > great to see moving forward. > > > > The motivation behind my proposal was slightly different: exploring > whether > > a row cache could be implemented in a more non-intrusive way > > (coprocessor-only), with minimal Java heap footprint and optional > > compression (dictionary-based), > > mainly to understand the trade-offs around metadata overhead and memory > > density. It sounds like the core use case is already being addressed in > the > > ongoing work, so I won’t push this further on the list. > > I’ll keep following HBASE-29585 with interest, and happy to share > > observations if they turn out to be useful. > > > > > > Thanks again for the reference. > > > > > > > > On Tue, Jan 13, 2026 at 7:43 AM 张铎(Duo Zhang) <[email protected]> > wrote: > > > > > There is already a jira issue and a contributor is working on it. > > > > > > https://issues.apache.org/jira/browse/HBASE-29585 > > > > > > Charles Connell via dev <[email protected]> 于2026年1月13日周二 23:02写道： > > > > > > > > I'm interesting in trying out the row cache for some of our data sets > > > > at HubSpot. No timeline available yet, although I'm sure it will be > > > > before the end of 2026. I'm excited to see what I can do for us. > > > > > > > > On Mon, Jan 12, 2026 at 10:52 PM Vladimir Rodionov > > > > <[email protected]> wrote: > > > > > > > > > > Forgot to mention: Row Cache can be easily made cache > implementation > > > > > agnostic (Caffeine, EHCache) if it matters. > > > > > > > > > > > > > > > On Mon, Jan 12, 2026 at 6:27 PM Vladimir Rodionov < > > > [email protected]> > > > > > wrote: > > > > > > > > > > > Andor, below, my answers to your questions: > > > > > > > > > > > > > Doesn't the benefits of row based caching strongly depend on > the > > > use > > > > > > case? > > > > > > > > > > > > Sure. It's a point queries, not a scan operation. The repo, I > posted > > > the > > > > > > link : > > > > > > > > > > https://github.com/VladRodionov/hbase-row-cache/wiki/HBase:-Why-Block-Cache-Alone-Is-No-Longer-Enough-in-the-Cloud > > > > > > where you can find numerous use cases, where row cache will be > > > useful. > > > > > > > > > > > > > What’s the advantage if clients don’t always need the entire > row > > > just a > > > > > > subset of cells? > > > > > > Yes, this is a known limitation of a current version. There is an > > > open > > > > > > ticket to support "sparse" rows. here: > > > > > > https://github.com/VladRodionov/hbase-row-cache/issues/26 > > > > > > > > > > > > > Is block cache more performant and memory efficient in this > case? > > > > > > > > > > > > The only use case where block cache will be more performant is a > scan > > > > > > operation, which involves multiple rows. These caches are > > > complementary, > > > > > > not mutually exclusive. Row Cache has a serious advantage in > point > > > queries > > > > > > (It can do upto 100 Kops on full row reads, where each row is 3 > > > families > > > > > > with 3 columns and 10 versions). Block cache is more suitable > for > > > larger > > > > > > operations, such as a scan of multiple rows. > > > > > > Row cache can be enabled/disabled per table and per table's > column > > > > > > families. > > > > > > > > > > > > From RAM usage perspective, Row Cache (Carrot Cache) uses > advanced > > > data > > > > > > compression scheme (zstd with dictionary), which usually allows > to > > > save an > > > > > > additional 40-50% RAM > > > > > > compared to all non-dictionary based compression algorithms. It > > > works well > > > > > > even if the individual data item is less than 100 bytes. Hbase > Block > > > Cache > > > > > > (Bucket Cache) > > > > > > uses this type of compression as well (maybe I am wrong here?), > but > > > it > > > > > > compresses the whole block. > > > > > > > > > > > > Performance-wise, I think Row Cache should be much faster than > Block > > > Cache > > > > > > if blocks cached are compressed (you will need to decompress and > > > decode the > > > > > > whole block on a point read). > > > > > > > > > > > > Another limitation of a Block (Bucket) cache is a high meta-data > > > overhead > > > > > > (like 100+ bytes vs 12-16 bytes in Row Cache) All meta data in > Row > > > Cache > > > > > > (Carrot Cache) is off-heap as well. > > > > > > > > > > > > The repo has nice write up for when Row Cache is more preferable > > > than a > > > > > > Block cache. > > > > > > > > > > > > > > > > > > > > > > > > On Mon, Jan 12, 2026 at 5:27 PM Andor Molnár <[email protected]> > > > wrote: > > > > > > > > > > > >> Thanks Vladimir. > > > > > >> > > > > > >> I think this would be a great addition to HBase. > > > > > >> > > > > > >> Doesn't the benefits of row based caching strongly depend on > the use > > > > > >> case? > > > > > >> What’s the advantage if clients don’t always need the entire row > > > just a > > > > > >> subset of cells? > > > > > >> Is block cache more performant and memory efficient in this > case? > > > > > >> > > > > > >> Regards, > > > > > >> Andor > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > On Jan 4, 2026, at 13:02, Vladimir Rodionov < > > > [email protected]> > > > > > >> wrote: > > > > > >> > > > > > > >> > Hello HBase community, > > > > > >> > > > > > > >> > I’d like to start a discussion around a feature that exists in > > > related > > > > > >> > systems but is still missing in Apache HBase: row-level > caching. > > > > > >> > > > > > > >> > Both *Cassandra* and *Google Bigtable* provide a row cache for > > > hot rows. > > > > > >> > Bigtable recently revisited this area and reported measurable > > > gains for > > > > > >> > single-row reads. HBase today relies almost entirely on *block > > > cache*, > > > > > >> > which is excellent for scans and predictable access patterns, > but > > > can be > > > > > >> > inefficient for *small random reads*, *hot rows spanning > multiple > > > > > >> blocks*, > > > > > >> > and *cloud / object-store–backed deployments*. > > > > > >> > > > > > > >> > To explore this gap, I’ve been working on an *HBase Row Cache > for > > > HBase > > > > > >> 2.x*, > > > > > >> > implemented as a *RegionObserver coprocessor*, and I’d > appreciate > > > > > >> feedback > > > > > >> > from HBase developers and operators. > > > > > >> > > > > > > >> > *Project*: > > > > > >> > > > > > > >> > https://github.com/VladRodionov/hbase-row-cache > > > > > >> > > > > > > >> > > > > > > >> > *Background / motivation (cloud focus):* > > > > > >> > > > > > > >> > > > > > > >> > > > > https://github.com/VladRodionov/hbase-row-cache/wiki/HBase:-Why-Block-Cache-Alone-Is-No-Longer-Enough-in-the-Cloud > > > > > >> > > > > > > >> > What This Is > > > > > >> > > > > > > >> > > > > > > >> > - > > > > > >> > > > > > > >> > Row-level cache for HBase 2.x (coprocessor-based) > > > > > >> > - > > > > > >> > > > > > > >> > Powered by *Carrot Cache* (mostly off-heap, GC-friendly) > > > > > >> > - > > > > > >> > > > > > > >> > Multi-level cache (L1/L2/L3) > > > > > >> > - > > > > > >> > > > > > > >> > Read-through caching of table : rowkey : column-family > > > > > >> > - > > > > > >> > > > > > > >> > Cache invalidation on any mutation of the corresponding > row+CF > > > > > >> > - > > > > > >> > > > > > > >> > Designed for *read-mostly, random-access* workloads > > > > > >> > - > > > > > >> > > > > > > >> > Can be enabled per table or per column family > > > > > >> > - > > > > > >> > > > > > > >> > Typically used *instead of*, not alongside, block cache > > > > > >> > > > > > > >> > *Block Cache vs Row Cache (Conceptual)* > > > > > >> > > > > > > >> > *Aspect* > > > > > >> > > > > > > >> > *Block Cache* > > > > > >> > > > > > > >> > *Row Cache* > > > > > >> > > > > > > >> > Cached unit > > > > > >> > > > > > > >> > HFile block (e.g. 64KB) > > > > > >> > > > > > > >> > Row / column family > > > > > >> > > > > > > >> > Optimized for > > > > > >> > > > > > > >> > Scans, sequential access > > > > > >> > > > > > > >> > Random small reads, hot rows > > > > > >> > > > > > > >> > Memory efficiency for small reads > > > > > >> > > > > > > >> > Low (unused data in blocks) > > > > > >> > > > > > > >> > High (cache only requested data) > > > > > >> > > > > > > >> > Rows spanning multiple blocks > > > > > >> > > > > > > >> > Multiple blocks cached > > > > > >> > > > > > > >> > Single cache entry > > > > > >> > > > > > > >> > Read-path CPU cost > > > > > >> > > > > > > >> > Decode & merge every read > > > > > >> > > > > > > >> > Amortized across hits > > > > > >> > > > > > > >> > Cloud / object store fit > > > > > >> > > > > > > >> > Necessary but expensive > > > > > >> > > > > > > >> > Reduces memory & I/O amplification > > > > > >> > > > > > > >> > Block cache remains essential; row cache targets a *different > > > > > >> optimization > > > > > >> > point*. > > > > > >> > > > > > > >> > *Non-Goals (Important)* > > > > > >> > > > > > > >> > > > > > > >> > - > > > > > >> > > > > > > >> > Not proposing removal or replacement of block cache > > > > > >> > - > > > > > >> > > > > > > >> > Not suggesting this be merged into HBase core > > > > > >> > - > > > > > >> > > > > > > >> > Not targeting scan-heavy or sequential workloads > > > > > >> > - > > > > > >> > > > > > > >> > Not eliminating row reconstruction entirely > > > > > >> > - > > > > > >> > > > > > > >> > Not optimized for write-heavy or highly mutable tables > > > > > >> > - > > > > > >> > > > > > > >> > Not changing HBase storage or replication semantics > > > > > >> > > > > > > >> > This is an *optional optimization* for a specific class of > > > workloads. > > > > > >> > > > > > > >> > *Why I’m Posting* > > > > > >> > > > > > > >> > This is *not a merge proposal*, but a request for discussion: > > > > > >> > > > > > > >> > > > > > > >> > 1. > > > > > >> > > > > > > >> > Do you see *row-level caching* as relevant for modern HBase > > > > > >> deployments? > > > > > >> > 2. > > > > > >> > > > > > > >> > Are there workloads where block cache alone is insufficient > > > today? > > > > > >> > 3. > > > > > >> > > > > > > >> > Is a coprocessor-based approach reasonable for > experimentation? > > > > > >> > 4. > > > > > >> > > > > > > >> > Are there historical or architectural reasons why row cache > > > never > > > > > >> landed > > > > > >> > in HBase? > > > > > >> > > > > > > >> > Any feedback—positive or critical—is very welcome. > > > > > >> > > > > > > >> > Best regards, > > > > > >> > > > > > > >> > Vladimir Rodionov > > > > > >> > > > > > >> > > > >
