前段时间，在俄罗斯和乌克兰的冲突中，甲骨文宣布“暂停在俄罗斯的所有业务”。我相信大家的心情绝不是隔岸观火，而是提心吊胆地去想。
数据库被称为IT领域的三大核心之一(另外两个是CPU和操作系统)。一直是国际巨头垄断，人家控制核心。想什么时候锁喉就什么时候锁喉，没办法。
现在解决这个问题的唯一办法就是自强不息，把数据库的核心技术掌握在自己手中，做出自己的国产数据库。其实这个事情在中国已经讨论了几十年了。早在上世纪80年代，以科研院所和高校为主的国家队就开始投入国产数据库的研发，并在90年代推出了几款数据库产品。但可惜的是，这些产品的研发从一开始就缺乏产业准入，不是因为实际需求的刺激，纯粹是为了所有权。这样，产品在商业市场的拓展也相对较弱。作为追求者，我从未见过对手的背影。
知乎上有个问题：“中国跨过数据库这座大山了吗？”现在有没有完全自主研发的国产数据库？答案有100多个，大部分都没有直接面对这个问题。我们真的无法直接面对，因为我们还不能说我们已经爬上了这座山。
国内数据库现状
近年来，国内数百个数据库如雨后春笋般涌现，但有几个拥有原创技术？
其实不多！你甚至可以毫不客气地说：几乎没有！
这几百个国内数据库，大部分都是基于开源数据库，90%以上都是。其中大部分(约90%)基于MySQL或PostgreSQL。
MySQL作为最著名的开源数据库，由于用户众多，兼容性强，接口丰富，被国内很多数据库厂商用来改造成自己的产品。毕竟很多人熟悉，改造成本更低。
但是相比MySQL，基于PostgreSQL(俗称PG)的包更多。这是因为PG的BSD开源许可非常宽松，允许你在关闭之前修改源代码，甚至没有版权通知。因此，PG成为了众多国产数据库厂商的最爱，他们基于PG包装了自己的“原创”国产数据库，其中不乏一些以创新著称的著名厂商。正所谓“外国一开源，我们就原创。”有些厂商懒得改造(或者可能改造不了)，连驱动都可以直接借用。
除了MySQL和PG，还有一些基于其他开源数据库的包，但是数量很少。国内有些数据库看似原创，其实是基于一个退出江湖的老开源数据库。现在很难看到，他们被误认为是原来的。
除了使用开源库打包，国内还有一些数据库厂商通过购买源代码来实现“自治”。例如，2015年，几家中国公司购买了Informix源代码来开发自己的数据库。
这些“借用他人”的非原创数据库厂商，大多没有掌握核心技术。毕竟消化几千万行代码不是一件容易的事情。虽然有源代码在手，但是仍然很难进行深入的改造，未来的升级和发展也会引起人们的关注有时甚至会出现协议和法律问题。比如MySQL现在归甲骨文了，天知道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已经实现了很多次，但都没有遗漏，平均速度提高了一个数量级以上，而代码量却减少了好几倍。
这里还有一份性能测试报告：《全国产计算数据库性能测试报告》(http://c . raq soft . com . cn/article/1564972044122)。SPL在国产芯片上实现的运算可以超越运行在英特尔芯片上的甲骨文。这是SPL理论创新的结果(离散数据集)。
为什么SPL更强大？
看到SPL的应用效果后，我们不禁要问，SPL到底有什么样的魔力，竟然能达到这些惊人的效果？SPL背后的理论基础是什么？什么是离散数据集模型？
SPL的优势主要集中在两点：数据计算的代码短(写得简单)，性能更高(运行速度快)。SPL改变了计算机的速度吗？不，软件改变不了硬件的性能。SPL更强的原因是设计了很多别人没有的算法(和存储机制)。基于这些算法，计算机可以进行更少的运算，从而达到高性能，而这些算法大多依靠离散数据集的理论就可以很好的实现。
以下是SPL的一些算法，很多都是SPL的原创发明，在业界率先提出，可以窥一斑而知全豹。
和常见的TopN运算一样，TopN在SPL被理解为聚合运算，可以将高复杂度的排序转化为低复杂度的聚合运算，还可以扩大应用范围。
A
1=文件("data.ctx")。打开()。光标()
2=a1 . groups(；Top(10，amount))前10个订单。
3=A1 .组(面积；Top(10，amount))每个地区的前10个订单。
与SQL不同的是，SPL完成这个操作的语句中没有排序字，所以不会有大的排序动作。成套或分组计算TopN的语法基本相同，不仅编写更简单，而且性能更高。而SQL只能写带sort这个词的语句，是否能快速运行取决于数据库的优化引擎。数据库可以应对简单的情况，但即使是Oracle这样的高级数据库，遇到复杂的情况也会“晕倒”。下面是详细的测试案例：性能优化技巧：TopN。
我们已将SPL的离散数据集理论编译成一篇论文(SPL论文http://c . raq soft . com . cn/article/1653097658478)，其中严格定义了离散数据集代数系统，并描述了它与关系代数的区别。
高性能不是靠代码，而是靠代数。代码只是实现的手段。关键是SPL背后的理论体系中提供的数据类型、算法和存储模型。
这篇文章是用简单快速的数据库语言SPL写的，用更通俗的术语解释了SPL的高效原理。关系代数和SQL就像小学的算术，只有加减乘除，而离散数据集和SPL相当于中学时增加了幂平方指数的对数。加减乘除可以应付日常购物，但要造一个飞机楼，必须用更多的数学。
知道了这一点，在上面提到的国产芯片上看到英特尔芯片上运行超越甲骨文的性能也就不足为奇了。即使国产芯片还有很长的路要走，但基于SPL建设完全独立高效的国产数据库，让国产芯片也能插上翅膀腾飞，是可以成为现实的。
SPL的未来
当然，SPL本身还有很长的路要走。目前已发布的函数仅针对OLAP(数据分析)场景，主要解决数据计算问题。我们知道，除了计算，数据库中还有事务，这通常被称为OLTP能力。在面向事务的场景下，SPL仍然会通过创新来解决当前数据库面临的各种问题。
或者创新
现在数据库上云是大势所趋，但是简单的把关系数据库从本地搬到云上并不能体现云应用的特点。云应用的基本特征在于数据结构的多样性。云数据库要同时为多个用户提供服务，不同用户的数据结构可能不一样，同一用户的数据结构在不同时间会发生变化，所以会积累大量不同结构的数据一起存储和计算。这将面临个性化(数据结构不同)和海量用户的矛盾，这是关系数据库无法解决的问题。
事实上，诞生于50年前的数据库在设计时并没有考虑到这个问题(也不可能想到50年后的需求)，所以在关系代数中几乎没有处理结构多样的数据的能力。如果我们想解决这个问题，我们不能再遵循关系代数系统。
同时关系数据库一致性成本过高，资源消耗严重，导致并发性下降。而高并发是云应用的典型特征，这已经成为一个不可调和的矛盾。造成这个问题的原因在于它的数据组织机制(数据类型)，这还是由其理论上的关系代数决定的。如果想同时兼顾一致性和高并发性，就必须打破关系代数的限制，用不同的方式组织和存储数据。
突破理论局限才能从根本上解决问题，SPL(离散数据集)正是时候！
这个未来并不遥远。SPL面向OLTP的功能已经在实验室打磨了几年，经过一段时间的完善，将会一目了然。届时，完全基于自主原创理论的国产数据库将一飞冲天。
超过
同时，理论创新可能会带来另一种结果，那就是：超越！实现数据库领域对国外产品的超越。
我们明白，作为追赶者，采取技术跟随策略是无望的。目前国内数据库绝大多数还是关系数据库，可以说是技术跟随者。国外巨头做这些事情几十年了，人家积累的钱也多了。我没有三头六臂。我为什么要超越别人？唯一的可能是对手失误了，但作为前十名，我们不能指望前n名对手同时失误。寄希望于某项政策将外国产品拒之门外有点徒劳，在这个开放的时代也不太可能发生。
那就只有创新了！
数据库，一定要比竞争对手做得更好，好很多，这样才有机会超越它，弥补生态的不完善。要做得更好，我们需要颠覆性的技术。面对新技术，我们和对手在同一起跑线上。
关系数据库发明了几十年，早已无法满足现代更复杂的应用和更强大的硬件环境的需求。很多看似简单的问题做起来非常困难，开发和维护成本非常高。它不能充分利用计算机资源，性能低下。
对于那些关系数据库巨头来说，要想向股东交代，就必须保持稳定的收入。他们不能只杀自己，而是处于相对不利的境地。这就给了理论层面可以创新的产品机会，实现超越不是异想天开。
马车再高档，也还是马车。再怎么优化，还是要看马。新生的汽车，当然会有各种不习惯的操作，也会有很多不尽如人意的功能。但它是发动机驱动的，它的巨大优势会全面碾压马车。
让我们拭目以待，让我们奋进！
审核编辑：李倩