Hadoop依靠HBase实现存储，HBase采用列存储方案，加上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:大规模数据处理系统》一文。
 

    图2 Lexst行存储布局

    Lexst行存储权衡了读和写的效率，并对行存储做了多种优化。在保证数据完整性和一致性基础上，通过CRC32校验和压缩、加密等方法，进一步加强了数据的安全性和可靠性。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。