数据库，终究还是数据结构

好久不写博客了，也是ITEYE最近的首页文章实在太水，来逛的少。最近在看淘宝沈询的博客文章，讲数据库方面的理论和实践，科普性的小文，有时来点小幽默，看起来蛮轻松。微博上也大概录了二十条笔记，现在满脑子各类数据结构的特性，如范围查找、读写性能、是否面向磁盘结构、并行指标、内存占用。像把大学时学的不怎么好的数据结构重新捡起了理了一遍，当时觉得这一大坨各种烦人还绕人的数据结构究竟有啥用（其实现在工作中用到的也就有限的几种，包括算法也是，做行业业务软件的重点还是在梳理业务），现在才知道大用场在这里，IT系统的基石还是这些东东。拿数据库来说，因为无数前辈们的智慧能够将底层巨复杂的东东抽象成你所需要了解的SQL语言就可以应付一般的单机数据库日常使用需要。

 

数据库底层的核心，其实就是映射（mapping），也就是一大堆的key－value。针对这些映射数据，其实做的就是两件事：读和写。不断的读，不断的写，交叉的读和写，这些就是数据库需要做的事情。但只这么说的话其实懂点计算机语言的都能写个小数据库出来，但一般除了写的人自己没人用，为什么？当然是性能。

 

SQL语言可以看作是一个数据库供使用时的操作指令，但如果你的数据库读/写时很慢，比其它产品慢（不拿商业的就拿开源的比）那鬼才用你，当然以国内的环境说不定某些高校中倒会发生这种奇葩事情。但说到慢肯定不会一开始就慢（不然这鸟代码写的得多烂），一般都会达到某种限制之后才会出现，比如并发读，已经存有大量数据时的写，如何保证事务等等，这时才是拼产品真正实力的时候。针对各种不同的问题场景，出现了不同的解决方案，比如要快速查找数据，用有序数组存储，其二分查找的时间复杂度大概是O(log2N)。用平衡二叉树可以支持数据自动扩展，让树能够在保持有序的前提下尽可能平衡。要并行度高的话可以用跳表，要面向磁盘结构的话可以试试B树、LSM Tree。但又没有一种数据结构能包打天下？答案是没有，没有一种能够解决所有的问题，实际更多是在各种权衡和妥协中找到一个平衡点。

 

正如作者所言“在目前的硬件体系下，写的快的一般查询都慢，查询的条件支持丰富的基本上写的都慢，好不容易弄个系统写的也快查的也挺快的机器消耗就大了。市面上的大部分的数据库系统，主要做的事情就是把数据在上面这两类数据库中倒来倒去，以期望于满足更多应用的需求场景，代价嘛就是代码非常复杂。”

 

现实就是容易理解的模型往往性能都不好，性能好的模型往往不容易理解，所以数据库，终究还是数据结构。。。