mace 记录 -- 写入优化
目前所做的优化 （0.0.11）
- 节点内存完全缓存，随节点淘汰释放 （有效避免插入的查找过程中需要从文件加载数据）
- 延迟 compact，将 compact 移到后台线程，节点在淘汰时进行 compact （提升插入的查找效率，同时提升冷数据加载效率）
- 直接释放 CAS 失败的新节点的内存 （尽量复用同一个arena）
- 增加节点锁 （减少多线程 compact / SMO 竞争带来的内存分配和初始化开销 ）
不太可行的优化
- 单日志，在后台group commit线程写，瓶颈出现在 “完成通知” 上
- compact 仅复制地址指针，插入性能提升3倍，但查询性能下降8倍+，多一层间接带来的
- split/merge直接拷贝 sst 内容，避免 iterator 遍历以及带来的 decode/encode，但无法处理 prefix ，当 split 时，prefix 会变长，但直接拷贝无法释放额外的空间
可能的优化
- sst 分块，每个块有自己的 prefix
总的来讲，由于 B+ 树的性质，SMO 不可避免的需要进行内存拷贝，另外加之Bw树 append-only的性质，不可避免的需要定期将 delta 合并到 base 也需要内存拷贝，那么能做的就是：减少拷贝的次数（频率），特别是多线程环境下，CAS 只有一个线程能成功，而其他线程此前为了 compact 和 SMO 所作的拷贝全都是无效的
一下是优化前后性能对比， 数据源 x.csv
从结果来看（SSD），mace 在查询性能上远超 rocksdb，0.0.10 在插入上不及 rocksdb，而优化后的 0.0.11 只有在1024的key大小下单线程插入时略低于 rocksdb，rocksdb 的 Leader-Follower 写机制（也就是 Group Commit）不能 scale，因为瓶颈不在磁盘上。而在HDD上则比 mace 更有优势，这时的瓶颈就是磁盘，并发的小块写不如单线程大块写，这种情况下可以增加配置，单独在 SSD 上写 WAL （测试发现，大约有6倍多的提升，接近 rocksdb 的水平）