高性能NoSQL

笔记

• 关系数据库的缺点：

  1. 关系数据库存储的是行记录，无法存储数据结构。
  2. 关系数据库的 schema 扩展很不方便。修改表结构时会锁表。
  3. 关系数据库在大数据场景下 I/O 较高。如果对一些大量数据的表进行统计之类的运算，关系数据库的 I/O 会很高。
  4. 关系数据库的全文搜索功能比较弱。关系数据库的全文搜索只能使用 like 进行整表扫描匹配，性能非常低。

• NoSQL 方案带来的优势，本质上是牺牲 ACID 中的某个或者某几个特性。将 NoSQL 作为 SQL 的一个有力补充。

• K-V 存储

  1. Redis 是 K-V 存储的典型代表。Redis 的 Value 是具体的数据结构，包括 string、hash、list、set、sorted set、bitmap 和 hyperloglog，所以常常被称为数据结构服务器。
  2. Redis 的缺点主要体现在并不支持完整的 ACID 事务，Redis 的事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）。

• 文档数据库

  1. MongoDB是典型实现。
  2. 文档数据库最大的特点就是 no-schema，可以存储和读取任意的数据。目前绝大部分文档数据库存储的数据格式是 JSON。
  3. 文档数据库的这个特点，特别适合电商和游戏这类的业务场景。
  4. 缺点：
     不支持事务。
     无法实现关系数据库的 join 操作。

• 列式数据库

  1. 列式数据库就是按照列来存储数据的数据库，关系数据库是按照行来存储数据的。
  2. 列式数据库的优点：
     • 只操作几列时，节省IO。
     • 具备更高的存储压缩比，能够节省更多的存储空间。

3. 列式数据库的缺点：
   • 列式存储的随机写效率要远远低于行式存储的写效率。
4. 行式数据库的优点：
   • 业务同时读取多个列时效率高，因为这些列都是按行存储在一起的，一次磁盘操作就能够把一行数据中的各个列都读取到内存中。
   • 能够一次性完成对一行中的多个列的写操作，保证了针对行数据写操作的原子性和一致性；否则如果采用列存储，可能会出现某次写操作，有的列成功了，有的列失败了，导致数据不一致。

• 全文搜索引擎
  1. 传统的关系型数据库通过索引来达到快速查询的目的，但是在全文搜索的业务场景下，索引也无能为力。要满足各种查询条件的组合，需要创建太多索引。
  2. 全文搜索引擎的技术原理被称为“倒排索引”（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，其基本原理是建立单词到文档的索引。“正排索引”的基本原理是建立文档到单词的索引。
  3. 全文搜索引擎的索引对象是单词和文档。

理解与思考

1. NOSQL又是一个内容较多的技术簇。
2. 没有最好，只有最适合。每种业务场景都有适合的技术。
3. 针对业务场景选取合适的技术。这对技术和经验要求都很高。唯有勤学苦练才能应对一二。

课后思考题

有人认为 NoSQL = No SQL，架构设计的时候无需再使用关系数据库，对此你怎么看？
要看业务场景，NoSQL和关系数据库都有自己的适用场景。如果业务对ACID要求较严格，则必须使用关系数据库，其他场景可以酌情适用对应的NOSQL技术。