时序数据库基石：LSM Tree的辅助优化
场景：
LSM Tree其实本质是一种思想，而具体是否需要WAL，内存表用什么有序数据结构来组织，磁盘上的SSTable用什么结构来存放，是否需要布隆过滤器来加快不存在数据的判断等都需要根据业务场景来做特定优化
常见优化：
提示写性能：
-
假如对写操作的吞吐量比较敏感，可采用日志策略（顺序读写，只追加不修改）来提升写性能。存在问题：数据查找需要倒序扫描，花费很多时间。比如，预写日志WAL，WAL的中心概念是数据文件（存储着表和索引）的修改必须在这些动作被日志记录之后才被写入，即在描述这些改变的日志记录被刷到持久存储以后。如果我们遵循这种过程，我们不需要在每个事务提交时刷写数据页面到磁盘，因为我们知道在发生崩溃时可以使用日志来恢复数据库：任何还没有被应用到数据页面的改变可以根据其日志记录重做（这是前滚恢复，也被称为REDO）。使用WAL可以显著降低磁盘的写次数，因为只有日志文件需要被刷出到磁盘以保证事务被提交，而被事务改变的每一个数据文件则不必被刷出。
-
压缩：对数据block进行压缩，通过增加占用CPU压缩和解压缩资源来降低数据block磁盘空间占用和读写时间。
-
批量写：LSM Tree数据写入性能已经很高了，但是批量操作时可以节省网络传输RTT时间。
-
将数据进行分片（对于网盘尤为合适，其不同文件在不同后端存储集群节点，可以并发写）：这样多个分片可以并行写，如果数据路由处理得当，也可以提升数据查询速度。但是增加了维护多个分片数据读写的复杂度。
-
设计合理的多级索引
-
在允许情况下关闭自动SSTable合并，在业务量低的时间段强制执行SSTable合并。
提升读性能：
-
二分查找: 将文件数据有序保存，使用二分查找来完成特定key的查找。分为文件名的二分查找和内容的二分查找
-
稀疏索引：文件内容如果都是有序的，那么针对文件里的内容的key建立其offset的稀疏索引就可以实现快速文件内容查找
-
倒排索引：将数据里的关键信息用倒排索引存起来，这样根据倒排索引能知道哪些关键信息在哪些文件，从而定向读取
-
布隆过滤器：进行查询时，首先检查布隆过滤器。如果布隆过滤器报告数据不存在，则直接返回不存在。否则，按照从新到老的顺序依次查询每个 segment。
-
TableCache：如：LevelDB 不仅提供了Bloom Filter 减少查询过程的磁盘 I/O，还利用缓存将频繁读取的 SSTable 驻留在内存中。因为程序在运行时对内存的访问具有局部性的特点，程序在对某一块的内存请求会非常频繁，如果这一块内存在第一次请求之后就被缓存，那么会大大提升之后的数据读取速度。所以，缓存设计的是否合理有效，在于缓存的命中率高不高。
