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