首先非常感谢PingCAP能组织一个非常专业的Rust课程,这对于Rust爱好者来说是一次非常好学习的机会,感谢PingCAP为Rust做出的贡献。该课程持续的做了一个月左右,感谢Brian Anderson大神提供优秀的实现供学员参考。
课程的目标是用Rust逐步实现一个BitCask数据库,详细请看https://github.com/pingcap/talent-plan/tree/master/courses/rust
Project-1
通过内存的KVStore学习了如下内容
- Rust项目工具cargo的作用以及cargo相关的命令
- clap库的使用
- 理解rust工程保组织结构
- 熟悉了标准库HashMap
Project-2
在project-1的基础上增加了error处理,以及数据持久化至硬盘。基本思路是内存的HashMap作为索引,Map的value中是键值对的文件id以及偏移地址和长度。
数据是序列化为json格式后以append log方式写,当旧的数据和删除的数据达到一定阈值,开启合并操作,合并操作是把当前内存索引中存在的数据写入新的文件中。
另外值得一提的是删除是写入一条记录来表示数据删除,同时删除该key索引。后续会执行Merge操作。
Project-3
本次实验主要增加了网络通信和基准测试的模块,对存储引擎抽象为KvsEngine Trait,实现分别是kvstore和sled wrapper。网络模块主要熟悉标准库的API以及通信的Message的定义。
通过的sled以及BW-tree的调研发现 bw-tree的实践并不能超越传统b+tree。在基准测试模块中是对单线程下的set和get进行测试,发现sled的flush会特别的慢,导致测试一直卡在set阶段,sled flush操作将会调用fsync同步整个page,慢是必然的。 sled会定时的执行刷盘操作,因此没必要每次set都进行flush操作。
Project-4
简单的说本次的实验就增加一个点,即所有的接口支持并发的调用,接下来解决的问题是什么数据共享,什么不共享,什么操作需要同步,什么不需要同步?
当然最简单办法是所有的操作都同步起来,顺序执行,但是性能存在问题。整体思路是所有的set和remove操作同步,读操做不同步。
索引以及不变的数据共享,读缓冲不共享,线程私有。
有个问题是索引在写线程中会修改,读线程需要根据索引来定位数据,如果`Arc来共享,那么写线程不能得到可变的引用,如果是用Arc<Mutex>则是同步的方式,直接pass,如果用Arc<RwLock>,还是存在读写互斥的情况,当然会比Mutex效率好点。采用线程安全的SkipListMap会更简单粗暴一些。
总结
其实看着简单的一个系统,做起来其实也会遇到大大小小的问题,整体的感受是Rust真的适合写底层的系统,即有c的力量感又有python的抽象能力,接下来一段时间会做dss课程,有兴趣的朋友可以互相交流学习。
https://github.com/TheLudlows/talent-plan-rs