标签：
Laxcus最早源于一个失败的搜索引擎项目，项目最后虽然终止了，但是项目中的部分技术，包括FIXP协议、Diffuse/Converge算法、以及很多新的数据处理理念却得以保留下来，这些成为后来研发Laxcus的基础。此后又经历过一些海量数据处理项目，因为时代和行业的变化，用关系数据库做底层存取已经越来越无法满足不断扩张的业务需要，于是希望改用能够支持海量数据处理的软件，然后在其之上结合实际应用做进一步整合。项目完成后，在推广和使用中遇到了很多阻碍。这里面除了产品本身的一些问题外，更多的困难来自于用户本身，当用户已经熟悉了关系数据库，习惯了SQL的数据表达方式，再让他们去适应一种新的数据产品和新的处理方式，其实是很难的一件事情。同时，用户普遍的想法是少花钱多办事，希望在即有硬件基础设施不变、不增加或者少增加成本的情况下，得到更多更强的数据处理能力。这些情况都最终促成了开发Laxcus的动因，被纳入了开始的设计中。在随后的开发过程中，又逐步融入了一批新的技术和设计理念，比如多个域集群并行、负载自适应、混合数据存储、分布描述语言、分布任务组件、事务管理、各种容错处理、安全管理。在过去几年里，陆续推出了几个版本，并且一步步发展而来，成为今天这样一个比较完整和通用的大数据管理系统。
Laxcus针对的是目前普遍存在的大规模数据处理，且着眼于未来的超大规模数据处理环境。为了实现易用性，设计中很重要的一项要求就是简约化的数据操作处理。这包括了更低成本的硬件、快速的布署、容易的维护、简单的开发和操作。使用户能够以轻松的心情完成大数据处理，在使用体现上，感觉更接近于数据库，而不是什么新的数据产品。以此减少学习压力，提高使用效率。另外，还有非常重要的一项要素是，现实世界的事物之间是存在“关系”的，数据的本质就是这种“事物”和“关系”的关联反映，从“关系”的角度去理解、组织、处理数据，更符合人的思维习惯和定势。
因此，与当下很多大数据产品不一样的是，Laxcus一开始就着力于实现下一代的大规模数据处理，要求在一个产品里做到大数据功能的全体系集成，提供超大规模的存储和计算能力，轻量化的管理和易操作性，所有这些都促使其本身有着很多属于自己的特点。
比如，Laxcus使用实时映像系统来管理元信息，进行元信息的动态实时映像，来实现集群节点间的数据交互。元信息在系统运行中产生，在网络之间传递，在内存里驻留，不会写入磁盘，被不定时地被刷新，总是保证处于最新状态。且因为它的数据量小，在运行过程中不会对运行环境构成什么影响，因此能够做到实时的数据追踪和数据处理。
Diffuse/Converge网络计算算法在Laxcus体系中占有很重要的位置，这是实现分布环境下的大规模并行计算的关键。目前已经实现了抽象和模块化处理，用户只需要调用API接口，就可以很容易地得到分布的、大型数据的处理能力。在减轻了开发者工作的同时，也减少了运行中出错的机率。除非对算法运行机理本身有兴趣，可以直接去看源代码。
分布计算过程中的数据量平均分配的问题也得到妥善解决，数据量平均分配后，体现出的效果就是处理时间的基本一致性。让每一个用户快速脱离计算环境，将计算资源留给后续业务，这对保证集群高效处理来说十分关键。另外，数据传输采用“拉（pull）”，而不是“推（push）”的处理方式，是保证数据平衡很重要的一条准则。
目前在Diffuse/Converge算法接口的基础上，已经提供了多种分布计算工作，其中包括嵌套检索(SUB SELECT)和连接(JOIN)服务。
在Laxcus体系中，索引的概念保留下来，被赋予新的含义。其中一部分融入到元数据中，实现了集群环境下的快速的数据定位，另一部分运用在数据存储模型中。
基于对“关系”的这项重要指标的考量，Laxcus同时采纳了行/列两种存储模型。行存储基本是延续了关系数据库的即有方案。列存储则进行了大的改进，实际上取消了索引这个在数据检索时的中间环节，达到了减少了数据存量和提高检索效率的目的。在数据计算时，行/列存储按照指令要求在存储层面进行多种逻辑关系的复合检索处理，数据能够以列为单位自由分割组合，最大限度减少输出时的冗余数据。还有，Laxcus通过以多集群的协同并行工作方式来提高存储计算数量、数据格式全部采用二进制提高计算效率、延续了数据库的组织体系结构、实时的全网数据处理，这些在实际应用中都是非常重要的。
标签：
原文地址：http://blog.csdn.net/laxcus/article/details/51225817
