文章目录
-
- K-V 存储
- 文档数据库
- 列式数据库
- 全文搜索引擎
- 小结
关系数据库经过几十年的发展后已经非常成熟，强大的 SQL 功能和 ACID 的属性，使得关系数据库广泛应用于各式各样的系统中，但这并不意味着关系数据库是完美的，关系数据库存在如下缺点。
- 关系数据库存储的是行记录，无法存储数据结构
以微博的关注关系为例，“我关注的人”是一个用户 ID 列表，使用关系数据库存储只能将列表拆成多行，然后再查询出来组装，无法直接存储一个列表。
- 关系数据库的 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 为代表。
今天，我们讨论一下各种高性能 NoSQL 方案的典型特征和应用场景。
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 提供了下面这些典型的操作（更多请参考链接：http://redis.cn/commands.html#list）：
- LPOP key 从队列的左边出队一个元素。
- LINDEX key index 获取一个元素，通过其索引列表。
- LLEN key 获得队列（List）的长度。
- RPOP key 从队列的右边出队一个元素。
以上这些功能，如果用关系数据库来实现，就会变得很复杂。例如，LPOP 操作是移除并返回 key 对应的 list 的第一个元素。如果用关系数据库来存储，为了达到同样目的&
