数据蒋堂 | 存储和计算技术的选择

作者：蒋步星

来源：数据蒋堂

本文共1093字，建议阅读4分钟。
本文为你介绍NoSQL、RDB、集算器三种数据库的储存与计算。

前一阵子公司有个售前来沟通某个用户的情况：数据量比较大，又涉及很多复杂的关联计算，在数据库中用SQL计算性能很差。本来这种场景是比较适合集算器的集文件（集算器特有的压缩二进制格式）存储并计算，但据说这个用户的历史数据还会经常变动，而集文件目前没有提供改写能力（为了保证压缩率和性能），也就不容易直接用。于是想推荐用户采用nosql产品做存储，集算器在上面做计算。

赶快打住！如果用户真的听了，那会恨死我们。

这个场景中有三个要素：数据量大、复杂计算、频繁改动。

为了解释这三者的大致关系，我画了一个不太严谨的图：

NoSQL数据库在存储时不考虑事务一致性，而且许多NoSQL产品对key-value结构（要改的数据肯定要有个key）的数据都会采用LSM树等优化手段，一般情况比RDB常用的B树性能要好，所以对于频繁改的应用，NoSQL的效率会比较高。相反，RDB虽然也能频繁改，但为了事务一致性等因素，效率就会低于NoSQL。

但key-value结构的NoSQL却不擅长大数据计算，除了按key找value比较快以外，涉及到遍历（这是家常便饭）的运算都不灵光，主要是因为value是无确定结构的，每次取出数据要现解析，而且数据结构也会多存很多空间，所以大数据计算效率就会远远低于RDB（所以上述场景一定要打住，绝不可以推荐NoSQL）。

RDB频繁修改后会导致数据在硬盘上的连续性很差，也不容易做好压缩，这样大数据量遍历的性能也不会太好。而RDW在RDB基础上做了运算优化，可以事先整理数据，放弃了复杂的写一致性能力，这样对于大数据计算就会有更好的性能。但反过来，频繁改就不适合了。

RDB和RDW都采用SQL体系运算，对于简单查询计算没太大问题，但过于复杂的关联和过程性运算，由于关系代数的局限性，很多优化算法无法实施（我们已经多次说过这个问题），所以在复杂运算场景下性能不佳（也就会发生上述场景的现象）。

集算器是为了复杂计算而设计，可以实现更优的算法获得更好的性能。但如开始所述，目前的集文件又不支持改写，所以它只适合解决复杂运算，而难以面对频繁改的场景。集算器其实比RDW在大数据计算性能方面更好，不过作为计算引擎并不太关注存储，而大数据需求中还是会比较在意的可维护管理能力就要弱了。

集算器进一步发展出来的仓库版将支持少量修改的存储方案，这样可以在保证复杂运算能力的基础上再提供数据维护能力，可以逐步替代数据仓库，不过也不合适频繁修改。而另一个方向的云库版则更注重结构多样性，同时也支持事务一致性，能适应频繁改，而且有集算器提供复杂计算能力，但同前面分析NoSQL的理由，这时候它又不适合大数据遍历了。

那么这三样都想要怎么办呢？难道就只能见鬼去？

其实也有办法，只要肯多花钱买大内存（还可能要集群）把数据全装进去，这三样就能并存了。毕竟，有钱能使鬼推磨嘛，呵呵！

专栏作者简介

润乾软件创始人、首席科学家

清华大学计算机硕士，著有《非线性报表模型原理》等，1989年，中国首个国际奥林匹克数学竞赛团体冠军成员，个人金牌；2000年，创立润乾公司；2004年，首次在润乾报表中提出非线性报表模型，完美解决了中国式复杂报表制表难题，目前该模型已经成为报表行业的标准；2014年，经过7年开发，润乾软件发布不依赖关系代数模型的计算引擎——集算器，有效地提高了复杂结构化大数据计算的开发和运算效率；2015年，润乾软件被福布斯中文网站评为“2015福布斯中国非上市潜力企业100强”；2016年，荣获中国电子信息产业发展研究院评选的“2016年中国软件和信息服务业十大领军人物”；2017年, 自主创新研发新一代的数据仓库、云数据库等产品即将面世。

数据蒋堂

《数据蒋堂》的作者蒋步星，从事信息系统建设和数据处理长达20多年的时间。他丰富的工程经验与深厚的理论功底相互融合、创新思想与传统观念的相互碰撞，虚拟与现实的相互交织，产生出了一篇篇的沥血之作。此连载的内容涉及从数据呈现、采集到加工计算再到存储以及挖掘等各个方面。大可观数据世界之远景、小可看技术疑难之细节。针对数据领域一些技术难点，站在研发人员的角度从浅入深，进行全方位、360度无死角深度剖析；对于一些业内观点，站在技术人员角度阐述自己的思考和理解。蒋步星还会对大数据的发展，站在业内专家角度给予预测和推断。静下心来认真研读你会发现，《数据蒋堂》的文章，有的会让用户避免重复前人走过的弯路，有的会让攻城狮面对扎心的难题茅塞顿开，有的会为初入行业的读者提供一把开启数据世界的钥匙，有的甚至会让业内专家大跌眼镜，产生思想交锋。

往期回顾：

数据蒋堂 | JOIN延伸 - 维度概念

数据蒋堂 | JOIN提速 - 有序归并

数据蒋堂 | JOIN提速 - 外键指针的衍生

数据蒋堂 | JOIN提速 - 外键指针化

数据蒋堂 | JOIN简化 - 意义总结

数据蒋堂 | JOIN简化-消除关联

数据蒋堂 | JOIN简化 - 维度对齐

数据蒋堂 | JOIN运算剖析

数据蒋堂 | 迭代聚合语法

数据蒋堂 | 非常规聚合

数据蒋堂 | 再谈有序分组

数据蒋堂 | 有序分组

数据蒋堂 | 非等值分组

数据蒋堂 | 还原分组运算的本意

数据蒋堂 | 有序遍历语法

数据蒋堂 | 常规遍历语法

数据蒋堂 | 从SQL语法看离散性

数据蒋堂 | 从SQL语法看集合化

数据蒋堂 | SQL用作大数据计算语法好吗？

数据蒋堂 | SQL的困难源于关系代数

数据蒋堂 | SQL像英语是个善意的错误

数据蒋堂 | 开放的计算能力为数据库瘦身

数据蒋堂 | 计算封闭性导致臃肿的数据库

数据蒋堂 | 怎样看待存储过程的移植困难

数据蒋堂 | 存储过程的利之弊

数据蒋堂 | 不要对自助BI期望过高

数据蒋堂 | 报表的数据计算层

数据蒋堂 | 报表应用的三层结构

数据蒋堂 | 列式存储的另一面

数据蒋堂 | 硬盘的性能特征

数据蒋堂 | 我们需要怎样的OLAP？

数据蒋堂 | 1T数据到底有多大？

数据蒋堂 | 索引的本质是排序

数据蒋堂 | 功夫都在报表外--漫谈报表性能优化

数据蒋堂 | 非结构化数据分析是忽悠？

数据蒋堂 | 多维分析的后台性能优化手段

数据蒋堂 | JOIN延伸 - 维度查询语法

数据蒋堂 | 文件的性能分析

数据蒋堂 | RDB与NoSQL的访问性能

数据蒋堂 | 报表开发的现状

数据蒋堂 | Hadoop - 一把杀鸡用的牛刀

数据蒋堂 | Hadoop中理论与工程的错位

校对：陈瑞清

为保证发文质量、树立口碑，数据派现设立“错别字基金”，鼓励读者积极纠错。

若您在阅读文章过程中发现任何错误，请在文末留言，或到后台反馈，经小编确认后，数据派将向检举读者发8.8元红包。

同一位读者指出同一篇文章多处错误，奖金不变。不同读者指出同一处错误，奖励第一位读者。

感谢一直以来您的关注和支持，希望您能够监督数据派产出更加高质的内容。