小扇区场景下B树如何存储大尺寸key与value？

大尺寸Key/Value在512字节扇区场景下的存储方式 #

B树的核心作用是索引排序，要尽量控制节点大小减少IO开销，不要直接把完整大Key/Value塞进B树节点，建议按如下规则设计：

• B树节点仅存储定长索引条目，每个条目固定包含三个字段：Key长度（2字节）、Value长度（2字节）、数据偏移指针（8字节），总长度12字节。长度低于256字节的小Key/Value可以直接inline存储在索引条目后，省去额外读IO。
• 超过长度阈值的大Key/Value统一存入独立的溢出块区域，溢出块按512字节扇区对齐分配，单KV超过单个溢出块大小时采用连续Extent或链式块存储，B树节点仅保留指向溢出块起始位置的偏移指针即可。
• 所有B树节点、溢出块的大小都设置为512字节的整数倍，避免跨扇区读写产生额外IO开销。

放开大小限制后单个B树节点的Key容量 #

该数值没有固定标准，由你设定的B树节点大小和存储策略决定：

• 主流存储引擎的B树节点大小通常设为4KB（8个512字节扇区）或16KB，平衡节点分裂频率和IO放大率，不建议设为刚好512字节：512字节除去节点头（存节点类型、子节点数、兄弟指针等，一般32字节左右）剩余空间过小，会导致B树层数过高，大幅提升随机读的IO次数。
• 以4KB节点、仅存定长索引条目为例：扣除32字节节点头后剩余4064字节，可存储约338个索引条目；如果采用inline存储小KV，容量会根据KV的平均长度对应降低。
• 实际使用时建议预留至少25%的节点空闲空间，避免频繁触发节点分裂合并，所以实际可用的Key容量要在理论值基础上打75折。

可变长数据是否需要替换B树存储 #

不需要完全替换B树，可以根据业务场景做针对性优化，或搭配辅助结构：

• 如果业务中小KV占比超过70%，带inline存储的B树已经足够适用，读性能稳定性远高于其他结构。
• 如果大KV占比偏高，可以改用B+树替代普通B树：非叶子节点仅存Key的排序前缀或索引指针，所有Value统一存在叶子节点，进一步提高非叶子节点的索引条目容量，降低索引层数减少IO。
• 除非你的业务写性能优先级远高于读性能，否则不建议替换为LSM树类结构，B树的读放大远低于LSM树，更适配随机读居多的KV存储场景。

内容的提问来源于stack exchange，提问作者roat