一、引入：

当时我正在编写一个用户关系模块，这个模 块需要实现一个“共同关注”功能，用于计算出两个用户关注了哪些相同 的用户。 举个例子，假设huangz关注了peter、tom、jack三个用户，而john关 注了peter、tom、bob、david四个用户，那么当huangz访问john的页面 时，共同关注功能就会计算并打印出类似“你跟john都关注了peter和 tom”这样的信息。

数学问题：

从集合计算的角度来看，共同关注功能本质上就是计算两个用户关 注集合的交集，因为交集这个概念是如此的常见，所以我很自然地认为 共同关注这个功能可以很容易地实现，但现实却给了我当头一棒：我所 使用的关系数据库并不直接支持交集计算操作，要计算两个集合的交 集，除了需要对两个数据表执行合并（join）操作之外，还需要对合并 的结果执行去重复（distinct）操作，最终导致交集操作的实现变得异常 复杂

并最终发现了Redis。在我看来，Redis正是我想要 找的那种数据库——它内置了集合数据类型，并支持对集合执行交集、 并集、差集等集合计算操作，其中的交集计算操作可以直接用于实现我 想要的共同关注功能。 得益于Redis本身的简单性，以及Redis手册的详尽和完善，我很快 学会了怎样使用Redis的集合数据类型，并用它重新实现了整个用户关 系模块：重写之后的关系模块不仅代码量更少，速度更快，更重要的 是，之前需要使用一段甚至一大段SQL查询才能实现的功能，现在只需 要调用一两个Redis命令就能够实现了，整个模块的可读性得到了极大 的提高。

二、关系型数据库：

1.概念

关系型数据库是指采用了关系模型来组织数据的数据库。简单来说，关系模式就是二维表格模型。

主要代表：SQL Server，Oracle,Mysql,PostgreSQL。

关系模型把数据看作是一个二维表格，任何数据都可以通过行号+列号来唯一确定，它的数据模型看起来就是一个Excel表：

┌─────┬─────┬─────┬─────┬─────┐
│     │     │     │     │     │
├─────┼─────┼─────┼─────┼─────┤
│     │     │     │     │     │
├─────┼─────┼─────┼─────┼─────┤
│     │     │     │     │     │
├─────┼─────┼─────┼─────┼─────┤
│     │     │     │     │     │
└─────┴─────┴─────┴─────┴─────┘

2.优点

（1）.容易理解，二维表的结构非常贴近现实世界，二维表格，容易理解。

（2）使用方便，通用的sql语句使得操作关系型数据库非常方便。

（3）易于维护，数据库的ACID属性，大大降低了数据冗余和数据不一致的概率。

3.瓶颈

(1 )海量数据的读写效率。对于网站的并发量高，往往达到每秒上万次的请求，对于传统关系型数据库来说，硬盘I/o是一个很大的挑战。

(2) 高扩展性和可用性。

在基于web的结构中，数据库是最难以横向拓展的，当一个应用系统的用户量和访问量与日俱增的时候，数据库没有办法像web Server那样简单的通过添加更多的硬件和服务节点来拓展性能和负载能力。

三、从关系型到非关系型

关系型数据库的最大优点就是事务的一致性，这个特性，使得关系型数据库中可以适用于一切要求一致性比较高的系统中。比如：银行系统。

但是在网页应用中，对这种一致性的要求不是那么的严格，允许有一定的时间间隔，所以关系型数据库这个特点不是那么的重要了。相反，关系型数据库为了维护一致性所付出的巨大代价就是读写性能比较差。而像微博、facebook这类应用，对于并发读写能力要求极高，关系型数据库已经无法应付。所以必须用一种新的数据结构存储来替代关系型数据库。所以非关系型数据库应用而生

四、非关系型

1.概念

NoSQL非关系型数据库，主要指那些非关系型的、分布式的，且一般不保证ACID的数据存储系统，主要代表MongoDB，Redis、CouchDB。

NoSQL提出了另一种理念，以键值来存储，且结构不稳定，每一个元组都可以有不一样的字段，这种就不会局限于固定的结构，可以减少一些时间和空间的开销。使用这种方式，为了获取用户的不同信息，不需要像关系型数据库中，需要进行多表查询。仅仅需要根据key来取出对应的value值即可。

2.分类

非关系数据库大部分是开源的，实现比较简单，大都是针对一些特性的应用需求出现的。根据结构化方法和应用场景的不同，分为以下几类。

（1）面向高性能并发读写的key-value数据库

主要特点是具有极高的并发读写性能，例如Redis、Tokyo Cabint等。

（2）面向海量数据访问的面向文档数据库

特点是，可以在海量的数据库快速的查询数据。例如MongoDB以及CouchDB.

（3）面向可拓展的分布式数据库

解决的主要问题是传统数据库的扩展性上的缺陷。

3.缺点

但是由于Nosql约束少，所以也不能够像sql那样提供where字段属性的查询。因此适合存储较为简单的数据。有一些不能够持久化数据，所以需要和关系型数据库结合。

五 数据的acid的特性

原子性(Atomicity)
  单个事务，为一个不可分割的最小工作单元，整个事务中的所有操作要么全部commit成功，要么全部失败rollback，对于一个事务来说，不可能只执行其中的一部分SQL操作，这就是事务的原子性。

一致性(Consistency)
  数据库总是从一个一致性的状态转换到另外一个一致性的状态。在前面的例子中， 一致性确保了，即使在执行第三、四条语句之间时系统崩潰，信用卡账户也不会损 失100块，因为事务最终没有提交，所以事务中所做的修改也不会保存到数据库中，保证数据一致性。

隔离性(Isolation)
  通常来说，一个事务所做的修改在最终提交以前，对其他事务是不可见的。在前面 的例子中，当执行完第三条语句、第四条语句还未开始时，此时有另外一个账户查询余额SQL开始运行，则其看到的信用卡账户的余额并没有被减去100元。后面我们讨论隔离级别(Isolation level)的时候，会发现为什么我们要说事务通常来说是不可见的。

持久性(Durability)
  一旦事务提交，则其所做的修改就会永久保存到数据库中。此时即使系统崩溃，修改的数据也不会丢失。

  事务的ACID特性可以确保银行不会弄丢你的钱。而在应用逻辑中，要实现这一点非常难, 甚至可以说是不可能完成的任务。一个兼容ACID的数据库系统，需要做很多复杂但可能用户并没有觉察到的工作，才能确保ACID的实现。
 

六、两种对比

1.存储上？

Sql通常以数据库表的形式存储，例如存储用户信息，SQL中增加外部关系的话，需要在原表中增加一个外键，来关联外部数据表。NoSql采用key-value的形式存储

2.事务

SQL中如果多张表需要同批次被更新，即如果其中一张表跟新失败的话，其他表也不会更新成功。这种场景可以通过事务来控制，可以在所有命令完成之后，再统一提交事务。在Nosql中没有事务这个概念，每一个数据集都是原子级别的。

3.数据表 VS 数据集

关系型是表格型的，存储在数据表的行和列中。彼此关联，容易提取。而非关系型是大块存储在一起。

4.预定义结构 VS 动态结构

在sql中，必须定义好地段和表结构之后，才能够添加数据，例如定义表的主键、索引、外键等。表结构可以在定义之后更新，但是如果有比较大的结构变更，就会变的比较复杂。

在Nosql数据库中，数据可以在任何时候任何地方添加。不需要预先定义。

5.存储规范 VS 存储代码

关系型数据库为了规范性，把数据分配成为最小的逻辑表来存储避免重复，获得精简的空间利用。但是多个表之间的关系限制，多表管理就有点复杂。

当然精简的存储可以节约宝贵的数据存储，但是现在随着社会的发展，磁盘上付出的代价是微不足知道的。

非关系型是平面数据集合中，数据经常可以重复，单个数据库很少被分开，而是存储成为一个整体，这种整块读取数据效率更高。

6.纵向拓展 VS 横向拓展

为了支持更多的并发量，SQL数据采用纵向扩展，提高处理能力，通过提高计算机性能来提高处理能力。

NoSql通过横向拓展，非关系型数据库天然是分布式的，所以可以通过集群来实现负载均衡。

7.其他方面

比如：关系型是结构化查询语言，NoSql是采用更简单而且精确的数据访问方式；SQl数据库大多比较昂贵，而NoSql大多是开源的。

七、选择？

目前许多大型互联网都会选用MySql+NoSql的组合方案，因为SQL和NoSql都有各自的优缺点。

关系型数据库适合存储结构化数据，比如：用户的账号、地址：

（1）这些数据通常需要做结构化查询，比如说Join，这个时候，关系型数据库就要胜出一筹。

（2）这些数据的规模、增长的速度通常是可以预期的。

（3）事务性、一致性,适合存储比较复杂的数据。

NoSql适合存储非结构化数据，比如：文章、评论：

（1）这些数据通常用于模糊处理，例如全文搜索、机器学习，适合存储较为简单的数据。

（2）这些数据是海量的，并且增长的速度是难以预期的。

（3）按照key获取数据效率很高，但是对于join或其他结构化查询的支持就比较差。