NOSQL

基本上你对这个潮流有一些基本的了解，就会知道，所谓的“NOSQL”运动，大多数是指的非“关系数据库（Relational Database）”。所以，它应该叫“NORDB”更准确一些。我们看看这几年出现的，“NOSQL”的主要口号：

不使用外键关联、
不使用固定字段格式
MapReduce
KV数据库
牺牲一致性和完备性，提高性能
使用API接口，而非文本方式访问
这里我只列举了想到的一些，欢迎大家补充。我们可以看到，除了最后一条，其它其实与SQL无关。SQL全称“结构化查询语言”，是一门语言，它其实不拘于某一种数据库模型，很多LDAP（层次型数据库）实现都提供了SQL接口，包括著名的KV数据库BDB，新版中也有SQL支持。而就算“非关系”这个主题，总的来说，数据库领域非常的广大，关系型数据库虽为主流，但是其它模型的也很多，仅仅简单的将KV等同于非关系数据库（不是我乱讲，确有一部分同行有此误解），也不恰当。著名的MongoDB就不是KV模型，CouchDB也不是。NOSQL运动要解决的问题，并不完全由SQL语言引起，也不完全是因为关系模型。

不夸张的说，关系数据库是近二十年来MIS和互联网产业得以存在的基础。没有关系型数据库，肯定还是会有C／S和B／S模式，会有动态更新的网站服务，但开发成本会比现在高出很多很多，至少多出两个数量级毫不夸张。几个主流的关系型数据库产品，共同实现了一个不可能的任务：为IT业提供一个同时满足各种性能和功能需求，使用起来又足够简单的，持久化信息存储平台。

曾几何时，软件／互联网开发，就是写一个客户端或网页，用来对数据库的表进行增删改查，甚至业务逻辑也写进数据库，前端只访问存储过程。

但是，从那时到现在，已经几十年过去了，当年被强大好用的关系数据库掩盖的各种问题，随着性能和存储空间的压力，逐渐暴露出来。首先单节点的服务器已经不能再满足数据管理的需要，再强大的主机也存不下潮水般涌入的数据。大多企业是买不起更贵的服务器，买得起的金主，也要考虑世上有没有容量无限增长的主机。好吧到此为止仍不是关系型数据库的问题，我们还可以分库——但是，分库这个行为已经悄悄开始改变关系数据库的使用行为。接下来，就是速度问题。

这里仍然回到我前两篇博客的观点：计算机不会魔法。很多关系数据库的应用，其实抽象成键值关系，或层次等其它模型，会更贴切，更简单，于是有更高的性能。