网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
现在解决这个问题的办法只能是自强，将数据库核心技术掌握在自己手里，做属于自己的国产数据库。其实，这个事我国也已经张罗了几十年，早在上世纪80年代以研究所和大学为主的国家队就开始投入研发国产数据库，并在90年代相继推出了几款数据库产品。不过可惜的是这些产品研发从一开始就缺乏产业端的接入，并不是因为实际需求的刺激，而纯粹是为了拥有。这样，产品在商业市场的拓展也比较弱。作为追赶者，始终也没有看到对手的背影。
知乎上有个问题：“中国跨过数据库这座大山了吗？” 翻译一下就是：现在有完全自主研发的国产数据库了吗？回答有100多个，看了看不是普及数据库知识的就是推广自家产品的，大多回答并没有直面这个问题。确实也没法直面，因为我们还不能说已经翻过这座大山了。
国产数据库现状
这几年，雨后春笋般地冒出数百个国产数据库，但有多少拥有原创技术呢？
其实没多少！甚至可以粗暴一点说：几乎没有！
这几百个国产数据库中，绝大多数是基于开源数据库改造的，90%都不止。其中又有绝大部分（大概又是90%）是基于MySQL或PostgreSQL改造的。
MySQL作为最著名的开源数据库，由于使用者众多、兼容性强、接口丰富等因素，被很多国产数据库厂商用来改造成自家产品也不足为奇，毕竟熟悉它的人不少，改造成本也低一点。
不过，相对MySQL，基于PostgreSQL（俗称PG）封装的更多。这是由于PG采用BSD开源许可非常宽松，允许修改源码后再闭源，甚至不需要版权声明。因此PG成为众多国产数据库厂商的最爱，纷纷基于PG封装出自己的“原创”国产数据库，包括某些以创新闻名的著名大厂。正所谓“国外一开源，我们就原创”，有的厂家甚至懒得改造（也可能是没能力改造），连驱动程序都能直接借用。
除了MySQL和PG这两大阵营外，也有一些基于其他开源数据库封装的，不过数量很少。有些国产数据库看似原创，但其实是基于某个已经退出江湖的古老开源数据库改造的，现在很难看出来就被误以为原创了。
除了使用开源库封装，还有一些国内数据库厂商通过购买源码实现“自主”。像2015年有几家中国公司购买了Informix源码来发展自己的数据库。
这些“借用别人”的非原创数据库厂商，大多数并没有掌握核心技术，毕竟消化上千万行代码也不是一件容易的事儿。虽然手里有源代码，却仍然很难进行深入的改造，未来升级发展也要仰人鼻息。有些时候甚至还会有协议和法律问题，比如MySQL现在的所有权归Oracle所有，天知道哪天O记不高兴了会不会对我们干些啥。
不过，欣慰的是，还是有少量难能可贵的厂商是从0开始自主实现的。比较有代表性的是OceanBase。因为诞生于互联网企业，面对急速扩张的业务，继续使用国外商用数据库无论在成本上还是容量上都难以支撑，自身就有很有很强的动力摆脱对国外产品的依赖，就必须走出一条自研之路。当然，从头自研一个数据库并非易事，这是个十年才能磨一剑的艰辛事业，肯这样熬的厂商确实是凤毛麟角。
除此之外，我们还有另一个更奇葩的也是十年磨出一剑的，一个看起来不像数据库却能完成大量数据库任务的产品：润乾软件开发的集算器SPL。它不仅在工程实现上完全自主开发，连理论模型都是自己原创的，突破的不仅仅是数据库本身，还有背后的理论框架，这样的产品在国内可以说更是绝无仅有的了。
SPL是啥？和数据库有啥关系？效果咋样？背后又突破了什么理论？下面我们就来说道说道。
SPL的由来
SPL的开发主体是润乾软件，润乾报表你可能听过或用过，是20年前为了解决中国式复杂报表制作创新的一个产品，其中使用了独创的非线性报表模型理论。我们知道，报表是一个强数据计算场景，数据库中的数据距离要呈现出来的数据还很远，需要很多步骤的复杂运算才能得到。而报表工具只能解决呈现环节那一步的少量计算，对于进入报表工具之前的数据计算则无能为力。这导致了虽然有成熟的报表工具来解决格式及呈现环节的计算问题，而报表开发却依然很难的现状。
对于这个问题，业界也没什么好办法，只能是写复杂SQL（以及存储过程）或者在应用程序中用高级语言 （如Java）编程，十分繁琐低效。而且由于SQL和Java的开发特性，还会带来耦合性高、维护困难等问题。
在这样的背景下，我们希望找到一种方式来解决数据计算难、计算慢的问题。我们通过大量总结分析碰到的各种数据计算问题后发现，如果继续沿用SQL的技术体系无论如何也解决不好这个问题，充其量在工程上做些优化（现在大多数数据库在做的），新瓶装旧酒而已。
SQL的理论基础是关系代数，SQL之所以难以应对复杂数据计算，根本原因是背后的关系代数理论。想要根本解决这个问题就不能再基于关系代数。
那怎么办？
既然没有现成的可用，就只能发明新的了，使用新的理论模型解决计算难题！
不过，这事儿说起来轻松，做起来却不容易。从2007年开始，我们用了十多年时间，历经四次大的重构才把模型和结构稳定下来，形成了一套理论模型——离散数据集，基于这套模型开发出了SPL（Structured Process Language），专门用于结构化数据计算的程序设计语言，配合有存储机制后，也可以理解成为数据仓库产品。
由于SPL采用了新的理论模型，在市面上根本没有其他产品可以借鉴，更不可能有现成的开源代码可以“借用”，只能完全自己一行一行开发。所以，SPL的核心运算模型代码从头到脚都是完全自主原创的。连理论基础都是自己发明的，代码更加只能原创，你说够不够自主？
说到这你可能发现，SPL看起来跟传统数据库不太一样，它的实际应用效果如何呢？
SPL应用效果
对于大数据计算类任务来讲，就已应用的效果来看，SPL在实践中的表现非常出色。实现复杂计算时，不仅代码简短，性能相较于传统数据库通常能快一个数量级以上。
国家天文台的某个天体计算场景：11张照片，每张50万天体（目标规模为500万），天文距离（三角函数计算）较近的天体被视为同一个，需要将不同照片中的“相同”天体合并，属性重新聚合。
这个任务的技术本质是个非等值关联，计算量是平方级的（也就是50万*50万=2500亿）。Python代码约200行，单线程计算6.5天，按个速度估算，目标的500万规模需要近2年时间，彻底没有可实用性；国内某大厂的分布式数据库上动用了100个CPU的SQL代码也用了3.8小时，算下来单核计算速度比Python还慢；而SPL实现的优化代码仅50多行，利用任务特点大幅降低了计算量（远不到2500亿），在4核的笔记本上仅用2分多钟就完成了计算，计算500万的目标规模只要数小时就能搞定，完全可以实用。
这个差距的背后：受限于理论模型的SQL，无法实现这种优化技术，只能眼睁睁地看着计算资源消耗；Python硬编码虽然可以实现优化算法，但工作量巨大，代码将远不止200行；只有SPL，代码更短，还跑得更快。
不仅如此，在其他行业，SPL的优势也很明显。
在某保险公司团体保明细单查询场景中，SPL相比Oracle性能提升了2000倍，同时代码量减少了5倍以上……
在某保险公司车险跑批计算优化场景中，使用SPL将RDB跑批时间从2个小时优化到17分钟，而实现代码从原来的2000行缩短到不到500行……
在某银行的客户画像场景中，SPL将用户画像客群交集计算性能提升了200倍以上……
在某金融用户的报表查询场景中，SPL将报表计算时间从3700秒缩短到105秒，提升了35倍多……
……
类似的案例SPL实施过不少，还没有失手过，平均提速超过一个数量级，同时代码量降低数倍。
这里还有一份性能测试报告：《全国产计算数据库性能测试报告》。用 SPL 在国产芯片上实现的运算，能超越在Intel芯片上跑的Oracle。这都是SPL理论创新（离散数据集）带来的效果。
SPL为什么更强
我们看到SPL的应用效果后不禁要问，SPL到底有何种魔法居然能达到这些惊为天人的效果？SPL背后的理论基础离散数据集模型到底是什么样的？
SPL的优势主要集中在两点，实现数据计算的代码简短（写得简单），而且性能更高（跑得快）。那是SPL改变了计算机的速度了吗？并没有，软件不可能改变硬件的性能。SPL更强的原因是因为设计了很多别人没有的算法（和存储机制），基于这些算法可以让计算机少执行一些运算，从而获得高性能，而这些算法大都要依靠离散数据集理论才能很好实现。
下面是SPL的部分算法，很多都是SPL的独创发明，在业内首次提出，窥一斑而知全豹。
像常见的TopN运算，在SPL中TopN被理解为聚合运算，这样可以将高复杂度的排序转换成低复杂度的聚合运算，而且很还能扩展应用范围。
| A | ||
|---|---|---|
| 1 | =file(“data.ctx”).open().cursor() | |
| 2 | =A1.groups(;top(10,amount)) | 金额在前 10 名的订单 |
| 3 | =A1.groups(area;top(10,amount)) | 每个地区金额在前 10 名的订单 |
和SQL不同，SPL完成这个运算的语句中没有排序字样，也就不会产生大排序的动作，在全集还是分组中计算TopN的语法基本一致，不仅写法上更简单，性能也更高。而SQL只能写出有排序字样的语句，是不是能跑得快就只能指望数据库的优化引擎了，简单情况时数据库还能对付，但情况复杂时连Oracle这样的资深数据库都会“晕掉”，这里有相关的详细测试案例： 性能优化技巧：TopN。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
610
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
