nagisa-kunhah commented on PR #3481: URL: https://github.com/apache/kvrocks/pull/3481#issuecomment-4397166666
@jihuayu Thanks for the suggestions. My understanding is that the Page abstraction is a persistent storage-layout unit, not an application-level cache. I plan to replace the current bucket key layout: ```text InternalKey(ns_key, version, filter_index + bucket_index) -> bucket data ``` with a page-based layout: ```text InternalKey(ns_key, version, filter_index + page_index) -> multiple consecutive buckets ``` The bucket mapping would be: ```text buckets_per_page = page_size / bucket_size page_index = bucket_index / buckets_per_page ``` Each sub-filter would own its own set of pages, so pages are not shared across sub-filters. Also, I would treat `page_size` as the upper bound for a page value, not a fixed physical size. Small sub-filters and the last page of a sub-filter may store less than `page_size` For the first version, I would like to use a fixed internal page size, likely `2KB`, and derive `buckets_per_page` when needed. We can consider making it configurable later, but then `page_size` should probably be stored in metadata because it affects the on-disk layout. Could you confirm whether this matches your expectation, especially: 1. pages are scoped within each sub-filter and are not shared across sub-filters. 2. starting with a fixed internal page size is acceptable for the first version? For the suggestions about `MultiGet` and insertion order, I agree with both points and will update the implementation accordingly. -- 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]
