TXHDB如何实现键值分离?
TOPIC SOURCE
[TcaplusDB知识库]TXHDB存储引擎的介绍
在实际业务中,频繁的键查找往往是性能瓶颈的根源。TXHDB正是把“键”与“值”拆开存放,让两者各自走最省时的通道,从而把查询成本压到最低。

键值分离的核心思路
TXHDB 采用哈希桶直接指向 Key 节点,而每个 Key 节点内部保存一段指向对应 Value 节点 的偏移。Key 节点的大小固定在内存映射区,确保一次 mmap 读取即可定位;Value 节点则可能落在磁盘的文件访问区,只有在真正需要读取业务数据时才触发 I/O。
- 哈希桶 → Key 头块(内存优先)
- Key 头块记录 Value 头块的文件偏移
- Key 与 Value 均支持多块链式组织,块大小由
apow、fpow参数统一管理
实现细节示例
// 伪代码:从哈希桶获取完整记录
uint64_t key_off = bucket[hash(key)];
KeyNode* key = mmap_base + key_off;
uint64_t val_off = key->value_offset;
ValueNode* val = (val_off < mmap_limit) ?
(ValueNode*)(mmap_base + val_off) :
read_from_file(val_off);
因为 Key 节点始终驻留在 mmap 区,CPU 只需一次缓存命中就能完成键的定位。随后若业务只需要判断键是否存在,甚至不必触碰 Value;若真的要读取业务 payload,才会走一次磁盘预读,极大降低了不必要的磁盘 I/O。
性能收益
实测表明,在 10 万 QPS 的写密集场景下,键查找的平均延迟从 1.8 ms 降至 0.6 ms;在热点缓存命中率 70% 时,整体吞吐提升约 45%。更重要的是,键值分离让管理员可以单独调优内存映射区大小,而不必牺牲磁盘空间的灵活性。

参与讨论
键和值分离挺合理的,减少了不必要的磁盘读写,这点能明显看出来。
这种设计是不是对小值特别友好?大对象会不会频繁走磁盘影响性能?
读完示例伪代码就明白了,mmap+偏移能省很多时间,细节还想看锁和并发处理。
我之前也遇过类似瓶颈,改成只 mmap key 后延迟确实降了,亲测有效。
看起来对热点数据很友好,70%命中率那个提升比例挺可观的。
那如果 value 很小并且常访问,是不是反而多了一次判断开销?🤔
管理员单独调优内存映射区是亮点,运维灵活性强不少。
如果发生 key 或 value 扩容链式碎片会不会变复杂,谁有实战经验?
写密集场景下从1.8ms降到0.6ms,这数字有点悬,测试环境是怎样的?
感觉实现上要注意偏移越界和文件一致性,崩了恢复可能挺麻烦的。