数据密集型应用设计-笔记(2) 后端

哈希索引假如数据库存储全部采用追加式文件组成，可以用key表示键值，value标识偏移量来组成索引。
如果一直追加到一个文件，可能会用尽磁盘，所以需要将日志分解成一定大小的段，当文件达到一定大小的时候就关闭它，并将后续文件写入新段中。可以在之前的段上执行压缩，即丢弃多余的键，只保留最每个键的最新值。
冻结的段合并和压缩过程由后台控制。
哈希索引局限性：

哈希表必须全部放入内存，如果有大量的键，则需要把哈希放入磁盘，就会造成随机磁盘IO访问，效率很低。
区间查询效率低。

SSTABLE LSM-TREE SSTable又称为排序字符表（Sorted String Table），它需要将上文描述的k-v对存储按顺序存储，它有以下优点。

合并段的时候更高效，可以使用类似于归并排序算法，产生新的案件排序的合并文件段
在文件中查找特定键时，不需要保存整个哈希表，可以用稀疏索引，几千个字节用一个键就够了
读请求需要扫描范围内多个k-v对，可以考虑将记录保存到一个块中并压缩，然后稀疏索引指向开头，以减少IO。

使用压缩合并的引擎一般都叫LSM引擎（Log-Structed-Merge-Tree）
工作流如下：

写入时，先保存到内存中的平衡数据结构中（如红黑树）
内存表大于某个阈值时，将其作为SSTable文件写入（顺序写入），并生成一个新的内存表
处理读请求，先尝试内存表，然后最新的磁盘段文件，然后次新的段文件
后台进程周期性的执行段合并与压缩，丢弃被覆盖或者删除的值

性能优化

查找不存在的数据时，可能要回溯到最旧的文件，可以用布隆过滤器筛选
大小分级、分层压缩

B-Tree 这个就不多赘述了，网上资料很多
优化

通过预写日志（WAL）的方式存储数据库的操作，防止系统崩溃时数据丢失。
保存键的缩略信息
顺序存储页

LSM-tree VS B-tree 【数据密集型应用设计-笔记(2)】LSM能承受更多写入吞吐，因为它是顺序写入。LSM磁盘文件也比B-tree小很多，他没有碎片化空间，定期重写SSTable消除碎片化。
LSM读取性能较弱，当磁盘执行压缩操作时，容易发生读写请求等待，较高百分位数相应时间可能会很高。不限制写入速率可能会出现合并速率跟不上写入速率从而造成磁盘空间不足。