第一届阿里云PolarDB数据库性能大赛总结

阿里云第一届数据性能大赛-初赛总结

只参加了初赛，复赛没时间参加。最终初赛结果top 59/1653，第一次参加这种性能比赛，收获颇丰。

比赛总体分成了初赛和复赛两个阶段，整体要求实现一个简化、高效的 kv 存储引擎

初赛要求支持 Write、Read 接口。

复赛在初赛题目基础上，还需要额外实现一个 Range 接口。

程序评测逻辑分为2个阶段：

1）Recover 正确性评测：

此阶段评测程序会并发写入特定数据（key 8B、value 4KB）同时进行任意次 kill -9 来模拟进程意外退出（参赛引擎需要保证进程意外退出时数据持久化不丢失），接着重新打开 DB，调用 Read、Range 接口来进行正确性校验

2）性能评测

随机写入：64 个线程并发随机写入，每个线程使用 Write 各写 100 万次随机数据（key 8B、value 4KB）

随机读取：64 个线程并发随机读取，每个线程各使用 Read 读取 100 万次随机数据

顺序读取：64 个线程并发顺序读取，每个线程各使用 Range 有序（增序）遍历全量数据 2 次注： 2.2 阶段会对所有读取的 kv 校验是否匹配，如不通过则终止，评测失败； 2.3 阶段除了对迭代出来每条的 kv校验是否匹配外，还会额外校验是否严格字典序递增，如不通过则终止，评测失败。

第一次参加这种性能大赛，想着是先实现几种基本的kv模型,再调优。于是经过网上资料调研，先初步实现了几种基本的存储模型:BitCask、LSM。这时key,value是存在一起的，单独维护了索引文件，LSM树中采用超过阈值则进行compaction操作，即k路归并操作。

内存中的Immutable MemTable：只能读不能写的内存表，为了不阻塞写操作，在一个MemTable满了的时候会将其设为Immutable MemTable并开启新的MemTable;
磁盘中的SSTable：存储的就是一系列的键值对;
LSM Tree中分层: 使用双端队列进行MemTable的存放，这样在查找时可以遵循LRU原则，增加了内存hit，一定程度上优化了查找效率；
查询时增加了布隆过滤器以加速查找,在每个SSTable内进行二分查找;
WAL：write ahead log：先写log，再写kv,以防止断电数据的丢失

于是早早地写好了第一天开评测就线上测试，结果总是超时（官方限定一小时内没跑完则超时）。于是就沉迷优化代码，去掉重量级锁，改为轻量级锁，线下使用JProfile等工具进行性能调优。奈何无论如何调优，线上总是超时，偶尔还莫名其妙的OOM。经过几天debug，也没有任何起色。

就在快要放弃时，经过一名大神提点，突然发现可能根本是我的方案就有问题。

才发现自己忽略了比赛很重要的一个前提：存储设备是SSD！而不是一般的磁盘。

于是再次调研，发现一篇论文：WiscKey: Separating Keys from Values in SSD-conscious Storage 是专门针对LSM在SSD上做的优化。核心思想就是将key 、value分开存储

并且了解到，本次比赛的 key 共计 6400w，分布比较均匀。于是经过和队友的讨论，觉得可以将key、value分开存,这可以解决写放大问题，但是线程竞争呢？64个线程，实际线下测的时候每次并发跑的最多50多个，总会有好几个线程被阻塞。于是查阅资料，发现可以使用“数据分桶”的思想，

于是，我们赶紧重新实现了一版BucketDB,按照分桶的思想，进行新的一轮测试，终于，这次有了姓名！

数据分桶的好处，可以大大减少顺序读写的锁冲突，而 key 的分布均匀这一特性，启发我们在做数据分区时，可以按照 key 的位进行设计hash函数，将高几位相同的key都分进一个桶。

将key、value 分开存，则key和value文件的write pos始终会保持一致，即索引只要存储key的file 的write pos就行了，也即当前file的长度
key 分桶的hash 函数的设计：按照当前线程id，可以分到不同的桶中,根据 key hash，将随机写转换为对应分区文件的顺序写。

之后想到了几个优化思路：

Heap ByteBuffer会有内存泄漏！！： Fixing Java‘s ByteBuffer native memory "leak"

Heap bytebuffer会为每个线程都保持一个直接内存拷贝！
ThreadLocal ====> 可能导致内存泄漏！！！
ThreadLocal 通过隐式的在不同线程内创建独立实例副本避免了实例线程安全的问题

对于已经不再被使用且已被回收的 ThreadLocal 对象，它在每个线程内对应的实例由于被线程的 ThreadLocalMap 的 Entry 强引用，无法被回收，可能会造成内存泄漏。