关系型数据库 VS NOSQL

转载：https://mp.weixin.qq.com/s/FkoOMY8_vnqSPPTHc2PL1w

行式数据库(关系型数据库)

行式数据库有如下几个缺点：

• 大数据场景下 I/O 较高，因为数据是按行存储，即使只针对其中某一列进行运算，关系型数据库也会将整行数据从存储设备中读入内存，导致 I/O 较高。

• 存储的是行记录，无法存储数据结构。

• 表结构 Schema 扩展不方便，如要修改表结构，需要执行 DDL(data definition language)，语句修改，修改期间会导致锁表，部分服务不可用。

• 全文搜索功能较弱，关系型数据库下只能够进行子字符串的匹配查询，当表的数据逐渐变大的时候，like 查询的匹配会非常慢，即使在有索引的情况下。况且关系型数据库也不应该对文本字段进行索引。

• 存储和处理复杂关系型数据功能较弱，许多应用程序需要了解和导航高度连接数据之间的关系，才能启用社交应用程序、推荐引擎、欺诈检测、知识图谱、生命科学和 IT/网络等用例。

  然而传统的关系数据库并不善于处理数据点之间的关系。它们的表格数据模型和严格的模式使它们很难添加新的或不同种类的关联信息。

NoSQL，泛指非关系型的数据库，可以理解为 SQL 的一个有力补充。在 NoSQL 许多方面性能大大优于非关系型数据库的同时，往往也伴随一些特性的缺失，比较常见的是事务库事务功能的缺失。

列式数据库(NoSQL)

列式数据库是以列相关存储架构进行数据存储的数据库，主要适合于批量数据处理和即时查询。基于列式数据库的列存储特性，可以解决某些特定场景下关系型数据库 I/O 较高的问题。

常见列式数据库

HBase：是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的 BigTable 建模，实现的编程语言为 Java。

BigTable：是一种压缩的、高性能的、高可扩展性的，基于 Google 文件系统（Google File System，GFS）的数据存储系统，用于存储大规模结构化数据，适用于云端计算。

相关特性

高效的储存空间利用率：列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率。 比较常见的，通过字典表压缩数据： 下面图中才是那张表本来的样子。经过字典表进行数据压缩后，表中的字符串才都变成数字了。

查询效率高：读取多条数据的同一列效率高，因为这些列都是存储在一起的，一次磁盘操作可以把数据的指定列全部读取到内存中。

缺点如下：

• 不适合扫描小量数据。

• 不适合随机的更新。

• 不适合做含有删除和更新的实时操作。

• 单行的数据是 ACID 的，多行的事务时，不支持事务的正常回滚，支持 I(Isolation)隔离性(事务串行提交)，D(Durability)持久性，不能保证 A(Atomicity)原子性， C(Consistency)一致性。

使用场景

以 HBase 为例说明：

• 大数据量（100s TB级数据），且有快速随机访问的需求。

• 写密集型应用，每天写入量巨大，而相对读数量较小的应用，比如 IM 的历史消息，游戏的日志等等。

• 不需要复杂查询条件来查询数据的应用，HBase 只支持基于 rowkey 的查询，对于 HBase 来说，单条记录或者小范围的查询是可以接受的。

  大范围的查询由于分布式的原因，可能在性能上有点影响，HBase 不适用于有 join，多级索引，表关系复杂的数据模型。

• 对性能和可靠性要求非常高的应用，由于 HBase 本身没有单点故障，可用性非常高。

• 数据量较大，而且增长量无法预估的应用，需要进行优雅的数据扩展的 HBase 支持在线扩展，即使在一段时间内数据量呈井喷式增长，也可以通过 HBase 横向扩展来满足功能。

• 存储结构化和半结构化的数据。

K-V 数据库(NoSQL)

指的是使用键值(key-value)存储的数据库，其数据按照键值对的形式进行组织、索引和存储。K-V 存储非常适合不涉及过多数据关系业务关系的数据，同时能有效减少读写磁盘的次数，比 SQL 数据库存储拥有更好的读写性能，能够解决关系型数据库无法存储数据结构的问题。

常见 K-V 数据库

Redis：是一个使用 ANSI C 编写的开源、支持网络、基于内存、可选持久性的键值对存储数据库。

Cassandra：Apache Cassandra（社区内一般简称为C*）是一套开源分布式 NoSQL 数据库系统。

LevelDB：是一个由 Google 公司所研发的键／值对（Key/Value Pair）嵌入式数据库管理系统编程库， 以开源的 BSD 许可证发布。

相关特性

以 Redis 为例，K-V 数据库优点如下：

• 性能极高：Redis 能支持超过 10W 的 TPS。

• 丰富的数据类型：Redis 支持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperloglog。

• 丰富的特性：Redis 还支持 publish/subscribe，通知，key 过期等等特性。

缺点如下：

• 针对 ACID，Redis 事务不能支持原子性和持久性(A 和 D)，只支持隔离性和一致性(I 和 C) 。

特别说明一下，这里所说的无法保证原子性，是针对 Redis 的事务操作，因为事务是不支持回滚（roll back），而因为 Redis 的单线程模型，Redis 的普通操作是原子性的。

使用场景

适用场景：

• 储存用户信息(比如会话)、配置文件、参数、购物车等等。这些信息一般都和 ID（键）挂钩。

不适用场景：

• 需要通过值来查询，而不是键来查询。Key-Value 数据库中根本没有通过值查询的途径。

• 需要储存数据之间的关系。在 Key-Value 数据库中不能通过两个或以上的键来关联数据。

• 需要事务的支持。在 Key-Value 数据库中故障产生时不可以进行回滚。

文档数据库(NoSQL)

文档数据库（也称为文档型数据库）是旨在将半结构化数据存储为文档的一种数据库。文档数据库通常以 JSON 或 XML 格式存储数据。由于文档数据库的 no-schema 特性，可以存储和读取任意数据。由于使用的数据格式是 JSON 或者 BSON，因为 JSON 数据是自描述的，无需在使用前定义字段，读取一个 JSON 中不存在的字段也不会导致 SQL 那样的语法错误，可以解决关系型数据库表结构 Schema 扩展不方便的问题。

常见文档数据库

MongoDB：是一种面向文档的数据库管理系统，由 C++ 撰写而成，以此来解决应用程序开发社区中的大量现实问题。

CouchDB：Apache CouchDB 是一个开源数据库，专注于易用性和成为"完全拥抱 Web 的数据库"。它是一个使用 JSON 作为存储格式，JavaScript 作为查询语言，MapReduce 和 HTTP 作为 API 的 NoSQL 数据库。其中一个显著的功能就是多主复制。

相关特性

以 MongoDB 为例进行说明，文档数据库优点如下：

• 新增字段简单，无需像关系型数据库一样先执行 DDL 语句修改表结构，程序代码直接读写即可。

• 容易兼容历史数据，对于历史数据，即使没有新增的字段，也不会导致错误，只会返回空值，此时代码兼容处理即可。

• 容易存储复杂数据，JSON 是一种强大的描述语言，能够描述复杂的数据结构。

相比传统关系型数据库，文档数据库的缺点主要是对多条数据记录的事务支持较弱，具体体现如下：

• Atomicity(原子性)，仅支持单行/文档级原子性，不支持多行、多文档、多语句原子性。

• Solation(隔离性)，隔离级别仅支持已提交读（Read committed）级别，可能导致不可重复读，幻读的问题。

• 不支持复杂查询，例如 join 查询，如果需要 join 查询，需要多次操作数据库。

使用场景

适用场景：

• 数据量很大或者未来会变得很大。

• 表结构不明确，且字段在不断增加，例如内容管理系统，信息管理系统。

不适用场景：

• 在不同的文档上需要添加事务。Document-Oriented 数据库并不支持文档间的事务。

• 多个文档之间需要复杂查询，例如 join。

全文搜索引擎(NoSQL)

传统关系型数据库主要通过索引来达到快速查询的目的，在全文搜索的业务下，索引也无能为力，主要体现在：

• 全文搜索的条件可以随意排列组合，如果通过索引来满足，则索引的数量非常多。

• 全文搜索的模糊匹配方式，索引无法满足，只能用 like 查询，而 like 查询是整表扫描，效率非常低。

而全文搜索引擎的出现，正是解决关系型数据库全文搜索功能较弱的问题。

常见全文搜索引擎

Elasticsearch：是一个基于 Lucene 的搜索引擎。它提供了一个分布式，多租户，能够全文搜索与发动机 HTTP Web 界面和无架构 JSON 文件。

Solr：是 Apache Lucene 项目的开源企业搜索平台。其主要功能包括全文检索、命中标示、分面搜索、动态聚类、数据库集成，以及富文本（如 Word、PDF）的处理。Solr 是高度可扩展的，并提供了分布式搜索和索引复制。

相关特性

以 Elasticsearch 为例，全文搜索引擎优点如下：

• 查询效率高，对海量数据进行近实时的处理。

• 可扩展性，基于集群环境可以方便横向扩展，可以承载 PB 级数据。

• 高可用，Elasticsearch 集群弹性，他们将发现新的或失败的节点，重组和重新平衡数据，确保数据是安全的和可访问的。

缺点如下：

• ACID 支持不足，单一文档的数据是 ACID 的，包含多个文档的事务时不支持事务的正常回滚，支持 I(Isolation)隔离性（基于乐观锁机制的），D(Durability)持久性，不支持 A(Atomicity)原子性，C(Consistency)一致性。

• 对类似数据库中通过外键的复杂的多表关联操作支持较弱。

• 读写有一定延时，写入的数据，最快 1s 中能被检索到。

• 更新性能较低，底层实现是先删数据，再插入新数据。

• 内存占用大，因为 Lucene 将索引部分加载到内存中。

使用场景

适用场景如下：

• 分布式的搜索引擎和数据分析引擎。

• 全文检索，结构化检索，数据分析。

• 对海量数据进行近实时的处理，可以将海量数据分散到多台服务器上去存储和检索。

不适用场景如下：

• 数据需要频繁更新。

• 需要复杂关联查询。

图形数据库 (NoSQL)

图形数据库应用图形理论存储实体之间的关系信息。最常见例子就是社会网络中人与人之间的关系。

关系型数据库用于存储“关系型”数据的效果并不好，其查询复杂、缓慢、超出预期。

而图形数据库的独特设计恰恰弥补了这个缺陷，解决关系型数据库存储和处理复杂关系型数据功能较弱的问题。

常见图形数据库

Neo4j：是由 Neo4j，Inc. 开发的图形数据库管理系统。由其开发人员描述为具有原生图存储和处理的符合 ACID 的事务数据库，根据 DB-Engines 排名，Neo4j 是最流行的图形数据库。

ArangoDB：是由 triAGENS GmbH 开发的原生多模型数据库系统。数据库系统支持三个重要的数据模型（键/值，文档，图形），其中包含一个数据库核心和统一查询语言 AQL（ArangoDB 查询语言）。查询语言是声明性的，允许在单个查询中组合不同的数据访问模式。ArangoDB 是一个 NoSQL 数据库系统，但 AQL 在很多方面与 SQL 类似。

Titan：是一个可扩展的图形数据库，针对存储和查询包含分布在多机群集中的数百亿个顶点和边缘的图形进行了优化。Titan 是一个事务性数据库，可以支持数千个并发用户实时执行复杂的图形遍历。

相关特性

以 Neo4j 为例，Neo4j 使用数据结构中图（graph）的概念来进行建模。Neo4j 中两个最基本的概念是节点和边。

节点表示实体，边则表示实体之间的关系。节点和边都可以有自己的属性。不同实体通过各种不同的关系关联起来，形成复杂的对象图。

优点如下：

• 高性能表现，图的遍历是图数据结构所具有的独特算法，即从一个节点开始，根据其连接的关系，可以快速和方便地找出它的邻近节点。

  这种查找数据的方法并不受数据量的大小所影响，因为邻近查询始终查找的是有限的局部数据，不会对整个数据库进行搜索。

• 设计的灵活性，数据结构的自然伸展特性及其非结构化的数据格式，让图数据库设计可以具有很大的伸缩性和灵活性。

  因为随着需求的变化而增加的节点、关系及其属性并不会影响到原来数据的正常使用。

• 开发的敏捷性，直观明了的数据模型，从需求的讨论开始，到程序开发和实现，以及最终保存在数据库中的样子，它的模样似乎没有什么变化，甚至可以说本来就是一模一样的。

• 完全支持 ACID，不像别的 NoSQL 数据库，Neo4j 还具有完全事务管理特性，完全支持 ACID 事务管理。

缺点如下：

• 具有支持节点，关系和属性的数量的限制。

• 不支持拆分。

使用场景

适用场景如下：

• 在一些关系性强的数据中，例如社交网络。

• 推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定。

不适用场景如下：

• 记录大量基于事件的数据（例如日志条目或传感器数据）。

• 对大规模分布式数据进行处理，类似于 Hadoop。

• 适合于保存在关系型数据库中的结构化数据。

• 二进制数据存储。

总结

选型指标

关系型数据库和 NoSQL 数据库的选型，往往需要考虑几个指标：

• 数据量

• 并发量

• 实时性

• 一致性要求

• 读写分布和类型

• 安全性

• 运维成本

选型实例

常见软件系统数据库选型参考如下：

• 内部使用的管理型系统，如运营系统，数据量少，并发量小，首选考虑关系型。

• 大流量系统，如电商单品页，后台考虑选关系型，前台考虑选内存型。

• 日志型系统，原始数据考虑选列式，日志搜索考虑选倒排索引。

• 搜索型系统，例如站内搜索，非通用搜索，如商品搜索，后台考虑选关系型，前台考虑选倒排索引。

• 事务型系统，如库存，交易，记账，考虑选关系型+缓存+一致性协议。

• 离线计算，如大量数据分析，考虑选列式或者关系型也可以。

• 实时计算，如实时监控，可以考虑选内存型或者列式数据库。

在设计实践中，我们要基于需求、业务驱动架构，无论选用 R(elation)DB/NoSQL，一定是以需求为导向，最终数据存储方案必然是各种权衡的综合性设计。