VladRodionov commented on PR #7291: URL: https://github.com/apache/hbase/pull/7291#issuecomment-3746782600
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. -- 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]
