海量数据存储之存储设计(一)

?

20 microseconds,200 microseconds, 1500 microseconds

擦除操作是写操作的7倍多。也就是说在SSD上，我们重用块的代价远大于重写节点，这还没有考虑写入放大以及SSD寿命的因素，众所周知，SSD在随机写多的情况下性能损耗非常厉害。

结论，这里虽然append only胜出，但是并不是说reuse block不好，至少innodb的成功证明了它是正确的，而如此选择的前提是，数据如果用纯内存去装太不明智了，因为互联网数据访问是有热点的，在“内存是新的硬盘硬盘是新的磁带“到来之前，SSD毫无疑问是这个过度时期的最佳选择。

内存使用

不同的NoSQL对内存的使用方法可能不太一样，但是毫无疑问，即使在号称神速的SSD上，读取数据消耗的时间仍然远大于我们的内存，因此，内存中应该放最热的数据。一般来说，内存使用上有以下三种（其实都是殊途同归）。

Row Cache

?

这是大部分Java为开发语言的存储的首选，由于对底层的控制能力有限，因此采用自己实现的缓存可能会更加有效。这时候有人可能会说，由于虚拟内存的介入，这样很可能会出现双重缓存，事实上，我们一般会将机器的绝大部分内存分配给JVM，比如24G的内存分配给JVM16G或者更多，并且在我的实际测试中，部分row cache+系统Cache结合往往比任意单独的cache更有效。

?

MMAP

这是C程序员同学的首选吧，个人对C不熟悉，不做更多评论。但是有一点，MMAP的设计决定了，活跃数据的总量基本不能超过可用内存太大，否则性能急剧下降，系统不停的做swap。另外，Java调用mmap以后，性能监控会失效或不准确了。

Purely Cache

纯内存的设计，这种设计本身就定位为缓存，这一点我其实还是希望缓存和后端存储不分离，这样系统结构会尽量简单。这一实现上Redis是其杰出代表（虽然它也有持久的概念）。一般来说，这样的系统，网络会是唯一瓶颈。

大致写这么多，下一篇文章会讲Linux IO的一些细节，包括IO调度，监控以及IO的整个生命周期；再接下来会就事务设计做详细讲解。

?

?

?

?