SQL,NoSQL 以及数据库的实质

时间:2021-10-27 01:27:20


SQL,NoSQL 以及数据库的实质

     在之前的一些博文里(比如这篇),我多次提到关系式数据库和 SQL 的缺陷。我觉得它们是制造了问题又自己来解决,而且没有解决好。现在有了点时间,我就把这里面的细节稍微说一下,希望有一定的启发作用。

描述性语言的局限性

    当我指出 SQL 的问题时,总是避免不了有人反驳说:“SQL 是描述性的语言。你只告诉它 What,而不是告诉它 How。”我发现总是有人对一些我多年前就听腻了,看透了的“广告词”执迷不悟,而现在这同样的事又发生在 SQL 身上。他们没有发现,我不但能实现 SQL,而且已经实现过比 SQL 强大很多的语言(逻辑式语言),所以我其实早已看透了所有这些语言的实质,我知道那些广告词在很大程度上是误导。

    现在我就来分析一下 SQL 与逻辑式语言之间的关系,并且找出这类“描述性语言”共同的弱点。

Prolog 与人工智能的没落

    可以说,“只告诉它 What,而不是告诉它 How”,只是一个不切实际的妄想,而且它并不是 SQL 首创的口头禅。在 SQL 诞生两年以前,有人发明了 Prolog,著名的“逻辑式语言运动”的先锋。Prolog 使用了与 SQL 非常类似的广告词,声称自己能够一劳永逸的解决人工智能和自动编程的问题,这样人们不需要写程序,只需要告诉电脑“想要什么”,然后电脑就能自动生成算法,自动生成代码来解决这问题。

    不需要理解数据结构和算法,直接告诉电脑需要什么,它就给你答案,这是多么美妙的事情。世界上总是有很多这种类似“减肥药”的东西,每一个都声称自己是“不需运动,不需节食,一个星期瘦 20 斤!”然而由于人类的智力和经验参差不齐,总会有人上当。Prolog 当年的风头之大,以至于它被日本*采用并且大力推广,作为他们所谓的“第五代计算机”的编程语言。可惜的是,减肥药毕竟是减肥药,科学道理决定了 Prolog 必定失败,以及“人工智能冬天”(AI winter)的到来。

    为什么 Prolog 会失败呢?这是因为 Prolog 虽然“终究”有可能自动解决某些问题,然而由于它的算法复杂度太高,所以没法在我们有生之年完成。说白了,Prolog 采用的“计算”方式就是“穷举法”。为了得到用户“描述”的问题的答案,而不需要用户指定具体的数据结构和算法,Prolog 必须对非常大的图状解空间进行完全的遍历(Prolog 采用深度优先搜索)。而这种解空间的“状态”数量往往是与程序运行时路过的分支数目成指数关系,这就决定了 Prolog 虽然“最终”可能找到问题的答案,却很有可能在地球毁灭之前都没法完成它的搜索。而且由于 Prolog 无法表达真正意义上的“逻辑否”操作,所以对于很多问题它永远无法得到正确的答案(这是一个非常深入的问题,30 多年的研究,仍然没有结果)。

    过于具体的细节我不想在这里解释,你只需要明白的是我绝不是在信口开河。在 Indiana 的日子里,我重新实现,并且扩展了一种与 Prolog 类似的逻辑式语言,叫做 miniKanren。它也就是 Dan Friedman 的新书《The Reasoned Schemer》的主题。在两三个星期的时间内,我不但完全重写了 miniKanren 的代码(代码见这里),而且为它加入了一种技术叫做 constraint logic programming,并且在那之上实现了一个非常干净利落的“逻辑否”操作。经过这番动手操作,我对 miniKanren 和逻辑式语言的工作方式可以说是了如指掌。虽然 miniKanren 比起 Prolog 更加优雅,而且在搜索算法上有所改进(广度优先而非深度优先),它本质上采用的计算方式也是一样的:穷举法。所以在很多时候它的效率很低,用法不灵活。像 Prolog 一样,miniKanren 并不能用来解决很多实际的问题。有些很简单的 Scheme 代码,你却不能把它翻译成等价的 miniKanren。然而就是这样一种语言,比起 SQL 的表达能力,其实也是天上地下。所以在实现并且扩展了 miniKanren 这样的“智能语言”之后再来看 SQL,对于我来说就像是在解剖一只青蛙。

    这里只举一个例子,说明我所看到的所谓“描述性语言”的局限,看不懂的人可以暂时跳过。在 IU 的时候总有一些人喜欢用 miniKanren 来实现 Haskell 和 OCaml 的Hindley-Milner 类型系统(HM 系统)。HM 那种最基本的基于 unification 的类型推导,miniKanren 确实能做到,因为 miniKanren,Prolog 和 HM 系统一样,都是基于Robinson unification 算法。这种算法虽然精巧,表达能力却是非常有限的。如果遇到一些必要的扩展,比如 HM 系统所需要的 let-polymorphism,你就需要对 miniKanren 语言本身进行扩展。也就是说,你不再是用 miniKanren 实现你的算法,而是用一种过程式或者函数式语言(比如 Scheme)把你的算法加到 miniKanren 里面作为“语言特性”,然后再利用这个你刚实现的新特性来“实现”你的算法。于是你就发现,其实 miniKanren 本身并没有足够的表达力表示完整的 HM 类型推导算法。如果 miniKanren 必须经过 Scheme 扩展才能表达 HM 算法,那么比起直接的 Scheme 实现,miniKanren 并没有任何优势。一个新的语言特性要有价值,它必须能够在很多地方使用。然而这些 miniKanren 的扩展,每一个只能用到一个地方。所以它们其实完全失去了作为语言特性的价值,还不如直接写一段 Scheme 代码。

   这也就是为什么虽然我很感谢 miniKanren 教会了我逻辑编程的原理,然而我实现过的所有强大的类型系统(有些的能力大大超过 HM 系统),全都是用最普通的过程式或者函数式语言。“描述性语言”声称的好处,其实在这种关键时刻总是微乎其微,还不如调用普通语言的库代码。

从 Prolog 到 SQL

    扯了这么多 Prolog 和 miniKanren 的事情,这跟关系式数据库和 SQL 的讨论到底有何关系呢?其实,这些东西是有非常深层次的内在联系的。一个有趣的事情是,miniKanren 里面的“Kanren”一词并不是一个英语国家的人名,而是日语“関連”(かんれん,读作 kanren)。而“逻辑式语言”的另一个名字,其实叫做“关系式语言”(relational language)。

   在数学上,“关系”(relation)意味着“没有方向”,意味着“可逆”。然而具有讽刺意味的是,所谓的“关系式数据库”并不具有这种可逆计算的能力。Prolog 和 miniKanren 其实是比 SQL 强大很多的语言,是真正的“关系式语言”,它们能够在比较大的程度上完成可逆计算。比如在 miniKanren 里面,你可以使用这样“查询操作”:如果 x+y 等于 10,y 等于 2,那么 x 等于几?很多 Prolog 和 miniKanren 可以表达的查询,SQL 没法表示。SQL 其实只能用于非常简单的,有“明确方向”的查询操作,基本上就像 Lisp 的 filter 函数。由于这些局限性,再加上很多其他的设计失误(比如语法像英语,组合能力弱),它只适合会计等人员使用,一旦遇到程序员需要的,稍微复杂一点的数据结构,它就没法表达了,而且会像 Prolog 一样引起诸多的性能问题。

  由于 SQL 比起逻辑式语言有更多的限制,表达力弱很多,再加上 SQL 对于基本的数据结构进行了“索引”,逻辑式语言的性能问题在 SQL 里面得到了局部的缓解。比如,对于基本的算数操作x < 10,SQL 能够通过对索引(B树)的查找来进行“优化”,从而避免了对x 所有可能的值(一个非常大的空间)进行完全的遍历。然而这种索引的能力是非常有限的,它几乎没有扩展能力,而且很难自动生成。所以一旦遇到更加复杂的情况,数据库自带的索引就没法满足需要了。除了极其简单的情况,SQL 的编译器无法自动生成高效的索引。

    更要命的是,这种问题的来源是根本性的,不可解决的,而不只是因为某些数据库的 SQL 编译器不够“智能”。很多人不理解这一点,总是辩论说“我们为何需要 Java 而不是写汇编,也就是我们为何需要 SQL。”然而,把 Java 编译成高效的汇编,和把 SQL 编译成高效的汇编,是两种本质上不同的问题。前者可以比较容易的解决,而后者是不可能的(除了非常个别的情况)。如果你理解“编译器优化”的本质就会发现,这里面有一个拓扑学上的质的飞跃。把 Java 编译成高效的汇编,是一个非常简单的,线性的优化。这个过程就像改进一个已经连接好的电路,把里面太长的电线缩短一点,这样时延和电阻可以小一些。而把 SQL 优化成高效的汇编,是一个非线性的优化。这个过程不只是缩短电线那么简单的问题,它需要解开一些错综复杂的“结”。这种优化不但非常难以实现,需要大量的“潜在数学知识”,而且有可能花费比执行代码还多的时间。

    我只举一个例子来说明这个问题。如果你需要迅速地在地图上找到一个点附近的城市,SQL 无法自动在平面点集上建造像 KD-tree 那样的数据结构。这是很显然的,因为 SQL 根本就不知道你的数据所表示的是平面上的点集,也不理解平面几何的公理和定理。跟 B-tree 类似,知道什么时候需要这种特殊的索引结构,需要非常多的潜在数学知识(比如高等平面几何),所以你肯定需要手动的建立这种数据结构。你发现了吗,你其实已经失去了所谓的“描述性”语言带来的好处,因为你完全可以用最普通的语言,加上一些构造 B-tree, KD-tree 的“库代码”,来实现你所需要的所有复杂查询操作。你的 SQL 代码并不会比直接的过程式代码更加清晰和简洁。再加上 SQL 本身的很多设计失误,你就发现使用 SQL 数据库其实比自己手工实现这些数据结构还要痛苦。你学会 SQL 是为了避免编程,结果你不得不做比编程还要苦逼的工作,还美其名曰“performance tuning”。

    到这里也许有人仍然会说,这只是因为现在的 SQL 编译器不够智能,总有一天我们能够制造出能够“自动发明”像 B-tree, KD-tree 这样索引结构的“优化算法”。我对此持非常不乐观的态度。首先你要意识到,哪怕最基本的数学知识,也是经过了人类几千年的实践,研究和顿悟才得到的。计算机虽然越来越快,它却缺乏对于世界最直接的观察和探索能力,所以在相当长的时间内,计算机是根本不可能自动“想到”这些数学和算法问题的,就不要谈解决它们。其次,即使计算机有一天长了脚可以走路,有了眼睛可以看见东西,有了“*意志”,可以自己去观察世界,它却不一定能够发现并且解决“人类关心的数学问题”,因为它根本不知道人类需要什么。最后,我们需要在有生之年解决这些迫切的问题,我们无法等待几十年几百年,就为了让计算机自己想出像 KD-tree 一类众所皆知的数据结构。

     计算机不可能猜到人类到底想要什么,这就是为什么你几乎总是需要手动指定索引的原因,而且这种索引需要数据库“内部支持”。你一次又一次的希望 SQL 能够自动为你生成高效的索引和算法,却一次又一次的失望,也就是这个原因。当然,你永远可以使用所谓的 stored procedure 来扩展你的数据库,然而这就像是我的 IU 同学们用 miniKanren 来实现 HM 类型系统的方式——他们总是先使用一种过程式语言(Scheme)来添加这种描述性语言的“相关特性”,然后欢呼:“哇,miniKanren 解决了这个问题!”而其实呢,还不如直接使用过程式语言来得直接和容易。

    这种总是需要扩展的显现也出现在数据库的语言里面。经验告诉我,如果想数据库处理大量数据时达到可以接受的性能,你几乎总是需要使用普通语言对手头的数据库进行所谓的“扩展”,然后从 SQL 等查询语言“调用”它们。这种扩展代码往往是一次性的,只能用在一个地方,从而使得这些查询语言失去了存在的意义。因为如果经常如此,我们为何不直接发送这种过程语言到数据库里面执行,从而完全取代 SQL?

  另外有一种数据库查询语言叫 Datalog,它结合了 SQL 和 Prolog 的特点。然而以上对于 SQL 和 Prolog 的分析,同样也适用于 Datalog。

关系模型的实质

    每当我批评 SQL,就有人说我其实不理解关系模型,说关系模型本身并没有问题,所以现在我就来分析一下什么是关系模型的实质。其实关系模型比起逻辑式语言,基本就是个衍生产物,算不上什么发明。关系代数其实对应逻辑式语言里面的一个很小的部分——它的数据结构及其基本操作,只不过关系模型有更大的局限性而已。所以学会了逻辑式语言的设计之后,你直接就可以把关系模型这种东西想出来。

    每当谈到关系模型,总是有人很古板的追究它与 SQL,Datalog 等“查询语言”的区别。然而如果你看透了逻辑式语言的本质就会发现,其实“语言”和“模型”这两者并没有本质区别和明确界限。人们总是喜欢制造这些概念上的壁垒,用以防止自己的理论受到攻击。追究语言和模型的差别,把过错推到 SQL 和 IBM 身上,是关系式数据库领域常见的托词,用以掩盖其本质上的空洞和设计上的失误。所以在下面的讨论里为了方便,我仍然会使用少量 SQL 来表示关系模型里面对应的概念,但这并不削弱我对关系模型的批评。

关系模型与逻辑式语言

    我们先来具体探讨一下关系模型与逻辑式语言的强弱关系。之前我们已经提到了,关系式数据库所谓的“关系”,比起逻辑式语言来说,其实是小巫见大巫。关系式数据库的表达能力,绝对不会超过逻辑式语言。关系式代数里面的“=”,join 等构造都是没有方向的。然而与逻辑式语言不同,这些“可逆操作符”在关系代数里的用法受到非常大的限制。比如,这些可逆操作都不能跨过程,而且关系模型并不包含递归函数。所以你并不能真正利用这种“无方向的代码”来完成比“有方向代码”更加强大的功能,大部分时候它们本质上只是普通程序语言里面最普通的一些表达式,只不过换了一种更“炫”的写法而已。

    总是有人声称限制语言的表达力可以让语言更加容易优化,然而如果一个语言弱得不能用,优化做得再好又有什么用。关系模型的核心,其实是普通程序语言里面最简单的部分:表达式。如果缺乏控制结构和递归,这些表达式的能力只相当于最简单的计算器。经验告诉我,就算表达力这么弱的语言,很多数据库的编译器也不能把优化做好,所以这不过是为它的弱表达力找个借口。另外由于这种无方向的表达式让你在阅读的时候很难看清楚数据的“流向”,所以你很难理解这里面包含的算法。这种问题也存在于逻辑式语言,但因为逻辑式语言的表达力在某些方面强于过程式语言,所以感觉还不算白费劲。然而,关系模型有着逻辑式语言的各种缺点,却不能提供逻辑式语言最基本的长处,所以比起过程式语言来说其实是一无是处。

关系模型与数据结构

    我们再来探讨一下关系模型与数据结构的关系。很多人认为关系式数据库比起数据结构是一个进步,然而经过仔细的思考之后我发现,它其实不但是一个退步,而且是故弄玄虚,是狗皮膏药。在 IU 的时候,我做过好几个学期数据库理论课程的助教。当时我的感受就是,很多计算机系学生上了“数据结构”课程之后,再来上“数据库理论”课程,却像是被*了一样,仿佛根本没有理解数据结构。经过一段时间的接触之后,我发现其实他们大部分人只是被数据库领域的诸多所谓“理论”,“模型”或者“哲学”给迷惑了。本来是已经理解的数据结构和算法,却被数据库理论给换成了等价却又吓人的新名词,所以他们忽然搞不明白了。我是很负责的老师,所以我努力地思索,想让他们找回自我,最后我成功了。经过我如下的分析,他们大多数后来都茅塞顿开,对关系式数据库应用自如,最后取得了优异的成绩。

其实,关系模型的每一个“关系”或者“行”(row),表示的不过是一个普通语言里的“结构”(就像 C 的 struct)。一个表(table),其实不过是一个装着结构的数组。举个例子,以下 SQL 语句构造的数据库表:

CREATE TABLE Students ( sid CHAR(20),
name CHAR(20),
login CHAR(20),
age INTEGER,
gpa REAL )

其实相当于以下 C 代码构造的结构的数组:

struct student {
char* sid;
char* name;
char* login;
int age;
double gpa;
}

每一个 join,本质上就是沿着行里的“指针”(foreign key)进行“寻址”,找到它所指向的东西。在实现上,join 跟指针引用有一定区别,因为 join 需要查软件哈希表,所以比指针引用要慢。指针引用本质上是在查硬件哈希表,所以快很多。当然,这些操作都是基于“集合”的,但其实普通语言也可以表示集合操作。

所谓的查询(query),其实就是普通的函数式语言里面的 filter, map 等抽象操作,只不过具体的数据结构有所不同。关系式代数更加笨拙一些,组合能力弱一些。比如,以下的 SQL 语句

SELECT Book.title
FROM Book
WHERE price > 100

本质其实相当于以下的 Lisp 代码(但不使用链表,执行机制有所不同而已):

(map book-title
(filter (lambda (b) (> (book-price b) 100)) Book)

所以关系模型所能表达的东西,其实不会超过普通过程式(函数式)语言所用的数据结构,然而关系模型却有过程式数据结构所不具有的局限性。由于经典的关系“行”只能有固定的宽度,所以导致了你没法在结构里面放进任何“变长”的东西。比如,如果你有一个变长的数组需要放进结构,你就需要把它单独拿出来,旋转 90 度,做成另外一个表,然后在原来的表里用一个“key”指向它们。在这个“中间表”的每一行,这个 key 都要被重复一次,产生大量冗余。这种做法通常被叫做 normalization。这种方法虽然可行,然而我不得不说这是一个“变通”。它的存在是为了绕过关系模型里面的无须有的限制,终究导致了关系式数据库使用的繁琐。说白了,normalization 就是让你手动做一些比 C 语言的“手动内存管理”还要低级的工作,因为连 C 这么低级的语言都允许你在结构里面嵌套数组!然而,很多人宝贵的时间,就是在构造,释放,调试这些“中间表格”的工作中消磨掉了。

这些就是关系模型所有的秘密。如果你深刻的理解了数据结构的用法,那么通过反复推敲,深入理解以上这番“补充知识”,你就能把已知的数据结构常识应用到所谓的“关系模型”上面,从而对关系式数据库应用自如,甚至可以使用 SQL 写出非常复杂和高效的算法。

另外有一些人(比如这篇文章)通过关系模型与其它数据模型(比如网状模型之类)的对比,以支持关系模型存在的必要性,然而如果你理解了这小节的所有细节就会发现,使用基本的数据结构,其实可以完全的表示关系模型以及被它所“超越”的那些数据模型。说实话,我觉得这些所谓“数据模型”全都是故弄玄虚,无中生有。数据模型可以完全被普通的数据结构所表示,然而它们却不可能表达数据结构带有的所有信息。这些模型之所以流行,是因为它们让人误以为知道了所谓的“一对一”,“一对多”等肤浅的概念就可以取代设计数据结构所需要的技能。所以我认为它们其实也属于技术上的“减肥药”。

NoSQL 的“革命”

      SQL 和关系模型所引起的这一系列无须有的问题,终究引发了所谓 NoSQL 的诞生。很多人认为 NoSQL 是划时代的革命,然而在我看来它很难被称为是一次“革命”,最多可以被称为“不再愚蠢”。而且大多数 NoSQL 数据库的设计者们并没有看到以上所述的问题,所以他们的设计并没有完全摆脱关系模型以及 SQL 带来的思维枷锁。

      最早试图冲破关系模型和 SQL 限制的一种数据库叫做“列模式数据库”(column-based database),其代表包括 Vertica, HBase 等产品。这种数据库其实就是针对了我刚刚提到的,关系模型无法保存可变长度数组的问题。它们所谓的“列压缩”,其实不过是在“行结构”里面增加了对“数组”的表示和实现。很显然,每一个数组需要一个字段来表示它的长度,剩下的空间用来依次保存每一个元素。所以在这种数据库里,你大部分时候不再需要进行 normalization,也不需要重复存储很多 key。这种对数组的表示,是一开始就应该有的,却被关系模型排除在外。然而,很多列模式数据库并没有看到这一实质。它们经常设定一些无端的限制,比如你的变长数组只能有非常有限的嵌套层数之类,所以它们其实没能完全逃脱关系式数据库带来的思想枷锁。让我很惊讶的是,如此明显的事情,数据库专家们最开头恁是看不到。到后来改来改去改得六成对,还美其名曰“优化”和“压缩”。

      最新的一些 NoSQL 数据库,比如 Neo4j, MongoDB 等,部分的针对了 SQL 的表达力问题。Neo4j 设计了个古怪又不中用的查询语言叫 Cypher,MongoDB 使用冗长繁琐的 JSON 来直接表示对数据的查询,就像是在手写编译器里的 AST 数据结构。Neo4j 的 Cypher 语言不但语法古怪,表达力弱,而且效率非常低,以至于几乎任何有用的操作你都必须使用 Java 写扩展来完成(参考这篇博文)。所以到现在看来,数据库的主要问题已经转移到了语言设计的问题,而且它们会在很长一段时间之内处于混沌之中。

       其实数据库的问题哪有那么困难。只要你有一个好的程序语言,你就可以发送这种语言的代码到“数据库服务器”,这个服务器可以远程执行你的代码,调用服务器上的“库代码”对数据进行索引,查询和重构,然后返回代码指定的结果。如果你看清了 SQL 的实质,就会发现这样的“过程式设计”其实并不会损失 SQL 的“描述性语言”的表达能力。反而由于过程式语言使用的简单性,直接性和普遍性,会使得开发效率大大提高。NoSQL 数据库比起 SQL 和关系式数据库存在一些优势,也就是因为它们在朦胧中朝着这个方向发展。

       然而,NoSQL 并不总是朝着正确的方向发展。因为设计它们的人往往没有专业的修习过程序语言的设计,缺乏对历史教训的认识,所以他们经常犯下不应有的设计错误。我经历过好些 NoSQL 数据库之后发现,它们的查询语言设计几乎完全没有章法。而且由于具体的实现质量以及商业动机,这些数据库往往有各种各样恼人的问题。这是必然的现象,因为这些数据库公司靠的就是咨询和服务作为收入,如果他们把这些数据库高质量又开源的实现,没有烦人的问题,谁会给他们付费呢?

      所以,这些 NoSQL 数据库问题的存在,也许并不是因为人们都很笨,而是因为世界的经济*仍然是资本主义,大家都需要骗钱糊口,大家都舍不得给“小费”。有人说我这是“阴谋论”,可惜总有一天你会意识到,这的确是一个阴谋。如果你想知道跟 NoSQL 数据库公司打交道是什么感觉,可以参考一下我这篇博文里面关于 Neo4j 的部分。

总结

说了这么多,其实主要的只有几点:

  1. 关系模型是一个无需有的东西。它严重束缚了人们的思想,其本质并不如普通的数据结构简单和高效。它比起逻辑式语言的理论来说是非常肤浅的。
  2. SQL,Datalog,Prolog 等所谓“描述性语言”的价值被大大的高估了。使用它们的人往往有“避免编程”的心理,结果不得不做比编程还要痛苦的工作:数据库查询优化。
  3. 数据库完全可以使用普通的程序语言(Java,Scheme 等)的“远程执行”来进行查询,而不需要专门的查询语言。这在某种程度上就是 NoSQL 数据库的实质和终极发展方向。

    对数据库的问题有更多兴趣的人,可以参考我的一篇相关的英文博客,以及这篇《一种新的操作系统的设计》里面的相关部分。

习题

有人评论说我其实不懂 SQL,现在我就来考考你的 SQL 编程能力,看看到底是谁理解 SQL 多一些 :)

     题目:请用 SQL 实现 Dijkstra 的最短路径算法。

    为了加深对数据库的认识,每个人都应该用 SQL 来实现这样稍微复杂的算法,而不只是写一些高中生都会的基础程序。如果你仍然相信“What,not How”的广告,反对使用 SQL 来写这样的过程式算法,那么就请你更进一步,使用你所谓的“What 查询方式”来高效的解决最短路径问题。


原文地址:

http://www.yinwang.org/blog-cn/2014/04/24/sql-nosql/