版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
BwTree
面向场景：
主要是内存场景
打击点：
主要是内存场景：
- LOCK：引入的上下文切换开销
- CPU：本地更新引入的Cache coherence
- 写放大问题：通过增量 + append的方式减少写入数据量，增加Flush过程中的Batch效果
主要方案：
- 索引：btree
- 内存和磁盘都是append写，使用mapping_table解决物理地址频繁变更的问题
- lock_free：append + cas 实现无锁
- SMO的原子操作：double cas
- hash_lock_free：mapping_table
被打击点：
- 乐观锁：更新的失败率在万分之二，Merge和SMO的失败率在5%
- mapping_table的持久化：单独一个表，引入新的IO
- delta链表长度导致CPU效率：Merge Delta
- delta链表长度导致IO开销：
- merge delta link的IO开销：
- GC：
- 日志类型的相关性不好：对读IO不大友好，从感知上，一个BLOCK的读取，最好这个BLOCK存储的内容都是相关的
结合LLAMA那篇论文，BWTREE在IO上的工作主要是：
- 批量刷盘
- 在持久化delta时，把多个delta合并成一个c-delta，然后进行持久化。
- 在GC过程中，把页面搞成连续的，或者叫合并。
如果按照40写放大计算，一个页面8KB，单行160字节，可以存储50条记录。