关系数据库已经非常成熟，强大的 SQL 功能和 ACID 的属性，使得关系数据库广泛应用于各式各样的系统中，但这并不意味着关系数据库是完美的，关系数据库存在如下缺点。
关系数据库存储的是行记录，无法存储数据结构
关系数据库的 schema 扩展很不方便 关系数据库的表结构 schema 是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，需要执行 DDL(data definition language，如 CREATE、ALTER、DROP 等)语句修改，而且修改时可能会长时间锁表(例如，MySQL 可能将表锁住 1 个小时)。
关系数据库在大数据场景下 I/O 较高 如果对一些大量数据的表进行统计之类的运算，关系数据库的 I/O 会很高，因为即使只针对其中某一列进行运算，关系数据库也会将整行数据从存储设备读入内存。
关系数据库的全文搜索功能比较弱 关系数据库的全文搜索只能使用 like 进行整表扫描匹配，性能非常低，在互联网这种搜索复杂的场景下无法满足业务要求。
针对上述问题，分别诞生了不同的 NoSQL 解决方案，这些方案与关系数据库相比，在某些应用场景下表现更好。但NoSQL 方案带来的优势，本质上是牺牲 ACID 中的某个或者某几个特性，因此我们不能盲目地迷信 NoSQL ，而应该将 NoSQL 作为 SQL 的一个有力补充，NoSQL != No SQL，而是 NoSQL = Not Only SQL。
常见的 NoSQL 方案分为 4 类。
K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。
文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。
列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。
全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表
K-V 存储
K-V 存储的全称是 Key-Value 存储，其中 Key 是数据的标识，和关系数据库中的主键含义一样，Value 就是具体的数据。
Redis 是 K-V 存储的典型代表，它是一款开源(基于 BSD 许可)的高性能 K-V 缓存和存储系统。Redis 的 Value 是具体的数据结构，包括 string、hash、list、set、sorted set、 bitmap 和 hyperloglog，所以常常被称为数据结构服务器。
以 List 数据结构为例，Redis 提供了下面这些典型的操作
LPOP key 从队列的左边出队一个元素。
LINDEX key index 获取一个元素，通过其索引列表。
LLEN key 获得队列(List)的长度。
RPOP key 从队列的右边出队一个元素。
以上这些功能，如果用关系数据库来实现，就会变得很复杂。例如，LPOP 操作是移除并返回 key 对应的 list 的第一个元素。如果用关系数据库来存储，为了达到同样目的，需要进行下面的操作：
每条数据除了数据编号(例如，行 ID)，还要有位置编号，否则没有办法判断哪条数据是第一条。注意这里不能用行 ID 作为位置编号，因为我们会往列表头部插入数据。
查询出第一条数据。
删除第一条数据。
更新从第二条开始的所有数据的位置编号。
可以看出关系数据库的实现很麻烦，而且需要进行多次 SQL 操作，性能很低。
Redis 的缺点主要体现在并不支持完整的 ACID 事务，Redis 虽然提供事务功能，但 Redis 的事务和关系数据库的事务不可同日而语，Redis 的事务只能保证隔离性和一致性(I 和 C)，无法保证原子性和持久性(A 和 D)。
虽然 Redis 并没有严格遵循 ACID 原则，但实际上大部分业务也不需要严格遵循 ACID 原则。以上面的微博关注操作为例，即使系统没有将 A 加入 B 的粉丝列表，其实业务影响也非常小，因此我们在设计方案时，需要根据业务特性和要求来确定是否可以用 Redis，而不能因为 Redis 不遵循 ACID 原则就直接放弃。
文档数据库
为了解决关系数据库 schema 带来的问题，文档数据库应运而生。文档数据库最大的特点就是 no-schema，可以存储和读取任意的数据。目前绝大部分文档数据库存储的数据格式是 JSON(或者 BSON)，因为 JSON 数据是自描述的，无须在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误。
文档数据库的 no-schema 特性，给业务开发带来了几个明显的优势。
-
新增字段简单业务上增加新的字段，无须再像关系数据库一样要先执行 DDL 语句修改表结构，程序代码直接读写即可。
-
历史数据不会出错对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码进行兼容处理即可。
-
可以很容易存储复杂数据JSON 是一种强大的描述语言，能够描述复杂的数据结构。
文档数据库的这个特点，特别适合电商和游戏这类的业务场景。文档数据库 no-schema 的特性带来的这些优势也是有代价的，最主要的代价就是不支持事务。这是一个事务操作，用关系数据库来实现就很简单，但如果用 MongoDB 来实现，就无法做到事务性。
文档数据库另外一个缺点就是无法实现关系数据库的 join 操作。用关系数据库来实现，一个简单的 join 操作就搞定了；而用文档数据库是无法进行 join 查询的，需要查两次
列式数据库
列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为"行式数据库"，因为关系数据库是按照行来存储数据的。
关系数据库按照行式来存储数据，主要有以下几个优势：
业务同时读取多个列时效率高，因为这些列都是按行存储在一起的，一次磁盘操作就能够把一行数据中的各个列都读取到内存中。能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的原子性和一致性；否则如果采用列存储，可能会出现某次写操作，有的列成功了，有的列失败了，导致数据不一致。
全文搜索引擎
传统的关系型数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力，主要体现在：
全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量会非常多。
全文搜索的模糊匹配方式，索引无法满足，只能用 like 查询，而 like 查询是整表扫描，效率非常低。
- 全文搜索基本原理
全文搜索引擎的技术原理被称为"倒排索引"(Inverted index)，也常被称为反向索引、置入档案或反向档案，是一种索引方法，其基本原理是建立单词到文档的索引。之所以被称为"倒排"索引，是和"正排"索引相对的，"正排索引"的基本原理是建立文档到单词的索引。我们通过一个简单的样例来说明这两种索引的差异。
正排索引适用于根据文档名称来查询文档内容。
倒排索引适用于根据关键词来查询文档内容。
- 全文搜索的使用方式
全文搜索引擎的索引对象是单词和文档，而关系数据库的索引对象是键和行，两者的术语差异很大，不能简单地等同起来。因此，为了让全文搜索引擎支持关系型数据的全文搜索，需要做一些转换操作，即将关系型数据转换为文档数据。
目前常用的转换方式是将关系型数据按照对象的形式转换为 JSON 文档，然后将 JSON 文档输入全文搜索引擎进行索引。
全文搜索引擎能够基于 JSON 文档建立全文索引，然后快速进行全文搜索。
上一章: 高性能数据库集群
下一章: 单服务器高性能模式
归类: 从0开始学架构