相关文章推荐:
海里数据存储之存储设计(二)
Je的排版真的让人难过......
从本文开始着重讲解存储细节,思路比较飘逸,观者多包涵。
翻译了一篇Redis作者antirez的文章做为本文的切入点,翻译得不好,这部分可以大致一览,后面会有分析。
Append Only和Reuse Blocks的一些区别
对于一颗append only btree(以下简称AOB)来说,最有趣的属性就是它不可能出现corrupt(可以理解为数据不一致状态)。另外一个有趣的属性就是并发访问没有任何问题,因为无论你访问根节点或其它节点,它们总是一致的(Valid)。
但是有一点我不喜欢的,AOB需要一个额外的Compaction(压缩)进程,否则文件会越来越大。如果你的访问需求是绝大部分是读,那么这样是没问题的。但如果你有非常多的写需求,那么问题就来了。
试想一下:如果你的写请求非常大,已经到了磁盘IO的极限,此时你的AOB文件会越来越大,你需要Compaction。但是你已经达到了IO瓶颈,这时你是重新开一个文件还是重写这棵树呢?这些额外的IO将会影响到这棵btree的性能。你能先降低写请求来降低这种冲撞吗?很遗憾不能,另外,rewrite并没有compact这个文件的速度快(大量随机写).
我希望我的系统性能能尽可能的高,因此我不喜欢这样的设计。虽然它在很多情况下可以运转良好,但是我可以用不rewrite的单文件取得更好的效果。
但是这样的情况下,btree可能会很容易出现corrupt,特别是在你不使用fsync系统调用的情况下。磁盘或操作系统可能会重新排序这些写操作,那么假设你要做这些事情:
l 创建一个新节点
l 链接这个节点到某个老的节点
如果在这两个操作之间没有调用fsync,那么有可能写操作被重排序了,那么会可能这个链接被先于节点写入了磁盘。如果在这两个操作之间发生了crash,那么此时你的树是corrupt的(有一个节点找不到它的子节点)。Append only和reuse blocks之间是矛盾的吗?未必。
在我的实验中,我发现了一个可能可以解决这个问题的办法,虽然它不存在于任何一本算法书中。那就是,如果我的空闲节点有一个保障机制呢(60秒内不被重用)?
在这样的情况下,近期的节点将不会被重用。
不幸的是,我们仍然需要更改根节点的指针,那么fsync仍然需要每次调用以保证数据一致。
Append only和Reuse block之间的抉择
毫无疑问,正如每一种NoSQL都有其适用场景,这里每一种访问需求都有不同的答案,针对用户的访问需求做决定和测试产品是唯一正确的选择。
简单来说,antirez的观点就是:
1.
Append only btree不会出现数据不一致的情况。因为它是只追加的,没有重用文件中的失效块。因为在block I/O layer,内核会做一些IO上的调度,以致我们的IO请求会和我们预期的不一致。(FIXME)这一点我后面会开一篇文章详细讲解。
2.
Append only btree的过期数据清理会是很大的问题,很可能会出现compaction永远赶不上write,这样就会一直在做compaction。
关于这一点,我曾经在内部邮件里跟人探讨过,过期数据清理如何才能不影响系统性能。
最重要的两点:
a) 数据文件分多文件。在这一点上除了Berkeley DB Java Edition(以下简称JE)我还没有见到哪个NOSQL产品是如此设计的。
b) Btree的数据结构。这一点其实要略次,不如上一点重要。
下面就JE的compaction(官方称clean)操作进行讲解:
目前JE里面的clean操作即这里的compaction,后台clean线程会根据其记录的数据目录下每个文件的utilization(利用率)判断是否需要对该文件执行clean操作,默认的配置是5%,如果某个文件有效数据低于了5%,那么clean线程将会读取这个文件里面的有效数据,append到目录下的最后一个文件(这个操作是可以在内存中的,叫defer write),最后直接删除这个文件,整个流程是可以多线程并行的(每个线程对应当前的若干文件)。另外,最重要的是,因为b+tree的设计读取某个节点需要将其父节点load到内存(父节点维护了到子节点的指针及子节点的key),因此即使进行所有数据的clean,那么只需要其b+tree非叶节点在内存中,你只需要在父节点上删除指向该节点的指针即可,除了最后拷贝文件的那5%的有效数据(这些数据还很有可能在Cache里),基本不会存在任何的io操作(删除文件并不耗时)。以1亿数据量为例,假设单条记录是1kb,默认每个非叶子节点可以有128个子节点,也就是说只要你为JE分配4.5GB内存,那么你的B+tree所有索引(非叶子节点,100w个左右)都可以在内存中了,此时你做clean的话,其IO消耗几乎可以不计了。这一设计在JE中叫Lazy migration。
看到这里我想大家应该就能明白,对于append only file,为什么多文件的设计会更好,这也算是解决了去年我的海量数据存储之Key-Value存储简介一文中的伏笔。
而选择B+tree而不使用Hash的原因又多了一个-_-。
至于Reuse blocks为什么不好,下面给出几条数据:
SSD盘上读、写、擦除操作耗时依次是:
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的整个生命周期;再接下来会就事务设计做详细讲解。
分享到:
相关推荐
这里提出了一种基于分布式计算技术进行管理和存储海量海洋科学数据方法,构建了海量海洋科学数据存储平台解决方案,采用Linux集群技术,设计开发一个基于Hadoop的海量数据存储平台.系统由五大模块组成,有系统管理模块、...
文件系统技术内幕:大数据时代海量数据存储之道.docx
信息时代的发展必然导致海量的数据,海量数据的存储成为一个开发人员必须要关注的问题,本文介绍了存储模式的发展历史,并通过分析各个存储模式的优缺点,给开发人员在存储的时候提供建议
关于云计算的海量数据存储模型关于云计算的海量数据存储模型关于云计算的海量数据存储模型
基于云计算的图书馆海量数据存储研究 云计算 海量数据 数据存储
海量数据分布式存储方案的分析与设计,乔宇,,随着网络用户的不断扩大,企业内部网络数据、Internet上的数据、电子邮件, 无数个不同的商用软件和数据库数据使数据量爆炸性增长,��
海量数据存储解决方案.pdf
遥感影像 海量数据 存储技术 海量遥感数据 存储技术
高速海量数据存储的设计与实现,杨晴宇,赵海盟,为了满足当今航空摄影测量面临的大幅面图像数据高速存储的需求,本文介绍了一种用于数字航摄仪的高速海量数据存储系统,系统具有
海量数据分布式存储.pdf
一种基于云计算的海量数据分布式存储策略.pdf
mysql海量数据存储与优化
拟化技术,提出了基于云计算的海量数据存储模型。将医院信息化的海量数据部署在Hadoop 平台上,根据云计算的核心算法 MapReduce 来处理数据,最后将数据存储在虚拟资源池中。通过实际的应用,该模型可以很好地克服...
为了研究应对此挑战的海量数据存储技术,通过分析煤矿应急管理海量数据的来源及其特点,设计了云计算环境下基于NoSQL的煤矿应急管理海量数据存储方式,并对煤矿应急云平台进行了Hadoop基准测试,同时利用陕西黄陵矿业...
本书针对互联网应用的特点,分别从关系型数据库,新兴系统做出对比
基于数据网格的分布式处理后海量数据的存储及管理,刘庆慧,,研究基于数据网格的分布式处理后海量数据的存储及查询问题。首先,根据软件不同组件的功能以及对于数据的要求,将海量数据进行分
比较好的论文,无论是格式还是内容都比较好
海量数据的高效存储 --- 淘宝云梯极限存储的原理和实践