前段时间的俄乌抵触，Oracle 发表“暂停在俄罗斯的所有业务”，置信大家的情绪绝不是隔岸观火，而是细思恐极。
数据库号称 IT 畛域三大外围之一（其余两个是 CPU 和操作系统），始终以来都被国内巨头垄断，人家管制着外围，想什么时候锁喉就什么时候锁，你一点方法都没有。
当初解决这个问题的方法只能是自强，将数据库核心技术把握在本人手里，做属于本人的国产数据库。其实，这个事我国也曾经张罗了几十年，早在上世纪 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 将报表计算工夫从 3700 秒缩短到 105 秒，晋升了 35 倍 多……
相似的案例 SPL 施行过不少，还没有失手过，均匀提速超过一个数量级，同时代码量升高数倍。
这里还有一份性能测试报告：《全国产计算数据库性能测试报告》（http://c.raqsoft.com.cn/artic…）。用 SPL 在国产芯片上实现的运算，能超过在 Intel 芯片上跑的 Oracle。这都是 SPL 实践翻新（离散数据集）带来的成果。
SPL 为什么更强
咱们看到 SPL 的利用成果后不禁要问，SPL 到底有何种魔法竟然能达到这些惊为天人的成果？SPL 背地的实践根底离散数据集模型到底是什么样的？
SPL 的劣势次要集中在两点，实现数据计算的 代码简短（写得简略），而且 性能更高（跑得快）。那是 SPL 扭转了计算机的速度了吗？并没有，软件不可能扭转硬件的性能。SPL 更强的起因是因为设计了很多他人没有的算法（和存储机制），基于这些算法能够让计算机少执行一些运算，从而取得高性能，而这些算法大都要依附离散数据集实践能力很好实现。
上面是 SPL 的局部算法，很多都是 SPL 的独创创造，在业内首次提出，窥一斑而知全豹。
像常见的 TopN 运算，在 SPL 中 TopN 被了解为聚合运算，这样能够将高复杂度的排序转换成低复杂度的聚合运算，而且很还能扩大利用范畴。
和 SQL 不同，SPL 实现这个运算的语句中没有排序字样，也就不会产生大排序的动作，在选集还是分组中计算 TopN 的语法基本一致，不仅写法上更简略，性能也更高。而 SQL 只能写出有排序字样的语句，是不是能跑得快就只能指望数据库的优化引擎了，简略状况时数据库还能凑合，但状况简单时连 Oracle 这样的资深数据库都会“晕掉”，这里有相干的具体测试案例：性能优化技巧：TopN。
咱们曾经将 SPL 的离散数据集实践整顿成论文（SPL 论文 http://c.raqsoft.com.cn/artic…），其中严格地定义了离散数据集代数体系，并形容了它与关系代数的不同。
高性能靠的不是代码，而是代数，代码只是个实现伎俩而已，要害是 SPL 背地的理论体系中提供的数据类型和算法以及存储模型。
这篇文章 写着简略跑得又快的数据库语言 SPL 中用更艰深的说法解释了 SPL 的高效原理。关系代数和 SQL 就像小学时代的算术，只有加减乘除，而离散数据集和 SPL 则相当于减少了中学的乘方开方指数对数。加减乘除能够应答日常购物买菜，但要造出飞机大楼就必须用到更多的数学了。
理解了这些，再看前文提到的在国产芯片上跑出超过 Oracle 在 Intel 芯片上的性能也就不神奇了。即便国产芯片还有很长的路要走，基于 SPL 打造齐全自主、高效的国产数据库也能成为事实，让国产芯片也能插上翅膀腾飞起来。
SPL 的将来
当然，SPL 自身也还有很长的路要走，目前已公布的性能还只面向 OLAP（数据分析）场景，次要解决数据计算难题。咱们晓得，数据库除了计算还有交易，就是常说的 OLTP 能力。在面向交易的场景，SPL 依然会通过翻新解决以后数据库面临的各类问题。
还是翻新
当初数据库上云曾经是大势所趋，然而简略地把关系数据库从本地搬到云上并不能体现出云利用的特色。云利用的基本特征在于 数据结构的多样性。云数据库要同时为多个用户提供服务，而不同用户的数据结构可能不同，同一个用户在不同时段的数据结构也会变，这样就会积攒大量不同构造的数据要一起存储和计算。这就会面临个性化（不同数据结构）和海量用户的矛盾，这是关系数据库无奈解决的问题。
事实上，50 年前诞生的数据库在设计时并没有思考过这个问题（也不可能想到 50 年后的需要），因而关系代数中简直没有设计针对多样性构造数据的解决能力。想要解决这个问题就不能再沿用关系代数体系。
同时，关系数据库在实现一致性时老本过高，资源耗费重大，导致并发能力降落。而高并发又是云利用的典型个性，这又成了一对不可和谐的矛盾。这个问题的起因在于它的数据组织机制（数据类型），这依然是由其实践关系代数决定的。想要同时兼顾一致性和高并发就还要突破关系代数的限度，换一种形式组织和存储数据。
冲破实践限度能力从根本上解决问题，SPL（离散数据集）正过后！
这个将来也并不边远，SPL 面向 OLTP 的性能曾经在实验室中打磨了几年，再欠缺一段时间就能够亮剑出窍，届时齐全基于自主原创实践的国产数据库将划破天际。
超过
同时，实践上的翻新还可能带来另外一个后果，那就是：超过！在数据库畛域实现对国外产品的超过。
咱们明确，作为追赶者，采纳技术追随策略是没心愿的。目前的国产数据库绝大多数依然是关系数据库，能够说都是技术跟随者。而国外巨头们做这些事曾经好几十年，人强钱多积攒厚，我又没有三头六臂，凭什么超过人家呢？惟一的可能就是对手犯错，然而作为十名开外的咱们不能指望后面 N 名对手同时犯错吧。而寄希望于某种政策把国外产品拒之门外，也有点没出息不是，而且在这凋谢的年代也不太可能呈现这种状况。
那么就唯有翻新！
数据库，咱们必须比对手做得更好，还要好很多，这样才有机会超过，能力补救生态的不欠缺。而要做得更好，就须要有颠覆性的技术，在新技术背后咱们和对手是站在同一起跑线上的。
关系数据库曾经创造了几十年，早就不适应古代更简单的利用需要和更弱小的硬件环境，很多看似简略的问题十分难做，开发保护老本很高，也不能充沛利用计算机资源，眼睁睁地忍耐低性能。
对于那些关系数据库巨头来讲，要向股东交代，就要保持稳定的收益，它还不能轻易革掉本人的命，后果反而处于绝对不利的场面。这就给了能在实践层面翻新的产品机会，实现超过并非胡思乱想。
马车再低档也还是马车，无论如何优化都还是要靠马拉动。初生的汽车，操作上当然会有各种不习惯，性能上也会有泛滥不如意。但它是发动机驱动的，假以时日不断完善，它的微小劣势必将全面碾压马车。
让咱们刮目相待，也让咱们砥砺前行！