作为一个天天都在CRUD的程序员,你有没有想过,数据库是如何工作的?
今天,让我们从一个最最最简单的模型开始,揭开数据库神秘的一角。
对我们使用者而言,数据库就像是一个黑盒子,你可以往它里面写入数据,也可以从它里面读出数据。
让我们暂时抛却SQL、网络连接、数据库等等概念,就来看这个最基本的需求:如果我们来实现一个可以对外提供读写数据的黑盒子,该怎么做?
假设我们的黑盒子很简单,里面只有一张表:user_info
,用来存储用户信息。
表里面也很简单,只有三个字段,分别记录用户的ID、姓名和手机号。
user_id(uint32)
name(char[8])
phone(char[20])
我们可以用一个简单的结构体(或者一个class)来表示一条数据:
struct DataRecord{
uint32 user_id;
char name[8];
char phone[20];
};
user_id是一个uint32类型,占4个字节,name占8个字节,phone占20个字节,加起来一条数据总共占32个字节。
我们选择用一个文件来存储这些数据,存储非常简单,只需要一条一条地码在一起就行了,就像这样:
数据存储方式有了,接下来就是如何来读写了,我们来提供两个函数,分别来插入(insert)和查询(select)数据:
// 伪代码
void insert(Table* table, DataRecord record) {
fp = open(table->file_name);
fseek(fp, FILE_END);
write(fp, sizeof(DataRecord));
close(fp);
}
插入很简单,直接打开表对应的数据文件,然后把文件指针移动到文件尾部,接着追加数据,最后关闭文件,大功告成。这和把大象关进冰箱的步骤是一样一样的。
接下来是查询,我们提供一个可以通过id来查询用户的函数:
// 伪代码
DataRecord select(uint32 user_id) {
DataRecord result;
fp = open(table->file_name);
while (1) {
if (feof(fp))
break;
DataRecord record;
read(fp, &record, sizeof(DataRecord));
if (record.user_id == user_id) {
result = record;
break;
}
}
close(fp);
return result;
}
查询也很简单,我们打开文件,一条一条读取数据,然后比较用户id和给定的参数是否相同,直到找到符合条件的数据返回。
好了,以上,我们就实现了一个最最最基础的黑盒子:它里面有一张表,然后可以往里面写数据,从里面查数据。
现在来思考一下:
如果我们写了很多数据进去,比如几十万条,我们要查一个指定id的数据,要按照这样一条条比对,那不得等到猴年马月去了?
为什么要一条条比对呢?是因为我们的数据全都是一条一条码在一起的,完全没有顺序,所以要查询,只能这样一条条检查——全表扫描。
如果我们的数据是有顺序的呢?
假如我们插入数据的时候,是按照id从小到大排列着,这样我们就能用二分法快速找到指定id的数据了。
看上面这张图,假设我们要查找id为9的数据,我们可以读取第一条数据的id是1,就知道id为9的数据肯定在它后面。然后再读取最后一条数据id是12,就知道id为9的数据肯定在它前面,然后选择中间的数据读取,如此二分查找,很快就能锁定目标,不用每条数据都读取了。
因为每条数据都是32个字节,所以可以非常方便定位任意一条数据的位置:第n条数据的位置在32*(n-1)偏移处。
通过改变数据的存储组织形式,我们可以把数据查找的时间复杂度从O(N)下降到O(LogN)。
但如此一来,查找是变快了,但插入就麻烦了。以前的时候,我们直接把数据塞到文件最后就拍拍屁股走人了。但现在不行了,我们得把数据按照顺序,插入到合适的位置。
最麻烦的是,我们的数据是一条一条挨个码在一起的,如果中间某个位置要插入数据,就得把那个位置及其以后的数据通通往后移动,这就涉及到大量的数据复制移动,开销非常大。
要是每来一条insert操作就数据大量迁徙,那不得累得半死?
(其实不止插入,删除数据delete也同样如此麻烦。)
就没有一种办法,可以同时插入快,查询也快吗?
仔细思考一下,前面我们把数据按顺序一条一条码在一起,查起来为什么快?
是因为做了排序以后,数据的存储位置有一条隐含的信息:如果id比我们要找的小,那我们要找的肯定在它后面;反之,如果id比我们要找的大,那我们要找的肯定在它前面。
之所以有这个规律,是因为我们按id的大小进行了排序存储。
那如果现在回到最开始的那种方式,不排序了,还是一条一条顺序来写入,就没有这个信息了。
但如果,我们在每条数据记录中增加一些额外的信息,用来指示id比它小的在哪里,id比它大的又在哪里,是不是就能顺着这些额外的信息“顺藤摸瓜”找到要找的数据呢?
或许,聪明的你已经看出来了,这是按照“二叉树”的形式在记录数据位置信息。
但实际上,二叉树也才两个分叉,如果数据量很大的话,这棵树就会很高很瘦。
而每一次走入一个分支,就对应着一次文件I/O,所以在实际使用中,不会使用二叉树,而是使用开了非常多个叉的树——B树或者B+树。
如果用B树或者B+树来将文件中的数据在逻辑上组织起来,要查找数据就会快得多。
用id来查找数据问题解决了,但如果要用name来查找又该怎么办呢?
想一想,如果另外有一个文件,记录了每个name和这个name对应的数据记录在文件中的偏移位置,就像这样:
user_id | 数据位置(偏移) |
---|---|
xuanyuan | 0 |
shuaidi | 31 |
april | 63 |
dibingfa | 95 |
有了这个东西,是不是就简单很多了?只需要在这里搜一遍,拿到数据的位置,然后打开文件,定位到对应的偏移,一下就读出来了。
我们可以另外准备一个文件,同样使用B树或者B+树的形式来组织上面表格中的对应关系。
聪明的你可能已经看出来了,这玩意儿其实就是索引。
当然,实际中的数据库系统的索引实现或多或少有一些差别,但道理是通用的。
这里,再给大家推荐一个Github的开源项目,手把手教大家写一个最简单的数据库出来。
https://cstack.github.io/db_tutorial/
很多朋友简历上的项目经历,要么是XXX管理系统,要么是一个Web服务器,这些都太烂大街了,以后要是简历上来一个手写数据库系统,那绝对能让面试官眼前一亮。