比SQL还好用，又一门国产数据库语言诞生了

数据库言语的目标
要说清这个目标，先要了解数据库是做什么的。数据库这个软件，姓名中有个“库”字，会让人觉得它首要是为了存储的。其实不然，数据库完结的重要功用有两条：核算、业务！也便是咱们常说的OLAP和OLTP，数据库的存储都是为这两件事服务的，单纯的存储并不是数据库的目标。咱们知道，SQL是现在数据库的干流言语。那么，用SQL做这两件事是不是很便利呢？业务类功用首要处理数据在写入和读出时要保持的一致性，完结这件事的难度并不小，但对于使用程序的接口却十分简略，用于操作数据库读写的代码也很简略。假如假定现在联系数据库的逻辑存储模式是合理的（也便是用数据表和记载来存储数据，其合理性与否是另一个杂乱问题，不在这儿展开了），那么SQL在描绘业务类功用时没什么大问题，由于并不需求描绘多杂乱的动作，杂乱性都在数据库内部处理了。但核算类功用却不相同了。这儿说的核算是个更广泛的概念，并不只仅简略的加加减减，查找、相关都能够看成是某种核算。什么样的核算系统才算好呢？仍是两条：写着简略、跑得快。写着简略，很好了解，便是让程序员很快能写出来代码来，这样单位时间内能够完结更多的作业；跑得快就更简略了解，咱们当然希望更短时间内获得核算成果。其实SQL中的Q便是查询的意思，创造它的初衷首要是为了做查询（也便是核算），这才是SQL的首要目标。然而，SQL在描绘核算使命时，却很难说是很担任的。
SQL为什么不行
先看写着简略的问题。SQL写出来很象英语，有些查询能够当英语来读和写（网上多得很，就不举例了），这应当算是满足写着简略这一条了吧。且慢！咱们在教科书上看到的SQL常常只需两三行，这些SQL确实算是写着简略的，但假如咱们测验一些稍杂乱化的问题呢？这是一个其实还不算很杂乱的例子：核算一支股票最长接连上涨了多少天？用SQL写出来是这样的：
selectmax(consecutive_day)from(selectcount(*)(consecutive_dayfrom(selectsum(rise_mark)over(orderbytrade_date)days_no_gainfrom(selecttrade_date,casewhenclosing_price>lag(closing_price)over(orderbytrade_date)then0else1ENDrise_markfromstock_price))groupbydays_no_gain)
这个句子的作业原理就不解说了，反正有点绕，同学们能够自己测验一下。
这是润乾公司的招聘考题，通过率缺乏20%；由于太难，后来被改成另一种办法：把SQL句子写出来让应聘者解说它在算什么，通过率依然不高。这阐明什么？阐明情况稍有杂乱，SQL就变得即难懂又难写！再看跑得快的问题，仍是一个常常拿出来的简略例子：1亿条数据中取前10名。这个使命用SQL写出来并不杂乱：
SELECTTOP10xFROMTORDERBYxDESC
可是，这个句子对应的履行逻辑是先对所有数据进行大排序，然后再取出前10个，后面的不要了。我们知道，排序是一个很慢的动作，会多次遍历数据，假如数据量大到内存装不下，那还需求外存做缓存，功能还会进一步急剧下降。假如严格按这句SQL表现的逻辑去履行，这个运算不管如何是跑不快的。然而，很多程序员都知道这个运算并不需求大排序，也用不着外存缓存，一次遍历用一点点内存就能够完结，也便是存在更高功能的算法。惋惜的是，用SQL却写不出这样的算法，只能寄希望于数据库的优化器足够聪明，能把这句SQL转换成高功能算法履行，但情况杂乱时数据库的优化器也未必靠谱。
看样子，SQL在这两方面做得都不够好。这两个并不杂乱的问题都是这样，实际中数千行的SQL代码中，这种难写且跑不快的情况举目皆是。为什么SQL不行呢？要回答这个问题，咱们要分析一下用程序代码完结核算到底是在干什么。本质上讲，编写程序的进程，便是把处理问题的思路翻译成核算机可履行的准确化形式言语的进程。举例来说，就象小学生解使用题，分析问题想出解法之后，还要列出四则运算表达式。用程序核算也是相同，不只需想出处理问题的办法，还要把解法翻译成核算机能了解履行的动作才算完结。用于描绘核算办法的形式言语，其间心在于所采用的代数系统。所谓代数系统，简略说便是一些数据类型和其上的运算规则，比方小学学到的算术，便是整数和加减乘除运算。有了这套东西，咱们就能把想做的运算用这个代数系统约定的符号写出来，也便是代码，然后核算机就能够履行了。假如这个代数系统规划时考虑不周到，供给的数据类型和运算不便利，那就会导致描绘算法十分困难。这时候会发生一个怪现象：翻译解法到代码的难度远远超越处理问题本身。举个例子，咱们从小学惯用阿拉伯数字做日常核算，做加减乘除都很便利，所有人都天经地义以为数值运算就该是这样的。其实未必！估计很多人都知道还有一种叫做罗马数字的东西，你知道用罗马数字该怎么做加减乘除吗？古罗马人又是如何上街买菜的？代码难写很大程度是代数的问题。再看跑不快的原因。软件没办法改变硬件的功能，CPU和硬盘该多快便是多快。不过，咱们能够规划出低杂乱度的算法，也便是核算量更小的算法，这样核算机履行的动作变少，天然也就会快了。可是，光想出算法还不够，还要把这个算法用某种形式言语写得出来才行，不然核算机不会履行。并且，写起来还要比较简略，都要写很长很费事，也没有人会去用。所以呢，对于程序来讲，跑得快和写着简略其实是同一个问题，背后仍是这个形式言语采用的代数的问题。假如这个代数不好，就会导致高功能算法很难完结甚至完结不了，也就没办法跑得快了。就象上面说的，用SQL写不出咱们希望的小内存单次遍历算法，能不能跑得快就只能寄希望于优化器。咱们再做个类比：上过小学的同学大概都知道高斯核算1+2+3+…+100的小故事。普通人便是一步步地硬加100次，高斯小朋友很聪明，发现1+100=101、2+99=101、…、50+51=101，成果是50乘101，很快算完回家午饭了。听过这个故事，咱们都会慨叹高斯很聪明，能想到这么奇妙的办法，即简略又敏捷。这没有错，可是，我们简略疏忽一点：在高斯的时代，人类的算术系统（也是一个代数）中现已有了乘法！象前面所说，咱们从小学习四则运算，会觉得乘法是理所当然的，然而并不是！乘法是后于加法被创造出来的。假如高斯的时代还没有乘法，即便有聪明的高斯，也没办法快速处理这个问题。现在干流数据库是联系数据库，之所以这么叫，是由于它的数学根底被称为联系代数，SQL也便是联系代数理论上发展出来的形式言语。现在咱们能回答，为什么SQL在希望的两个方面做得不够好？问题出在联系代数上，联系代数就像一个只需加法还没创造乘法的算术系统，很多事做不好是必然的。联系代数现已创造五十年了，五十年前的使用需求以及硬件环境，和今天比的差异是很巨大了，继续延用五十年前的理论来处理今天的问题，听着就感觉太陈旧了？然而实际便是这样，由于存量用户太多，并且也还没有老练的新技术出现，根据联系代数的SQL，今天依然是最重要的数据库言语。虽然这几十年来也有一些改进完善，但根子并没有变，面临今世的杂乱需求和硬件环境，SQL不担任也是情理之中的事。并且，不幸的是，这个问题是理论上的，在工程上不管如何优化也无济于事，只能有限改善，不能根除。不过，绝大部分的数据库开发者并不会想到这一层，或者说为了照料存量用户的兼容性，也没计划想到这一层。所以，干流数据库界一直在这个圈圈里打转转。
SPL为什么能行
那么该怎样让核算写着更简略、跑得更快呢？创造新的代数！有“乘法”的代数。在其根底上再规划新的言语。这便是SPL的由来。它的理论根底不再是联系代数，称为离散数据集。根据这个新代数规划的形式言语，起名为SPL（StructuredProcessLanguage)。SPL针对SQL的缺乏（更切当地说法是，离散数据集针对联系代数的各种缺点）进行了改造。SPL重新界说了并扩展许多结构化数据中的运算，增加了离散性、强化了有序核算、完结了彻底的调集化、支撑目标引证、发起分步运算。把前面的问题用SPL重写一遍有个直接感受。一支股票最长接连上涨多少天：
stock_price.sort(trade_date).group@i(closing_price<closing_price[-1]).max(~.len())
核算思路和前面的SQL相同，但由于引入了有序性后，表达起来简略多了，不再绕了。1亿条数据中取前10名：

T.groups(;top(-10,x))
SPL有更丰厚的调集数据类型，简略描绘单次遍历上施行简略聚合的高效算法，不触及大排序动作。
限于篇幅，这儿不能介绍SPL（离散数据集）的全貌。咱们在这儿罗列SPL（离散数据集）针对SQL（联系代数）的部分差异化改进：游离记载离散数据会集的记载是一种根本数据类型，它能够不依赖于数据表而独立存在。数据表是记载构成的调集，而构成某个数据表的记载还能够用于构成其它数据表。比方过滤运算便是用原数据表中满足条件的记载构成新数据表，这样，不管空间占用仍是运算功能都更有优势。联系代数没有可运算的数据类型来表明记载，单记载实际上是只需一行的数据表，不同数据表中的记载也不能同享。比方，过滤运算时会仿制出新记载来构成新数据表，空间和时间本钱都变大。特别地，由于有游离记载，离散数据集答应记载的字段取值是某个记载，这样能够更便利地完结外键衔接。有序性联系代数是根据无序调集规划的，调集成员没有序号的概念，也没有供给定位核算以及相邻引证的机制。SQL实践时在工程上做了一些部分完善，使得现代SQL能便利地进行一部分有序运算。离散数据会集的调集是有序的，调集成员都有序号的概念，能够用序号拜访成员，并界说了定位运算以返回成员在调会集的序号。离散数据集供给了符号以在调集运算中完结相邻引证，并支撑针对调会集某个序号位置进行核算。有序运算很常见，却一直是SQL的困难问题，即便在有了窗口函数后依然很繁琐。SPL则大大改善了这个局势，前面那个股票上涨的例子就能阐明问题。离散性与调集化联系代数中界说了丰厚的调集运算，即能将调集作为全体参加运算，比方聚合、分组等。这是SQL比Java等高档言语更为便利的当地。但联系代数的离散性十分差，没有游离记载。而Java等高档言语在这方面则没有问题。离散数据集则相当于将离散性和调集化结合起来了，既有调集数据类型及相关的运算，也有调集成员游离在调集之外独自运算或再组成其它调集。能够说SPL会集了SQL和Java两者的优势。有序运算是典型的离散性与调集化的结合场景。次第的概念只需在调会集才有意义，单个成员无所谓次第，这儿表现了调集化；而有序核算又需求针对某个成员及其相邻成员进行核算，需求离散性。在离散性的支撑下才干获得更彻底的调集化，才干处理诸如有序核算类型的问题。离散数据集是即有离散性又有调集化的代数系统，联系代数只需调集化。分组了解分组运算的本意是将一个大调集按某种规则拆成若干个子调集，联系代数中没有数据类型能够表明调集的调集，所以强迫在分组后做聚合运算。离散数据会集答应调集的调集，能够表明合理的分组运算成果，分组和分组后的聚合被拆分成相互独立的两步运算，这样能够针对分组子集再进行更杂乱的运算。联系代数中只需一种等值分组，即按分组键值区分调集，等值分组是个彻底区分。离散数据集以为任何拆分大调集的办法都是分组运算，除了常规的等值分组外，还供给了与有序性结合的有序分组，以及或许得到不彻底区分成果的对位分组。聚合了解联系代数中没有显式的调集数据类型，聚合核算的成果都是单值，分组后的聚合运算也是这样，只需SUM、COUNT、MAX、MIN等几种。特别地，联系代数无法把TOPN运算看成是聚合，针对全集的TOPN只能在输出成果集时排序后取前N条，而针对分组子集则很难做到TOPN，需求改变思路拼出序号才干完结。离散数据集发起普遍调集，聚合运算的成果不一定是单值，依然或许是个调集。在离散数据会集，TOPN运算和SUM、COUNT这些是地位等同的，即能够针对全集也能够针对分组子集。SPL把TOPN了解成聚合运算后，在工程完结时还能够防止全量数据的排序，从而获得高功能。而SQL的TOPN总是随同ORDERBY动作，理论上需求大排序才干完结，需求寄希望于数据库在工程完结时做优化。有序支撑的高功能离散数据集特别强调有序调集，使用有序的特征能够施行很多高功能算法。这是根据无序调集的联系代数力不从心的，只能寄希望于工程上的优化。下面是部分使用有序特征后能够施行的低杂乱度运算：1)数据表对主键有序，相当于天然有一个索引。对键字段的过滤常常能够快速定位，以削减外存遍历量。随机按键值取数时也能够用二分法定位，在同时针对多个键值取数时还能重复使用索引信息。2)一般的分组运算是用HASH算法完结的，假如咱们确认地知道数据对分组键值有序，则能够只做相邻比照，防止核算HASH值，也不会有HASH冲突的问题，并且十分简略并行。3)数据表对键有序，两个大表之间对位衔接能够履行更高功能的归并算法，只需对数据遍历一次，不用缓存，对内存占用很小；而传统的HASH值分堆办法不只比较杂乱度高，需求较大内存并做外部缓存，还或许因HASH函数不当而形成二次HASH再缓存。4)大表作为外键表的衔接。事实表小时，能够使用外键表有序，快速从中取出相关键值对应的数据完结衔接，不需求做HASH分堆动作。事实表也很大时，能够将外键表用分位点分成多个逻辑段，再将事实表按逻辑段进行分堆，这样只需求对一个表做分堆，并且分堆进程中不会出现HASH分堆时的或许出现的二次分堆，核算杂乱度能大幅下降。
其间3和4使用了离散数据集对衔接运算的改造，假如依然延用联系代数的界说（或许发生多对多），则很难完结这种低杂乱的算法。
除了理论上的差异，SPL还有许多工程层面的优势，比方更易于编写并行代码、大内存预相关进步外键衔接功能等、特有的列存机制以支撑随意分段并行等。
大数据时代，我们一般会对高功能核算感兴趣，这儿再附一些SPL完结的大数据算法：
功能优化技巧：遍历复用
功能优化技巧：TopN
功能优化技巧：预相关
功能优化技巧：外键序号化
功能优化技巧：附表
功能优化技巧：单边分堆
功能优化技巧：有序分组