Hadoop和Lexst的存储策略

Hadoop依靠HBase实现存储,HBase采用列存储方案(典型NoSQL),加上LSM(Log Structured Merge-Tree)对数据紧缩,使得数据存储效率不错,很适合大数据环境下的读操作,但是如果做删除数据,由于列存储和LSM固有的特点,这时的处理效率不高。

Hadoop和Lexst的存储策略

图1 HBase列存储,NoSQL环境的主流存储方案,高效读是最大优点。

Lexst主要面向商业领域的大数据存储,这一点与面向互联网行业存储有所不同,除了保证要保证大量的高效的读操作,还要兼顾大量的写处理(包括插入、删除、更新,完全标准SQL操作),以及数据的完整性、可靠性、安全性,所以在存储方案选择上采用了行存储。行存储特点是写入效率高,更新和删除容易实现,并且能够有效保证数据的完整性和一致性,但是读效率不如列存储。为了解决这个问题,lexst通过以下方案加以改进:

1. 数据聚凑和有序的行排列布局

2. 可调的存储结构

3. 数据平衡

4. Build节点优化

1.先谈谈有序排列的问题。大数据读取时,很少有关系数据库读取单条记录的现象,普遍情况都是每次读取一批同质的数据。利用这种情况,在写入数据时,把相同或者相邻的数据按照某种排列顺序聚凑在一起时,在读取时,就可以做到一次性顺序读完。避免磁头在磁盘上的多次移动(机械硬盘的磁头移动非常费时间),这样就会显著提高数据读效率。但是每个用户对数据排列规则可能又是不一样的。比如一行数据默认的排列位置是“1,2,3”。在A用户处可能希望的排列顺序是“1,3,2”,到了B用户处,可能又是“2,3,1”。对于这种情况,lexst使用“create layout”语句,允许用户在运行时自由选择自己的数据排列方案。顺带说一句,“create layout”需要在建表时确立,否则将以默认位置进行排列。

2.再说存储结构,lexst的存储结构保证数据可以极快的速度在内存中进行调整。比如,数据在磁盘上的存储排列顺序是“1,2,3”,但是当用户需要以“3,1,2”显示时,就要进行调整;或者用户只需要“3,1”排列,这时必须删除冗余的“2”,也是需要改变。由于编码上充分利用了X86 CPU上的SSE指令集,这个调整效率非常高,在Pentium4 2G单核芯片上的测试结果超过1,300,000行/秒。这是对读过程的又一次改进。

3.还有数据平衡的问题。lexst是一个分布式的网络存储系统,数据的存储量极大,如果把同质数据放在一个存储节点上,那么这个单点上的数据压力就会很大,严重的会造成磁盘损坏或者节点宕机。为避免这种现象的发生,采用了平衡数据的办法,每个存储节点布置了其中一部分数据,做到每个节点不超载。当数据存储和计算时,通过数据分布算法和各节点之间协同,共同完成处理任务。

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:http://www.heiqu.com/fc90d3b326f9cdfedc0c55ee79cb978c.html