听小董谝存储 六

目录

序章

关于内存与磁盘的资源组织

关于大数据与小数据

关于磁盘里block的回收

---

序章

前一章，我们大体了解了存储层的大体设计原理。但是解决了一个问题，又冒出一堆问题。具体的问题有

Bolock里面有脏数据了，怎么回收。

索引节点感觉还有几个问题，但是我一时说不上来。

断电了咋办，数据怎么恢复？

block是怎么组织的，内存是怎么组织的。

这一节，就解决这几个问题。

关于内存与磁盘的资源组织

小菜：请注意，我并不是想实现一个存储系统，老师你只用说大体设计就OK，不用牵扯太多细节哦。

老鸟：OK。既然说到了内存与磁盘的，那么咱们就得理清楚上一章的数据结构里，哪些是放在内存的，哪些是放在磁盘的。如下图一，小菜，谈谈你的看法。

                           

                                                             图一 存储层涉及的数据结构

小菜：图一左边黑色的hash桶，不用说就放在内存里。

中间黄色的索引块不用说，也是内存里。

蓝色的DataRegion也是内存里的，绿色的数据块也是内存的。

磁盘里一个个block是逻辑单位，但是也是分配在磁盘里的。下刷到磁盘里的黄色的数据块自然也是放在磁盘里的。

老鸟：OK你说的很清楚。那你就说说这几个结构的初始化和申请销毁流程吧。

小菜：OK。首先系统初始化的时候，除了图一画出来的结构外，应该还有几个逻辑管理模块。包括

• IndexingManager：管理上图黄色索引块的创建与回收。

每次新来一个set请求的时候（这个key之前并不存在），IndexManager都会创建一个索引节点。

当删除了一个数据后，系统只是在索引节点和DataRegion里面做一个标记。等到下刷的时候，再删除索引节点。

• BlockManager：管理磁盘上block的创建与回收

系统初始化的时候，BlockManager将整个磁盘（除了必要的恢复模块，元数据模块外）抽象成N个Block。

数据下刷的时候，系统向BlockManager申请一个block。至于什么时候回收Block，咱们后面再说。

• DataRegionManager：管理DataRegion的初始化，以及数据在DataRegion区域的创建。

还记得循环队列是怎么实现的么？

小菜：OK你说的我都懂了。至于这些manager具体怎么管理各自的资源，就是具体的实现了。咱们暂时可以忽略。不过关于IndexingManager我有一个问题，假如一个索引节点占据空间30个字节，但是某些键值对总共才10个字节。那岂不是元数据占据的空间比真实的数据占据的空间还大？

老鸟：孺子可教，你提出了大数据与小数据的区别存储问题。

关于大数据与小数据

老鸟：这一章的背景是：如果数据本身很小，甚至小于一个常规索引节点的大小。那么按照之前的存储方案，资源的利用率就不是很高。所以我们引入了混合索引节点，以区别于之前的常规索引节点。来，小菜，就按照图三，说说你的理解。

小菜：为了叙述方便，我先给索引起个名字吧。如下图二，中间索引节点里，那些一个数据项就占用一个索引节点的数据，就叫大数据；反之多个数据项（例如上面那个红色块，DataD，DataE公用它）公用一个索引节点的数据，就叫小数据。一个大索引里面只有一个大数据，一个小索引里面有n个小数据。同时KeyIndex的每一个槽位，可以有多个大索引节点，但是只能有一个小索引节点。那么大数据与小数据的分界线是多大呢？可以考虑以2KB，作为阈值。

                                                       

                                                                                    图二 大数据与小数据

老鸟：术语说清楚了，那我就说说读写流程吧。对比一下图三和图二，我们又写了一个DataF，它是个小数据，且也hash到了5号槽位。那就先把5号槽位里面那个小索引节点对于的数据都读出来，然后把DataF加进去，再把整体数据重新写入DataRegion。

小菜：那么如果我并不是新写了一个DataF，而是要覆盖写DataE呢？

老鸟：还是把DataDE都读出来，修改之后，重新写入DataRegion。

小菜：如果读DataF，首先我并不知道这个数据是否存在；而且就算存在，到底是大数据，还是小数据也不知道。那就直接通过小索引节点把整个DataDEF都读出来，再从DataDEF里面寻找DataF，如果找到那就直接返回，如果没找到，就说明至少不是小数据，就把大索引节点一个个都比较一下。

老鸟：说完了么？有没有考虑过本来是小数据，后面覆盖写成大数据；或者本来是大数据，后面覆盖写成小记录？甚至数据都已经下刷到磁盘了，然后数据由大变小或者由小变大。

小菜：如果考虑到数据大小的变化，那之前的读写流程就不对了。我想想具体细节哦。

老鸟：这些逻辑，你自己想。其实只要你意识到有可能大小转换，那问题就算解决了一大半了，这里面太细节了，我就不多说了。整体来说，对小数据的处理思路就是把多个小记录打包起来，按照一个大数据来处理。

                                                       

                                                                                    图三 小数据的写流程

关于磁盘里block的回收

                                                       

                                                                                    图四 脏数据的图示

老鸟：小菜，说说你对图四的理解。

小菜：DataABC先下刷到block1，后来DataDEF作为3个小数据打包存储，再后来DataB重写。最后DataDEF和DataB又被下刷到block2。

老鸟：那现在的问题是什么呢？

小菜：DataB的数据其实已经存放在block2里面了。那么block1里面就等于是有垃圾数据，应该被清理。

老鸟：前面已经说了，有个BlockManager，它管理所有的block的使用与释放。每个block的最大体积都是512KB这个值不变。同时还有实际体积和有效体积。假定block1里面DataABC的体积分别是100KB，300KB，70kb。那么block1的实际体积就是470KB，有效体积就是170KB（当把DataB的索引指向从block1移动到block2的时候，就已经从block1的有效体积里面减去了300KB）。BlockManager里面有一个按照block有效体积从小到大排列的list。每次取出前两个最空闲的block进行合并就OK。

                                                       

                                                                           图五 回收后的block                       

老鸟：图五就是把block1和block2合并的结果。小菜，说说流程吧。

小菜：首先把block1和block2里面的所有元素都读出来，然后依次遍历索引节点，如果发现某个索引节点指向的位置并不是在自己所在的block里（例如block1里面的DataB对应的索引节点指向的是block2），就忽略它。然后把有效数据都重新写入block（如果一个block能写完就写到一个，如果一个block不够，就写到两个block）。然后把原来的block1和block2回收。

---

老鸟：总结一下，到现在为止我们的存储系统有以下特点

• 1 支持get，set，del等操作。且key的长度有限制（一般是512B，限制主要来自于索引节点），value的长度也有限制（不能大于一个block的体积，也就是512KB）
• 2 数据先写到内存，写到一定大小后统一下刷到磁盘。
• 3 数据存储在磁盘里的一个个block里面，系统会定时做磁盘里面的block回收。
• 4 整体结构适合写多读少的业务。（因为读的时候，如果内存里没有，就得读磁盘。当然可以考虑加一个ReadCache，小菜你后面考虑一下）
• 5 当数据存在于DataRegion里，且没有下刷之前，发生断电，这些数据就丢了（所以有三份存储，另外这里也可以升级一下，加入binlog，小菜你也考虑一下方案）

老鸟：今天就暂时讲到这里吧。明天讲数据安全性的一些问题，包括数据恢复。