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条记录。