从另外一个角度看什么是数据库-技术圈

本文公众号来源：柳树的絮叨叨

作者：SexyCode

数据库是什么？

是 Mysql？Oracle？HBase？

或许你还能想到 Redis、Zookeeper，甚至是 Elasticsearch ……

让我们从一个文件系统开始。

数据库 1.0 —— 文件系统

我们正在做一个电子书的小程序。

一开始，我们把所有图书信息都放在 csv 文件中：

Book.csv ( title , author , year )

"Gone with the Wind","Margaret Mitchell",1936"Hamlet","William Shakespeare",1602"活着","余华",1993"三体","刘慈欣",2006

这种存储方式，实现起来简单，似乎很完美。

接下来，我们要查询《三体》的作者，于是写了这段代码：

for line in file:   record = parse(line)      if "三体" == record[0]:           print record[1]

我们用了「遍历」，这是非常糟糕的查询方式。

一旦后面数据量上去了，数据被存放在多个文件里，每次查询，我们就得打开很多个文件，打开后还要遍历里面的数据，「磁盘 IO」和「时间复杂度」都很高。

问题症结在于：我们的数据，是没有无规律的。

一旦数据没有规律，我们查找数据时，就不知道数据在哪个文件，就只能一个个文件打开来看，靠蛮力去遍历。

所以，让数据规律存储，是优化这个文件系统的第一步。

数据库 2.0 —— 规律存储

让数据有规律的存储，一旦数据有规律，我们就可以使用各种算法去高效地查找它们。

让书籍，按照「字典排序」升序存储，于是我们可以进行「二分查找」，时间复杂度从 O(n) -> O(log2n)，缺点是每次插入都要排序；

让书籍，按照「Hash 表」的结构进行存储，于是我们可以进行「Hash 查找」，用空间换时间，时间复杂度 O(1)；

让书籍，按照「二叉树」的结果进行存储，于是我们可以进行「二叉查找」，时间复杂度 O(log2n)；

二叉树极端情况下会退化成 O(n)，于是有了「平衡二叉树」；

平衡二叉树终究还是“二叉”，只有两个子节点，一次从磁盘 load 的数据太少，于是有了可以有多于 2 个子节点的 B 树；

B 树找出来的数据，是无序的，如果你要求数据排好序返回，还要在内存手动排一次序，于是有了叶子节点是一个双向链表的 B+ 树；

……

看到没，不断规律化你的存储结构，你就能得到越来越牛逼的查找性能。

当然你会发现，按照「作者」查询，我建一个 B+ 树，按照「年份」查询，我也建一个 B+ 树，这样每增加一个字段查询，我都要建一个 B+ 树，如果 B+ 树里面放的是全部数据的信息，那会很冗余、很占用空间；

于是我让 B+ 树只记录数据的唯一标识，按照索引找到数据的唯一标识后，再去 load 全量的数据。

这就是 Mysql 里面的「二级索引」和「聚簇索引」：

「二级索引」只存储对应字段和唯一标识，查找时利用「二级索引」，可以快速找到数据的「唯一标识」；
「聚簇索引」是数据实际存储的位置，它也是有序的，按照「唯一标识」有序存储；
所以你在「二级索引」里拿到「唯一标识」后，可以快速地在「聚簇索引」找到数据的位置，大大减少了磁盘 IO；

Mysql 有一句话，“索引即数据”，指的就是「聚簇索引」，当然，如果用到了「覆盖索引」，那「二级索引」也能提供数据。

我们经常说，「索引」提高了查找性能，其实不完全正确。

还是以 Mysql 为例，二级索引只是告诉了你数据的「唯一标识」，但是你还要拿着这个「唯一标识」去数据里查找，如果这些数据本身不是有序的，那你还是得找大半天。于是 Mysql 再弄了个 B+ 树来存储数据，让这些数据有序，也就是「聚簇索引」。

这就像你在字典里查一个单词 incredible ，你在目录，也就是索引里，找到这个单词在第 256 页，然而，这本书在装订的时候，页面订乱了，不是按递增来装订的，完全无序，于是乎，就算你知道了 incredible 在第 256 页，你还是得海底捞针般的，把整本书翻一遍。

「索引」仅仅帮助你快速找到数据的标识，辅之以「数据规律的存储」，才能「减少磁盘 IO」,才能「加速查询」：

索引 + 规律存储 = 快速查询

不过对于 Mysql 来说，它的规律存储，是通过「聚簇索引」来实现的，所以说是「索引」让它查询变快也对。

数据结构带来了规律存储和快速查询，也带来了操作的复杂度。

你再也不能随意插入数据，因为你要维护数据的规律性，不管你是顺序存储还是 B+ 树，都要找到正确的位置进行插入；

可能你还想做个缓存来进一步减少磁盘 IO，那你得维护好缓存的生命周期，等等 ……

这么多复杂的逻辑，如果都要让用户感知到，自己手动操作，那使用成本太高，每次插入都要写一大段代码，于是我们要给用户提供简洁的操作方式。

数据库 3.0 —— 简单操控

几乎你用过的所有数据库，都会提供让你很方便的操控它的方式。

像 Mysql、Oracle 等关系型数据库，操作它们的语言，都是 SQL（Structured Query Language，结构化查询语言），这是结构化数据领域的通用语言，于是我们称之为 DSL（domain-specific language，领域特定语言）：

INSERT INTO Customer (FirstName, LastName, City, Country, Phone)
VALUES (‘Craig’, ‘Smith’, ‘New York’, ‘USA’, 1-01-993 2800)

而像 redis，它也定义了自己的一套语言，但是它比较谦虚，自称为 Command :

redis> SET mykey “Hello” “OK” redis> GET mykey “Hello”

也有像 Elasticsearch 一样直接提供 Restful API 的：

curl -X GET “localhost:9200/twitter/_doc/0?_source=false&pretty”

DSL、Command、API，其实都是为了方便你使用，降低了你的使用成本，不至于插入个数据，都要写一堆代码。

但是对于你的学习成本，却不一定降低了，反之，可能加大了你的学习成本，因为它屏蔽了背后的实现细节。

看似简简单单的语句背后，触发的可能是一连串复杂的逻辑。

数据库 4.0 —— 隐藏技能

这些复杂的逻辑，就是数据库的隐藏技能。

一个数据库在隐藏技能上下的功夫，决定了它是 Mysql，还是 Microsoft Access，决定了它能在高性能高可靠的道路上走多远，决定了它能否被广泛用到生产环境。

而对一个数据库隐藏技能了解的程度，也成了衡量一个人对这项知识掌握程度的标准。

在你一行指令的背后，触发的隐藏技能，包括但不限于：

事务：事务具有四个属性：ACID，当然数据库不会完全满足这四个属性，有的数据库甚至还不支持事务，比如 Mysql 在「读未提交」的隔离级别下，就不满足「C 隔离性」，对数据可靠性要求不高的，比如 redis，它也无需实现事务（当然你可以用各种方法来近似实现）。
锁：和 Java 一样，有并发访问，就有并发安全，就需要锁，比如 Mysql 的 MVCC.
集群：这是实现一个高性能高可靠系统的标配，你需要对数据进行冗余和分片存储，所以，在插入一条数据时，你的数据库可能需要判断要插入到哪一台机器，插入后，还有判断要冗余到哪些个机器。
缓存：数据不能每次都去磁盘 load，放到缓存，缓存失效了再去磁盘拿，数据一旦被更新，缓存就失效吗？不，数据更新时，更新的是缓存的数据，同时记录日志，然后再去刷磁盘，Mysql 和 Elasticsearch 都这么做。
……

所以数据库到底是什么？

上文从「文件系统」开始，一步一步演化成一个常用的「数据库」。

这里我用「三个关键字」 + 「三句话」，来给「数据库」下一个演进式的、通俗易懂的定义：

规律存储的文件系统：数据库，是一个把数据进行「规律存储」的文件系统；
简单访问：它给使用者提供了简单的操控方式，去访问（插入、修改、查询）它的数据；
隐藏技能：为了做到高性能高可靠，它实现了一系列复杂的逻辑，这些逻辑对一般使用者来说无需关心。

我们再来看看维基百科上给「Database」和「DBMS」的定义：

Database
A database is an organized collection of data, generally stored and accessed electronically from a computer system. Where databases are more complex they are often developed using formal design and modeling techniques.
Database management system
Connolly and Begg define Database Management System (DBMS) as a “software system that enables users to define, create, maintain and control access to the database”

这是学术上的定义。

学术定义，目的是「给一个通用的解释」，「划定边界」，所以一般会比较抽象。

它告诉你：