Ordered Bucket Index Shards in RGW
summary
RGW moves from hash-based shards to maintaining lexical ordering across shards so listings iterate shards sequentially and avoid querying every shard; shard boundaries live in the bucket instance OMAP as cut points, requiring lookups (cached where possible). Resharding becomes local resharding by splitting or joining consecutive shards, reducing global locks. Implementation uses a hierarchical numeric shard naming (avg ~4 levels in simulation), but this creates hotspot risk, OMAP size limits (100k keys) and version-bucket constraints (~49k version ceiling per object).
AI-written summary · about
chapters (8)
- 0:00Introduction and speaker background
- 2:27Bucket indexing basics and resharding
- 5:58Hashing bucket index shards explained
- 8:07Ordered bucket index shards concept
- 11:58Status and simulation results
- 15:06Q&A session part 1
- 20:14Q&A session part 2
- 22:45Q&A session part 3
related talks
38mExploring RocksDB in RGW: How We Manage Tombstones
24mWhen and How Should you Shard?
37mBeyond Hot Spots: Revolutionising OpenSearch Performance Through Heat-Aware Operations
12mROART: Range-query Optimized Persistent ART
06mWhen All Context Matters: Extended Cache Augmented Generation
29mCeph Object Storage Overview, Capabilities and Future Plans
31mSharding 2.0: Unlocking Infinite Search Scalability in OpenSearch
45mMonitoring Your OpenSearch Cluster Effectively