vlambda博客
学习文章列表

传统数据库如Mysql、Oracle的出现解决了早期互联网对于数据存储、数据一致性的问题，但随着互联网、物联网的快速发展而导致对数据存储的要求不只是数据一致性，还有了更多特性需求。

传统数据库有几个缺点：在大数据场景下读取IO较高、无法存储灵活的数据结构、表结构扩展不方便、全文搜索功能较弱（使用索引效率低）、不擅长出复杂关系型数据库，因此非关系型数据库NoSQL是极好的解决方案。

作为关系型数据库的补充，再根据互联网时代的需求不同，NoSQL可以分为：

Key-Value数据库

所谓KV数据库就是按照键值对进行存储的数据库，key是数据的标识，value是数据的值。Redis是典型的KV数据库，可以存储string、hash、list、set等数据结构。

我们以微博清除历史粉丝为例，对于redis来说，只要使用RPOPkey从队列的右边出队一个元素就可以了。是不是很简单？

但如果是关系数据库就比较复杂了，因为关系型数据库是行式存储，所以在建表时每条数据除了有数字编号之外，还有位置编号，用于判断数据是否第一条，其次通过sql语句找到了第一条数据之后，再次执行sql删除语句，最后更新从第二条开始的所有数据的位置编号。可以看到关系型数据库需要进行多次SQL操作，实现非常麻烦，效率低，性能低。

Redis数据库的主要缺点是不支持完整的ACID事务，但其实大部分业务也不需要严格遵守ACID原则，比如刚刚的微博粉丝案例，少一个或多一个粉丝对于我们并没有什么影响。

文档数据库

文档数据库有两个缺点。

缺点之一是不支持事务操作，比如使用MongoDB来存储商品库存，用户付款、减库存属于一个事务操作，用关系型数据库就很简单，如果使用MongoDB来实现，就可能出现库存减了但是用户没有付款的情况。

缺点之二是不支持join操作，比如我们想查询购买了陈克明面条中的女性用户，使用关系型数据库，将用户信息表和订单表通过用户ID来join操作就可以了，如果使用MongoDB，则需要查询订单表中买了陈克明面条的用户，再查询用户中的女性用户。

列式数据库

所谓列式数据库就是按照列来存储数据的数据库，传统的关系型数据库是按行来存储在磁盘，即行式数据库，典型的列式数据库是HBase。怎么理解行式和列式存储呢？

以某个用户信息登记表来说，按行存储是二维表格中的每一行占据一块连续的存储空间，按列存储则是每一列占据一块连续的存储空间。所以列式存储数据库非常适合大数据分析场景。

比如我们想分析某个区域的平均身高和体重，在mysql数据库中需要获取到每行的身高、体重数据，再来求平均，如果有10000个人，就需要请求磁盘空间10000次；在hbase数据库中我们只需要请求两次，获取身高和体重这一列的数据求平均即可。

中期的时候是敏捷开发模型。因为互联网上涌入的网民开始增多，大家的关注点开始变成好用、好玩，而此时一些有远见的人开始注意到互联网红利，投身于互联网，此时的开发模式演变成了敏捷开发模型。

敏捷开发模型面对的是频繁的需求变化，要求快速开发。比较流行的实际案例则是Scrum、XP极限编程。在新迭代（一般2-6周）开始前，产品经理将需求拆分成具体的开发任务，研发人员进行任务认领，每日站会进行任务的review，直到开发完成，发布新的可用版本。

列式数据库的缺点就是不适合小量数据、不适合随机的更新数据、不适合有删除和更新的实时操作、不适合ACID事务，因为列式存储中要随机的去更新数据或删除某条数据，比较耗费磁盘IO，影响整体的性能。

搜索引擎数据库

所谓搜索引擎数据库就是支持在数据库内通过关键字全文检索，传统的关系型数据库是通过索引，比如like、where等语句来达到快速查询，在全文检索的情况下，需要整个表扫描，效率非常低。ElasticSearch是典型的全文搜索引擎数据库，采用倒排索引的模式，建立从单词到文档的索引关系。比如现在我们有这样的一个文档集合，按单词将文档内容进行拆分，如文档1-谷歌地图之父跳槽Facebook，可拆分成单词谷歌（单词ID为1）、地图（单词ID为2）、之父（单词ID为3）、跳槽（单词ID为4）、Facebook（单词ID为5），其余的依次拆分可得到如下的倒排索引表….

通过关键字就可以检索文章了，我们在数据库搜索谷歌时，所有的结果都会返回，搜索创始人时则只返回“谷歌地图创始人拉斯离开谷歌加盟Facebook”。

SQL与NoSQL在是随着互联网的发展衍生的不同产物，在某一类业务的处理上都有自己的强项，在本文中我们介绍了四种类型的非关系型数据库，你清楚了NoSQL哪些地方强了嘛？而在业务中，我们将SQL与NoSQL结合，取长补短，赋能业务即可～

课工场

更可靠的IT就业教育