Hadoop和Lexst的存储策略-CSDN博客

本文链接：https://blog.csdn.net/atskytop/article/details/7773866

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

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

4.最后是存储优化。lexst的集群中，有一类节点专门负责数据优化工作，这就是Build节点。优化主要针对两种情况：

(1) 系统长时间运行，更新、删除操作频繁（删除操作只对数据做删除标记，并不从磁盘中移除），造成过期/冗余数据堆积，需要清除时。

(2) 将一种数据格式转化为另一种数据格式存储，为读操作提供更高的性能比。

提供数据优化的是marshal/educe算法，Build节点为用户提供了这个算法接口，可以热发布到Build节点上运行。关于算法的详细介绍和使用可见《Lexst：大规模数据处理系统》一文。