【读书笔记】数据存储与检索

<数据密集型应用系统设计> Chapter 3

事务型工作负载和针对分析型复杂的存储引擎优化有差异。

两种存储引擎：

• 日志结构的存储引擎
• 面向页的存储引擎

数据库的核心

最简单的数据库结构: 哈希表

key-value存储, 调用key,得到value, 底层的存储格式非常简单： 一个纯文本文件。

每行包含一个key-value对

其它需要考虑的问题: 并发控制,回收磁盘空间来控制日志文件大小、处理错误和部分完成写记录等。

为了高效地查找数据库中特定键的值, 需要使用索引来提高查找效率。 基本的设计思路: 通过保留额外的元数据来作为路标帮助定位想要的数据。

最简单的写操作: 直接在文件的末尾追加记录。 哈希索引 最简单的索引策略: 保存内存中的hashmap,将每个键一一映射到数据文件中特定的偏移量，直接找到对应的位置。 使用场景: 每个键的值频繁更新: 比如key是某个视频的url而value是播放的次数(点击量),有很多的写操作,但是没有太多不同的key， 所以即使每个key都有大量的写操作,但是将所有的key保存在内存之中是可行的。

• Q: 如何避免最终将磁盘空间用尽？(或者说如何提高磁盘空间的使用效率)?

• A: 将日志分解成一定大小的段,当文件达到一定大小时就关闭,将后面的数据写入到新的段中,并定时对所有的段进行压缩操作。压缩就是对同样的key值的不同value进行更新,只保留最新的value值。 -> 进阶操作: 并发执行写入和压缩操作

更多的细节问题:

• 文件格式
• 删除记录
• 崩溃恢复
• 部分写入的记录
• 并发控制

追加式添加(不原地更新文件,用新值覆盖旧值)的优点:

• 顺序写可以提高写入速率,特别是在旋转式的磁盘之中
• 如果段文件是追加的货不可变的,那么并发和崩溃恢复要简单很多(因为不会留下部分旧值和部分新值混杂在一起的文件)
• 合并旧段可以避免随时间推移出现数据文件碎片化(内部碎片【进程所需的空间小于分割快,导致剩余的空间没有被利用】，外部碎片【空闲空间被分割为小的块,无法满足进程使用的要求】)的问题

哈希索引的局限:

• 哈希表必须全部放入内存之中
• 区间的查询效率不高,不能支持查找 100-200之间的所有键,而只能采用逐个查找的方式,先找100，再找101,再找102...

SSTables排序字符串表和LSM-Tree SSTable就是讲key-value对按键排序，得到一个排序字符串表。最后合并的段文件 优点:

• 合并段更加简单高效,可以使用合并排序算法,比较每个文件的第一个键值,将最小的键拷贝到输出文件,重复该过程，最后就能够得到一个合并后的按键排序的合并段文件。
• 在文件中查找特定的值时，不再需要在内存中保存所有键的索引,可以直接跳过某些部分直接进行扫描,可以使用稀疏索引,每个段文件使用一个键作为索引。

内存排序可以使用树状数据结构比如红黑树和AVL树,可以按任意顺序插入键并按排序后的顺序读取

B-trees

在索引中存储值

布隆过滤器: 多列索引

转载于:https://juejin.im/post/5c5c3337e51d457fc0574051