第1章大型互联网公司的基础架构——1.10 其他NoSQL数据库

这里我们简单介绍一下其他常见的NoSQL数据库及其适用的场景，其中部分数据库会在后续服务设计章节中正式使用时再做详细介绍。

1.10.1 文档数据库

文档数据库的典型代表是MongoDB和CouchDB。**文档数据库普遍采用JSON格式来存储数据，而不是采用僵硬的行和列结构，其好处是可以解决关系型数据库表结构（Schema）扩展不方便的问题，以及可以存储和读/写任何格式的数据。**文档数据库与键值存储系统很类似，只不过值存储的内容是文档信息。文档数据库具有很好的可扩展性。

文档数据库适用的场景如下。

1. 数据量大，且数据增长很快的业务场景。
2. 数据字段定义不明确，且字段在不断变化、无法统一的场景。比如商品参数信息存储，电子设备商品参数有内存大小、电池容量等，服装商品参数有尺码、面料等。

文档数据库不适用的场景如下。

1. 需要支持事务，文档数据库无法保证在一个事务中修改多个文档的原子性。
2. 需要支持复杂查询，例如join语句。

1.10.2 列式数据库

列式数据库的典型代表是BigTable、HBase等。关系型数据库按照行来存储数据，所以它也被称为“行式数据库”；而列式数据库按照列来存储数据，如图1-44所示的是一个学生信息数据的例子。

列式数据库将每一列的数据组织在一起，这样做有什么好处呢？假设现在要统计各专业的学生人数：

1. 如果使用行式数据库，那么首先需要将所有行的数据读取到内存，然后对“专业”列进行GroupBy操作得到结果。虽然我们只关注“专业” 一列，但是其他列也参与了数据读取，磁盘I/O次数较多；
2. 而如果使用列式数据库，那么只需要将“专业”列数 据读取到内存，磁盘I/O次数大大减少，提高了查询效率。

列式数据库有很高的存储空间利用率，对于列数据类型是有限枚举（比如性别、专业）的情况，列式数据库可以通过字典表将数据压缩为图1-45所示的形式。

从图1-45中可以看出，性别字典、专业字典分别使用了数字编号来代表原来的字符串，原始数据经过压缩后字符串变为数字，提高了存储空间利用率，且数据量越大，存储空间利用率越高。

列式数据库适用的场景如下。

1. 有海量数据插入，但是数据修改极少的场景，比如用户行为收集。
2. 数据分析场景，比如针对少数几列做离线数据统计工作。

列式数据库不适用的场景如下。

1. 数据高频删除、修改的场景，即不适合直接服务于在线用户。
2. 需要支持事务的场景。

1.10.3 全文搜索数据库

全文搜索数据库的典型代表是Elasticsearch。关系型数据库在应对全文搜索场景时，只能通过LIKE语句进行模糊查询，而LIKE语句会扫描全量数据，效率非常低下。全文搜索数据库的出现就是为了解决关系型数据库不支持高效全文搜索的问题，其基本原理是建立单词到文档的索引关系作为“倒排索引”。

如图1-46所示，倒排索引维护着每个关键词在哪些文档中出现过的文档列表。在进行全文搜索时，根据搜索关键词就可以直接获取到相关文档信息。文档列表既可以保存文档ID，也可以记录关键词在每个文档中出现的频率和位置。

倒排索引非常适合根据关键词查询文档内容，所以在各种搜索场景中得到了广泛应用。其典型的应用场景包括：

1. 关键词搜索，如搜索引擎；
2. 海量数据的复杂查询；
3. 数据统计和数据聚合。

倒排索引不适用的场景包括：

1. 高频更新数据的场景。在全文搜索数据库中，修改数据实际上是删除旧数据和创建新数据两步操作；
2. 需要支持事务的场景。

1.10.4 图数据库

近几年图数据库较为火热，其主要的开源项目有Neo4j、Titan等。图数据库指的并不是存储图片的数据库，而是以“图”这种数据结构存储数据的数据库。

图由两个元素组成：

• 节点：表示一个实体（人、商品等事物）
• 关系：表示两个节点之间的关联关系

对于1.7.1节所举的例子：学生选课系统，如果用图数据库来存储，则会形成图1-47所示的存储结构。

从图1-47中可以看出，图数据库可以很简单且自然地构建出直观的数据模型；同时，我们可以很容易查询任意一个节点与其他节点的关系，解决了关系型数据库不擅长处理实体关系的问题。关系在图数据库中占首要地位，它非常适合强调关系、需要复杂关系查询和分析的业务场景，比如社交网络、知识图谱等。

1.10.5 NewSQL数据库

上述几种NoSQL数据库，虽然分别解决了关系型数据库无法实现高效处理的一些问题，但是也几乎丧失了关系型数据库的强一致性、事务支持等特性。因此，结合关系型数据库及NoSQL数据库两者优点的数据库便产生了，即NewSQL数据库。目前其较为知名的项目包括Google Spanner、TiDB、CockroachDB等。

**NewSQL底层依然采用NoSQL存储数据。**更确切地说，NewSQL使用分布式键值存储系统存储数据，而且在此基础上进行了很多革新，例如：

• 键值存储系统采用LSM Tree模型构建，可以大幅度提升写数据性能；
• 放弃了NoSQL的主从复制模式，而是以更小粒度的数据分片作为高可用单位，主从分片之间通过Paxos或Raft等分布式共识算法进行数据复制；
• 采用分布式事务实现键值存储系统的事务能力。

NewSQL既保留了NoSQL可扩展性强的优势，又在此基础上提供了类似于关系型数据库的事务能力。换言之，NewSQL的本质就是在传统关系型数据库上集成了NoSQL强大的可扩展性。NewSQL的思想很好，它作为数据库领域的后起之秀，正在进入越来越多的应用场景。但是目前NewSQL依然是小众产品，它在高并发、事务性上的表现还需要更多的考验，短期内NewSQL难以完全取代关系型数据库和NoSQL数据库。

总结

什么是文档数据库？

• 文档数据库的典型代表是MongoDB和CouchDB。
• 文档数据库普遍采用JSON格式来存储数据，而不是采用僵硬的行和列结构，其好处是可以解决关系型数据库表结构（Schema）扩展不方便的问题，以及可以存储和读/写任何格式的数据。
• 文档数据库与键值存储系统很类似，只不过值存储的内容是文档信息。
• 文档数据库具有很好的可扩展性。

文档数据库适用的场景？

1. 数据量大，且数据增长很快的业务场景。
2. 数据字段定义不明确，且字段在不断变化、无法统一的场景。比如商品参数信息存储，电子设备商品参数有内存大小、电池容量等，服装商品参数有尺码、面料等。

文档数据库不适用的场景？

1. 需要支持事务，文档数据库无法保证在一个事务中修改多个文档的原子性。
2. 需要支持复杂查询，例如join语句。

列式数据库适用的场景？

1. 有海量数据插入，但是数据修改极少的场景，比如用户行为收集。
2. 数据分析场景，比如针对少数几列做离线数据统计工作。

列式数据库不适用的场景？

1. 数据高频删除、修改的场景，即不适合直接服务于在线用户。
2. 需要支持事务的场景。

为什么会出现全文搜索数据库？

• 全文搜索数据库的出现就是为了解决关系型数据库不支持高效全文搜索的问题，其基本原理是建立单词到文档的索引关系作为“倒排索引”。

什么是倒排索引？

• 倒排索引建立了单词到文档的索引关系，维护着每个关键词在哪些文档中出现过的文档列表。

倒排索引的应用场景？

1. 关键词搜索，如搜索引擎；
2. 海量数据的复杂查询；
3. 数据统计和数据聚合。

倒排索引不适用的场景包括：

1. 高频更新数据的场景。在全文搜索数据库中，修改数据实际上是删除旧数据和创建新数据两步操作；
2. 需要支持事务的场景。

什么是图数据库？

• 图数据库是指以“图”这种数据结构存储数据的数据库。

图数据库的适用场景？

• 它非常适合强调关系、需要复杂关系查询和分析的业务场景，比如社交网络、知识图谱等。

为什么会出现NewSQL数据库？

• NoSQL数据库，虽然解决了关系型数据库无法实现高效处理的一些问题，但是也几乎丧失了关系型数据库的强一致性、事务支持等特性。
• 因此，结合关系型数据库及NoSQL数据库两者优点的数据库便产生了。

什么是NewSQL数据库？

• NewSQL底层依然采用NoSQL存储数据。更确切地说，NewSQL使用分布式键值存储系统存储数据。

NewSQL数据库有哪些革新？

• 键值存储系统采用LSM Tree模型构建，可以大幅度提升写数据性能；
• 放弃了NoSQL的主从复制模式，而是以更小粒度的数据分片作为高可用单位，主从分片之间通过Paxos或Raft等分布式共识算法进行数据复制；
• 采用分布式事务实现键值存储系统的事务能力。