高性能NoSQL

关系数据库已经非常成熟强大的 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 特性给业务开发带来了几个明显的优势。1. 新增字段简单业务上增加新的字段无须再像关系数据库一样要先执行 DDL 语句修改表结构程序代码直接读写即可。2. 历史数据不会出错对于历史数据即使没有新增的字段也不会导致错误只会返回空值此时代码进行兼容处理即可。3. 可以很容易存储复杂数据JSON 是一种强大的描述语言能够描述复杂的数据结构。文档数据库的这个特点特别适合电商和游戏这类的业务场景。文档数据库 no-schema 的特性带来的这些优势也是有代价的最主要的代价就是不支持事务。这是一个事务操作用关系数据库来实现就很简单但如果用 MongoDB 来实现就无法做到事务性。文档数据库另外一个缺点就是无法实现关系数据库的 join 操作。用关系数据库来实现一个简单的 join 操作就搞定了而用文档数据库是无法进行 join 查询的需要查两次列式数据库列式数据库就是按照列来存储数据的数据库与之对应的传统关系数据库被称为“行式数据库”因为关系数据库是按照行来存储数据的。关系数据库按照行式来存储数据主要有以下几个优势业务同时读取多个列时效率高因为这些列都是按行存储在一起的一次磁盘操作就能够把一行数据中的各个列都读取到内存中。能够一次性完成对一行中的多个列的写操作保证了针对行数据写操作的原子性和一致性否则如果采用列存储可能会出现某次写操作有的列成功了有的列失败了导致数据不一致。全文搜索引擎传统的关系型数据库通过索引来达到快速查询的目的但是在全文搜索的业务场景下索引也无能为力主要体现在全文搜索的条件可以随意排列组合如果通过索引来满足则索引的数量会非常多。全文搜索的模糊匹配方式索引无法满足只能用 like 查询而 like 查询是整表扫描效率非常低。1. 全文搜索基本原理全文搜索引擎的技术原理被称为“倒排索引”(Inverted index)也常被称为反向索引、置入档案或反向档案是一种索引方法其基本原理是建立单词到文档的索引。之所以被称为“倒排”索引是和“正排“索引相对的“正排索引”的基本原理是建立文档到单词的索引。我们通过一个简单的样例来说明这两种索引的差异。正排索引适用于根据文档名称来查询文档内容。倒排索引适用于根据关键词来查询文档内容。2. 全文搜索的使用方式全文搜索引擎的索引对象是单词和文档而关系数据库的索引对象是键和行两者的术语差异很大不能简单地等同起来。因此为了让全文搜索引擎支持关系型数据的全文搜索需要做一些转换操作即将关系型数据转换为文档数据。目前常用的转换方式是将关系型数据按照对象的形式转换为 JSON 文档然后将 JSON 文档输入全文搜索引擎进行索引。全文搜索引擎能够基于 JSON 文档建立全文索引然后快速进行全文搜索。上一章: 高性能数据库集群下一章: 单服务器高性能模式归类: 从0开始学架构