LSM-Tree(BigTable的理论模型)(转)
2012-07-11 16:20
253 查看
Google的BigTable架构在分布式结构化存储方面大名鼎鼎,其中的MergeDump模型在读写之间找到了一个较好的平衡点,很好的解决了web scale数据的读写问题。
MergeDump的理论基础是LSM-Tree (Log-Structured Merge-Tree), 原文见:LSM Tree
下面先说一下LSM-Tree的基本思想,再记录下读文章的几点感受。
LSM思想非常朴素,就是将对数据的更改hold在内存中,达到指定的threadhold后将该批更改批量写入到磁盘,在批量写入的过程中跟已经存在的数据做rolling merge。
拿update举个例子:
比如有1000万行数据,现在希望update table.a set addr='new addr' where pk = '833',
如果使用B-Tree类似的结构操作,就需要:
1. 找到该条记录所在的page,
2. load page到内存(如果恰好该page已经在内存中,则省略该步)
3. 如果该page之前被修改过,则先flush page to disk
4. 修改数据
转自http://www.cnblogs.com/raymondshiquan/archive/2011/06/04/2072630.html
上面的动作平均来说有两次disk I/O,
如果采用LSM-Tree类似结构,则:
1. 将需要修改的数据直接写入内存
可见这里是没有disk I/O的。
当然,我们要说,这样的话读的时候就费劲了,需要merge disk上的数据和memory中的修改数据,这显然降低了读的性能。
确实如此,所以作者其中有个假设,就是写入远大于读取的时候,LSM是个很好的选择。我觉得更准确的描述应该是”优化了写,没有显著降低读“,因为大部分时候我们都是要求读最新的数据,而最新的数据很可能还在内存里面,即使不在内存里面,只要不是那些更新特别频繁的数据,其I/O次数也是有限的。
所以LSM-Tree比较适合的应用场景是:insert数据量大,读数据量和update数据量不高且读一般针对最新数据。
文章读下来有以下几点感受:
1. 基本思想早就有了,作者给出了较好的表现形式。
2. Merge是page/block级别的,而不是BigTable中的文件级别的。这一点主要原因可能是BigTable在分布式场景下做block级别很困那,而且GFS也不支持修改。
3. 其提出的比较标准比较有趣,将磁盘容量,转速等结合起来给出一个以美元为单位的cost标准,然后跟B-Tree结构的实现做了比较,结果当然是大大胜出。但是这里我觉得作者有些比较是不合理的,比如LSM使用log而B-Tree没有使用,这显然对B-Tree不公,其实B-Tree如果使用log,写入性能应该不比LSM差,顺序读取可能差一些。
4. 在Multi components 中,提出Ci/Ci+1的比例达到20的时候是最优的,这个数字意义不大,但是其中的分析方法对于Merge策略的选择是个启发。
MergeDump的理论基础是LSM-Tree (Log-Structured Merge-Tree), 原文见:LSM Tree
下面先说一下LSM-Tree的基本思想,再记录下读文章的几点感受。
LSM思想非常朴素,就是将对数据的更改hold在内存中,达到指定的threadhold后将该批更改批量写入到磁盘,在批量写入的过程中跟已经存在的数据做rolling merge。
拿update举个例子:
比如有1000万行数据,现在希望update table.a set addr='new addr' where pk = '833',
如果使用B-Tree类似的结构操作,就需要:
1. 找到该条记录所在的page,
2. load page到内存(如果恰好该page已经在内存中,则省略该步)
3. 如果该page之前被修改过,则先flush page to disk
4. 修改数据
转自http://www.cnblogs.com/raymondshiquan/archive/2011/06/04/2072630.html
上面的动作平均来说有两次disk I/O,
如果采用LSM-Tree类似结构,则:
1. 将需要修改的数据直接写入内存
可见这里是没有disk I/O的。
当然,我们要说,这样的话读的时候就费劲了,需要merge disk上的数据和memory中的修改数据,这显然降低了读的性能。
确实如此,所以作者其中有个假设,就是写入远大于读取的时候,LSM是个很好的选择。我觉得更准确的描述应该是”优化了写,没有显著降低读“,因为大部分时候我们都是要求读最新的数据,而最新的数据很可能还在内存里面,即使不在内存里面,只要不是那些更新特别频繁的数据,其I/O次数也是有限的。
所以LSM-Tree比较适合的应用场景是:insert数据量大,读数据量和update数据量不高且读一般针对最新数据。
文章读下来有以下几点感受:
1. 基本思想早就有了,作者给出了较好的表现形式。
2. Merge是page/block级别的,而不是BigTable中的文件级别的。这一点主要原因可能是BigTable在分布式场景下做block级别很困那,而且GFS也不支持修改。
3. 其提出的比较标准比较有趣,将磁盘容量,转速等结合起来给出一个以美元为单位的cost标准,然后跟B-Tree结构的实现做了比较,结果当然是大大胜出。但是这里我觉得作者有些比较是不合理的,比如LSM使用log而B-Tree没有使用,这显然对B-Tree不公,其实B-Tree如果使用log,写入性能应该不比LSM差,顺序读取可能差一些。
4. 在Multi components 中,提出Ci/Ci+1的比例达到20的时候是最优的,这个数字意义不大,但是其中的分析方法对于Merge策略的选择是个启发。
相关文章推荐
- LSM-Tree--BigTable 的理论模型
- LSM-Tree (BigTable 的理论模型)
- [转]LSM-Tree (BigTable 的理论模型)
- LSM-Tree (BigTable 的理论模型)
- LSM-Tree (BigTable 的理论模型)
- LSM-Tree (BigTable 的理论模型)
- LSM-Tree (BigTable 的理论模型)
- LSM-Tree (BigTable 的理论模型)(转)
- 图形学理论 光照模型
- [转]从LSM-Tree、COLA-Tree谈到StackOverflow、OSQA
- 计算学习理论PAC模型
- R语言︱线性混合模型理论与案例探究(固定效应&随机效应)
- 使用 Jackson 树模型(tree model) API 处理 JSON
- Java 理论与实践: 修复 Java 内存模型,第 1 部分
- YunTable开发日记(6)- BigTable的分布式模型(转载)
- Opengl 浏览3ds模型,室外OCtree 和碰撞检测
- Microservice 微服务的理论模型和现实路径
- OSI七层网络模型(理论整理)
- NoSql中的B-tree、B+tree和LSM-tree 分类: B7_HBASE 2015-03-15 18:27 85人阅读 评论(0) 收藏
- 关于项目分析的理论模型