有没有完全自主的国产化数据库技术 _国产数据库都是基于什么技术(3)

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，涵盖了95%以上大数据知识点，真正体系化！

由于文件比较多，这里只是将部分目录截图出来，全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频，并且后续会持续更新

需要这份系统化资料的朋友，可以戳这里获取

由于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。

我们已经将SPL的离散数据集理论整理成论文（ SPL论文），其中严格地定义了离散数据集代数体系，并描述了它与关系代数的不同。

高性能靠的不是代码，而是代数，代码只是个实现手段而已，关键是SPL背后的理论体系中提供的数据类型和算法以及存储模型。

这篇文章 写着简单跑得又快的数据库语言 SPL 中用更通俗的说法解释了SPL的高效原理。关系代数和SQL就像小学时代的算术，只有加减乘除，而离散数据集和SPL则相当于增加了中学的乘方开方指数对数。加减乘除可以应对日常购物买菜，但要造出飞机大楼就必须用到更多的数学了。

了解了这些，再看前文提到的在国产芯片上跑出超越Oracle在Intel芯片上的性能也就不神奇了。即使国产芯片还有很长的路要走，基于SPL打造完全自主、高效的国产数据库也能成为现实，让国产芯片也能插上翅膀腾飞起来。

SPL的未来

当然，SPL本身也还有很长的路要走，目前已发布的功能还只面向OLAP（数据分析）场景，主要解决数据计算难题。我们知道，数据库除了计算还有交易，就是常说的OLTP能力。在面向交易的场景，SPL仍然会通过创新解决当前数据库面临的各类问题。

还是创新

现在数据库上云已经是大势所趋，但是简单地把关系数据库从本地搬到云上并不能体现出云应用的特征。云应用的基本特征在于数据结构的多样性。云数据库要同时为多个用户提供服务，而不同用户的数据结构可能不同，同一个用户在不同时段的数据结构也会变，这样就会积累大量不同结构的数据要一起存储和计算。这就会面临个性化（不同数据结构）和海量用户的矛盾，这是关系数据库无法解决的问题。

事实上，50年前诞生的数据库在设计时并没有考虑过这个问题（也不可能想到50年后的需求），因此关系代数中几乎没有设计针对多样性结构数据的处理能力。想要解决这个问题就不能再沿用关系代数体系。

同时，关系数据库在实现一致性时成本过高，资源消耗严重，导致并发能力下降。而高并发又是云应用的典型特性，这又成了一对不可调和的矛盾。这个问题的原因在于它的数据组织机制（数据类型），这仍然是由其理论关系代数决定的。想要同时兼顾一致性和高并发就还要打破关系代数的限制，换一种方式组织和存储数据。

突破理论限制才能从根本上解决问题，SPL（离散数据集）正当时！

这个未来也并不遥远，SPL面向OLTP的功能已经在实验室中打磨了几年，再完善一段时间就可以亮剑出窍，届时完全基于自主原创理论的国产数据库将划破天际。

超越

同时，理论上的创新还可能带来另外一个结果，那就是：超越！在数据库领域实现对国外产品的超越。

我们明白，作为追赶者，采用技术跟随战略是没希望的。目前的国产数据库绝大多数仍然是关系数据库，可以说都是技术跟随者。而国外巨头们做这些事已经好几十年，人强钱多积累厚，我又没有三头六臂，凭什么超越人家呢？唯一的可能就是对手犯错，但是作为十名开外的我们不能指望前面N名对手同时犯错吧。而寄希望于某种政策把国外产品拒之门外，也有点没出息不是，而且在这开放的年代也不太可能出现这种情况。

那么就唯有创新！

数据库，我们必须比对手做得更好，还要好很多，这样才有机会超越，才能弥补生态的不完善。而要做得更好，就需要有颠覆性的技术，在新技术面前我们和对手是站在同一起跑线上的。

关系数据库已经发明了几十年，早就不适应现代更复杂的应用需求和更强大的硬件环境，很多看似简单的问题非常难做，开发维护成本很高，也不能充分利用计算机资源，眼睁睁地忍受低性能。

对于那些关系数据库巨头来讲，要向股东交代，就要保持稳定的收益，它还不能随便革掉自己的命，结果反而处于相对不利的局面。这就给了能在理论层面创新的产品机会，实现超越并非异想天开。

马车再高档也还是马车，无论如何优化都还是要靠马拉动。初生的汽车，操作上当然会有各种不习惯，功能上也会有众多不如意。但它是发动机驱动的，假以时日不断完善，它的巨大优势必将全面碾压马车。

让我们拭目以待，也让我们砥砺前行！

SPL资料

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化资料的朋友，可以戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！

bbs.csdn.net/forums/4f45ff00ff254613a03fab5e56a57acb)**

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！