高并发系统设计九-NoSQL补充数据库

NoSQL补充数据库

• Redis、LevelDB KV存储，相比传统的数据库优势是极高的读写性能，一般对性能比较高的要求的场合会使用
• Hbase、Cassandra 列式存储数据库。适用于一些离线数据统计的场景
• MongoDB、CouchDB 文档型数据库。Schema Free(模式自由)，数据表中的字段可以任意扩展，比如电商系统中商品有非常多的字段，而且每个字段不同

实际场景中发现，SQL 语句的强大的查询功能以及传统数据库事务和灵活的索引等功能，NoSQL 只能作为一些场景的补充。

1、 提升性能

在性能方面，NoSQL 数据库使用一些算法将对磁盘的随机写转换成顺序写，提升了写的性能

1.1、数据库

数据库系统大多使用的是传统机械磁盘，访问方式有两种：随机IO、顺序IO。随机 IO 需要花费时间做磁盘寻道，读写效率比顺序IO 小两到三个数量级。

以 MySQL 的 InnoDB 存储引擎来说，更新 binlog、redolog、undolog 都是在做顺序 IO，而更新 datafile 和索引文件则是在做随机 IO，而为了减少随机 IO 的发生，关系数据库已经做了很多的优化，比如说写入时先写入内存，然后批量刷新到磁盘上，但是随机 IO 还是会发生。

---

索引在 InnoDB 引擎中是以 B+ 树方式来组织的，而 MySQL 主键是聚簇索引（一种索引类型，数据与索引数据放在一起），既然数据和索引数据放在一起，那么在数据插入或者更新的时候，我们需要找到要插入的位置，再把数据写到特定的位置上，这就产生了随机的 IO。而且一旦发生了页分裂，就不可避免会做数据的移动，也会极大地损耗写入性能。

1.2、NoSQL 如何解决

很多 NoSQL 数据库都在使用的基于 LSM 树的存储引擎

LSM 树（Log-Structured Merge Tree）牺牲了一定的读性能来换取写入数据的高性能，Hbase、Cassandra、LevelDB 都是用这种算法作为存储的引擎

• 数据先写入到 MemTable 的内存结构中，MemTable中数据是按照写入的 Key 来排序的。为了防止 MemTable 数据丢失，会通过 Write Ahead Log 的方式将数据备份在磁盘上。
• MemTable 在累积到一定规模时，它会被刷新生成一个新的文件 SSTable(Sorted String Table)。当 SSTable 达到一定数量时，将 SSTable 合并，减少文件的数量。因为 SSTable 是有序的，所以合并速度也是很快的
• 从 LSM 读取数据时，先从 MemTable中查，如果没有，再从 SSTable中查。因为存储的数据都是有序的，所以查找效率也是很高的，只是因为数据被拆分成多个 SSTable，所以读取的效率会低于 B+ 树索引。

2、 搜索功能

在某些场景下，比如全文搜索功能，关系型数据库并不能高效地支持，需要 NoSQL 数据库的支持

在模糊查询查询中，一旦没有使用索引就会扫描全表的数据，一般会使用开源组件Elasticsearch 来支持搜索的请求，它本身是基于“倒排索引”来实现的。

倒排索引是指将记录中的某些列做分词，然后形成的分词与记录 ID 之间的映射关系

Elasticsearch 作为一种常见的 NoSQL 数据库，就以倒排索引作为核心技术原理，为你提供了分布式的全文搜索服务。

3、提升扩展性

在扩展性方面，NoSQL 数据库天生支持分布式，支持数据冗余和数据分片的特性。

MongoDB 三个扩展性方面的特性

• Replica，也叫做副本集，你可以理解为主从分离，也就是通过将数据拷贝成多份来保证当主挂掉后数据不会丢失。同时呢，Replica 还可以分担读请求。Replica 中有主节点来承担写请求，并且把数据变动记录到 oplog 里（类似于 binlog）；从节点接收到 oplog 后就会修改自身的数据以保持和主节点的一致。一旦主节点挂掉，MongoDB 会从从节点中选取一个节点成为主节点，可以继续提供写数据服务
• Shard，也叫做分片，你可以理解为分库分表，即将数据按照某种规则拆分成多份，存储在不同的机器上。MongoDB 的 Sharding 特性一般需要三个角色来支持，一个是 Shard Server，它是实际存储数据的节点，是一个独立的 Mongod 进程；二是 Config Server，也是一组 Mongod 进程，主要存储一些元信息，比如说哪些分片存储了哪些数据等；最后是 Route Server，它不实际存储数据，仅仅作为路由使用，它从 Config Server 中获取元信息后，将请求路由到正确的 Shard Server 中
• 负载均衡，就是当 MongoDB 发现 Shard 之间数据分布不均匀，会启动 Balancer 进程对数据做重新的分配，最终让不同 Shard Server 的数据可以尽量的均衡。当我们的 Shard Server 存储空间不足需要扩容时，数据会自动被移动到新的 Shard Server 上，减少了数据迁移和验证的成本。