分布式第二章 单机存储系统

单机存储引擎就是哈希表，B树等在磁盘上的实现。单机存储系统是单机存储引擎的一种封装，对外提供文件、键值，表格或关系模型.
2.1.2 IO总线
存储系统瓶颈一般在于IO。
2.1.3 网络拓扑
传统分为三层，接入层–>汇聚层–>核心层。该结构的问题在于可能有很多接入层的交换机接到汇聚层，很对汇聚层交换机接到核心层。
接入层交换机包含48个1GB端口以及4个10GB上行端口，汇聚层和核心层的交换机包含128个10Gb端口。同一个接入层下服务器之间带宽为1GB，不同接入层交换机下服务器之间带宽小于1Gb。由于同一个接入层的服务经常部署在一个机架内，减少跨机拷贝大量数据。Hadoop HDFS默认存储三个副本，其中两个副本放在同一个机架，就是这个原因。
为了减少网络对拓扑结构的依赖，Google在2008年的时候把网络改造为扁平化拓扑结构，即三级CLOS网络，同一个集群内最多支持20480台服务器，且任何两台服务器都有1GB带宽。CLOS网络需要投入更多交换机，带来的好处也是明显的，在涉及系统时不需要考虑底层网络拓扑从而很方便地将整个集群做成资源池。
同一个数据中心的传输延时比较小，来回1ms之内，不同地区的数据中心传输延时由 距离*2/光速 = 延时。
2.1.4 性能参数
存储系统的性能瓶颈主要在于磁盘随机读写。通过缓存减少磁盘随机读操作、将随机写操作转化为顺序写操作，是磁盘读写的两种优化方式.
1500转的SATA盘的顺序读取带宽可达100MB以上，磁盘寻道的时间大约10ms，顺序读取1MB数据的时间为：磁盘寻道时间+数据读取时间，即10ms+1MB/100MB/s *1000=20ms。
固态磁盘SSD的随机读取延迟小，能有很高的IOPS(input/Output Per Second)性能。价格贵。
2.1.5 存储层次架构
从分布式角度看，集群中所有服务器上的存储介质（内存、机械硬盘、SSD）构成一个整体，其他服务器的存储介质和本机存储介质都是一样可访问的，区别仅仅在于需要额外的网络传输及网络协议栈等访问开销。
存储系统的性能主要包括两个维度：吞吐量以及访问延时。设计系统时在保证访问延时的基础上，尽可能提高吞吐量。硬盘和SSD的访问延时的差别很大，带宽差别不大，因此，磁盘适合大块顺序访问的存储系统，SSD适合随机访问较多或对延时要求较高的关键系统。热数据（访问频繁）存储到SSD中，冷数据（访问不频繁）存储到磁盘中。
2.2 单机存储引擎
存储系统的基本功能包括：增删改读，其中读操作又分顺序扫描和随机读。哈希存储引擎是哈希表的持久化实现，支持随机读去，不支持顺序扫描。B树存储引擎是B树的持久化实现，支持顺序扫描，对应存储系统是关系数据库。
LSM树存储引擎也支持顺序扫描。它通过批量转储技术规避磁盘随机写入问题，例如Google Bigtable。
2.2.1 哈希存储引擎
Bitcask是一个机遇哈希表结构的键值存储系统，它支持追加操作，即所有的写操作都只追加而不修改老数据。在Bitcask系统中每个文件都有大小限制，当文件大小达到上限，则生成一个新的文件，老的文件只读不写。新的可写的文件称作活跃数据文件（activate data file）。其他称为老数据文件。
1.数据结构
Bitcask的每条写入操作对应一条记录，每条记录的数据项分别为主键（key）、value内容、主键长度、value长度、时间戳以及crc校验值。数据删除操作也不会删除旧条目，而是将value设定为一个特殊的值用作标识。内存中采用哈希表的索引数据结构，哈希表的作用是通过主键快速定位到value的位置。哈希表中的每一项包含三个用于定位的数据信息，分别是文件编号（file id），value在文件中的位置（val_pos）,value长度，通过file_id对应文件的value_pos 开始的value_sz个字节，就是最终的value。写入时首先将key-value记录追加到活跃数据文件的末尾，接着更新内存哈希表，因此每个写操作对应一次顺序的磁盘写入和一次内存操作。
2.定期合并
BItcask系统中的记录删除或者更新后，原来的记录称为垃圾数据。Bitcask需要定期执行合并操作（将老数据文件扫描并生成新的数据文件，对同一个key的多个操作只保留最新一个记录的原则进行删除）以实现垃圾回收。
3.快速恢复
Bitcask中的哈希索引表是存储在内存中的，如果遇到断电，则需重启扫描所有数据文件生成新的哈希表。Bitcask通过索引文件（hint file）来提高重建哈希表的速度。
索引文件就是将内存中的哈希索引表转储到磁盘生成的结果文件。Bitcask对老数据文件进行合并操作时，会产生新的数据文件，这个过程中还会产生一个索引文件，这个索引文件存储了value的位置（类似内存哈希表）。这样在重启生成内存哈希表时，就会很快了。
2.2.2 B树存储引擎
B树存储引擎支持范围扫描。在mysql InnoDb中，有一个称谓聚集索引的特殊索引，行的数据存于其中，组成B+树数据结构。
1.数据结构
Inno DB按照页面来组织数据，每个页面对应B+树的一个节点。叶子结点保存每行数据，非叶子结点保存索引信息。数据在每个节点中有序存储，数据库查询时从根节点开始二分查找直到叶子结点，每次读取一个节点，如果对应的页面不在内存中，需要从磁盘中读取并缓存起来。B+树的根节点是常驻内存的，因此一次检索最多需要h-1次磁盘IO（h是树的高度）。修改操作首先需要记录提交日志，接着修改内存中的b+树。如果内存中被修改过的页面超出一定比率，后台线程会将这些页面刷到磁盘中持久化。
2.缓冲区管理
缓冲区管理器负责将可用的内存划分成缓冲区，缓冲区是与页面同等大小的区域，磁盘数据可以传送到缓冲区。缓冲区管理器的关键在于替换策略，即选择将哪些页面淘汰出缓冲池。常见算法如下两种。
（1）LRU
淘汰最长时间没有读或写过的块。这种方法的缓冲区管理器会记录每个页面最后一次被访问的时间组成一个链表，每次淘汰链表尾部的页面。
（2）LIRS
LRU大部分情况是不错的，但如果一个查询做了一次全表扫描，将导致缓冲池中的大量页面被替换，从而污染缓冲池。现代数据库一般采用LIRS算法，将缓冲池分两级，数据首先进入第一级，如果数据在较短时间内被访问两次或以上，则成为热点数据进入第二级，每一级内部采用LRU替换算法。以MySQL innoDB为例，内部的LRU链表分为两部分：默认新子链表占5/8，老子链表占3/8.页面首先插入到老子链表，InnoDB要求页面在老子链表停留时间超过一定值，比如1秒，才有可能被转移到新子链表。这样如果有一次全表扫描，页面只会到老子链表，不会转到新子链表。这就避免了新子链表中的页面被替换出去的情况。
2.2.3 LSM树存储引擎
LSM树思想非常朴素，就是将对数据的修改增量保持在内存中，达到指定大小后将这些修改操作批量写入磁盘，读取时要合并磁盘中的历史数据和内存中最近修改的操作。它的优势在于规避了磁盘随机写入的问题，但读取时可能需要访问较多的磁盘文件。本节以LevelDB的LSM树为例来说明。
1.存储结构