NoSQL 数据库权威指南

已发表: 2022-03-11

毫无疑问,Web 应用程序处理数据的方式在过去十年中发生了显着变化。 正在收集更多的数据,并且有更多的用户同时访问这些数据。 这意味着对于基于模式的关系数据库而言,可伸缩性和性能比以往任何时候都更具挑战,因此更难扩展。

NoSQL 的演变

SQL 可扩展性问题已被具有庞大且不断增长的数据和基础设施需求的 Web 2.0 公司所认识到,例如 Google、Amazon 和 Facebook。 他们提出了自己的解决方案——BigTable、DynamoDB 和 Cassandra 等技术。

这种日益增长的兴趣导致了许多 NoSQL 数据库管理系统 (DBMS),重点关注性能、可靠性和一致性。 为了提高搜索和读取性能,许多现有的索引结构被重用和改进。

首先,有大公司为满足其特定需求而开发的专有(闭源)类型的 NoSQL 数据库,例如被认为是第一个 NoSQL 系统的 Google 的 BigTable 和 Amazon 的 DynamoDB。

这些专有系统的成功引发了许多类似的开源和专有数据库系统的开发,其中最流行的是 Hypertable、Cassandra、MongoDB、DynamoDB、HBase 和 Redis。

是什么让 NoSQL 与众不同?

NoSQL 数据库和传统关系数据库之间的一个关键区别在于 NoSQL 是一种非结构化存储形式。

这意味着 NoSQL 数据库不像关系数据库中那样具有固定的表结构。

NoSQL 数据库的优缺点

优点

与传统的关系数据库相比,NoSQL 数据库具有许多优势。

一个主要的潜在区别是 NoSQL 数据库具有简单而灵活的结构。 它们是无模式的。

与关系数据库不同,NoSQL 数据库基于键值对。

NoSQL 数据库的一些存储类型包括列存储、文档存储、键值存储、图形存储、对象存储、XML 存储和其他数据存储模式。

通常,数据库中的每个值都有一个键。 一些 NoSQL 数据库存储还允许开发人员将序列化对象存储到数据库中,而不仅仅是简单的字符串值。

开源 NoSQL 数据库不需要昂贵的许可费用,并且可以在廉价的硬件上运行,从而使其部署具有成本效益。

此外,在使用 NoSQL 数据库时,无论它们是开源的还是专有的,扩展都比使用关系数据库时更容易且更便宜。 这是因为它是通过水平扩展并将负载分布在所有节点上来完成的,而不是通常使用关系数据库系统完成的垂直扩展类型,后者正在用更强大的主机取代主主机。

缺点

当然,NoSQL 数据库并不完美,它们并不总是正确的选择。

一方面,大多数 NoSQL 数据库不支持关系数据库系统本机支持的可靠性特性。 这些可靠性特征可以概括为原子性、一致性、隔离性和持久性。 这也意味着不支持这些功能的 NoSQL 数据库会以一致性换取性能和可扩展性。

为了支持可靠性和一致性特性,开发人员必须实现自己的专有代码,这增加了系统的复杂性。

这可能会限制可以依赖 NoSQL 数据库进行安全可靠交易的应用程序的数量,例如银行系统。

在大多数 NoSQL 数据库中发现的其他形式的复杂性包括与 SQL 查询的不兼容。 这意味着需要手动或专有查询语言,从而增加更多时间和复杂性。

NoSQL 与关系数据库

下表提供了 NoSQL 和关系数据库之间的简要功能比较:

特征NoSQL 数据库关系数据库
表现高的低的
可靠性较差的好的
可用性好的好的
一致性较差的好的
数据存储针对海量数据进行了优化中型到大型
可扩展性高的高(但更贵)


应该注意的是,该表显示了数据库级别的比较,而不是实现这两种模型的各种数据库管理系统。 这些系统提供了他们自己的专有技术来克服这两个系统中的一些问题和缺点,并且在某些情况下,显着提高了性能和可靠性。

NoSQL 数据存储类型

键值存储

在键值存储类型中,使用了一个哈希表,其中唯一的键指向一个项目。

键可以组织成键的逻辑组,只要求键在它们自己的组中是唯一的。 这允许不同逻辑组中的相同键。 下表显示了一个键值存储的示例,其中键是城市的名称,值是阿尔斯特大学在该城市的地址。

钥匙价值
《贝尔法斯特》 {“阿尔斯特大学,贝尔法斯特校区,约克街,贝尔法斯特,BT15 1ED”}
“科尔雷恩” {“阿尔斯特大学,科尔雷恩校区,克罗莫路,伦敦德里有限公司,BT52 1SA”}


键值存储的一些实现提供了缓存机制,这大大提高了它们的性能。

处理存储在数据库中的项目所需的一切都是关键。 数据以字符串、JSON 或 BLOB(二进制大对象)的形式存储。

这种数据库形式的最大缺陷之一是数据库级别缺乏一致性。 这可以由开发人员使用他们自己的代码添加,但如前所述,这会增加更多的工作量、复杂性和时间。

最著名的基于键值存储的 NoSQL 数据库是 Amazon 的 DynamoDB。

文档存储

文档存储类似于键值存储,因为它们是无模式的并且基于键值模型。 因此,两者都有许多相同的优点和缺点。 两者都缺乏数据库级别的一致性,这为应用程序提供更多的可靠性和一致性功能铺平了道路。

但是,两者之间存在关键差异。

在文档存储中,值(文档)为存储的数据提供编码。 这些编码可以是 XML、JSON 或 BSON(二进制编码的 JSON)。

此外,还可以进行基于数据的查询。

最流行的依赖文档存储的数据库应用程序是 MongoDB。

列商店

在列存储数据库中,数据存储在列中,而不是像大多数关系数据库管理系统那样存储在行中。

列存储由一个或多个列族组成,这些列族在逻辑上对数据库中的某些列进行分组。 键用于标识和指向数据库中的许多列,键空间属性定义了该键的范围。 每列包含名称和值的元组,按顺序排列并以逗号分隔。

列存储对存储的数据具有快速读/写访问权限。 在列存储中,对应于单个列的行存储为单个磁盘条目。 这使得在读/写操作期间可以更快地访问。

使用列存储的最流行的数据库包括 Google 的 BigTable、HBase 和 Cassandra。

图基

在 Graph Base NoSQL 数据库中,使用有向图结构来表示数据。 该图由边和节点组成。

形式上,图是一组对象的表示,其中一些对象对通过链接连接。 互连的对象由数学抽象表示,称为顶点,连接一些顶点对的链接称为边。 一组顶点和连接它们的边被称为图。

关于图表的图表。顶部中心是一个称为“图形”的框,其中有两个箭头。两个箭头都称为“记录”;一个指向“节点”框,另一个指向“关系”框。 “关系”框有一个指向“节点”框的“组织”箭头。 “节点”和“关系”都有称为“有”的箭头,指向最后一个框“属性”。换句话说,图记录了关系和节点,它们都具有属性,并且关系组织节点。

这说明了使用边和节点来表示和存储数据的图基础数据库的结构。 这些节点是通过相互之间的某种关系组织起来的,这些关系由节点之间的边表示。 节点和关系都有一些定义的属性。

图数据库最常用于社交网络应用程序。 图数据库允许开发人员更多地关注对象之间的关系,而不是对象本身。 在这种情况下,它们确实允许可扩展且易于使用的环境。

目前,InfoGrid 和 InfiniteGraph 是最流行的图数据库。

NoSQL 数据库管理系统

对于数据库的简要比较,下表提供了不同 NoSQL 数据库管理系统之间的简要比较。

存储类型查询方法界面编程语言开源复制
卡桑德拉列商店节俭的 API 节约爪哇是的异步
MongoDB 文档存储蒙戈查询TCP/IP C++ 是的异步
超表列商店高品质节约爪哇是的异步
沙发数据库文档存储MapReduce 休息二郎是的异步
大表列商店MapReduce TCP/IP C++异步
HBase 列商店MapReduce 休息爪哇是的异步


MongoDB 具有灵活的模式存储,这意味着存储的对象不一定需要具有相同的结构或字段。 MongoDB 还具有一些优化功能,可以分散数据集合,从而提高整体性能和更平衡的系统。

其他 NoSQL 数据库系统,例如 Apache CouchDB,也是文档存储类型的数据库,并且与 MongoDB 共享许多功能,但可以使用 RESTful API 访问数据库。

REST 是一种架构风格,由一组协调的架构约束组成,这些约束应用于万维网中的组件、连接器和数据元素。 它依赖于无状态、客户端-服务器、可缓存的通信协议(例如,HTTP 协议)。

RESTful 应用程序使用 HTTP 请求来发布、读取数据和删除数据。

对于基于列的数据库,Hypertable 是用 C++ 编写的 NoSQL 数据库,基于 Google 的 BigTable。

Hypertable 支持跨节点分布数据存储以最大化可扩展性,就像 MongoDB 和 CouchDB 一样。

使用最广泛的 NoSQL 数据库之一是 Facebook 开发的 Cassandra。

Cassandra 是一个列存储数据库,包含许多旨在提高可靠性和容错性的功能。

Cassandra 和 MongoDB 这两个最广泛使用的 NoSQL 数据库管理系统将在接下来的小节中进行探讨,而不是深入了解每个 NoSQL DBMS。

卡桑德拉

Cassandra 是 Facebook 开发的数据库管理系统。

Cassandra 背后的目标是创建一个没有单点故障并提供最大可用性的 DBMS。

Cassandra 主要是一个列存储数据库。 一些研究将 Cassandra 称为混合系统,其灵感来自 Google 的 BigTable(列存储数据库)和 Amazon 的 DynamoDB(键值对数据库)。

这是通过提供键值系统来实现的,但 Cassandra 中的键指向一组列族,依赖于 Google 的 BigTable 分布式文件系统和 Dynamo 的可用性特性(分布式哈希表)。

Cassandra 旨在存储分布在不同节点上的大量数据。 Cassandra 是一种 DBMS,旨在处理分布在许多服务器上的海量数据,同时提供无单点故障的高可用性服务,这对于 Facebook 这样的大型服务至关重要。

Cassandra 的主要特点包括:

  • 没有单点故障。 要实现这一点,Cassandra 必须在节点集群上运行,而不是在单台机器上运行。 这并不意味着每个集群上的数据都是一样的,但管理软件是一样的。 当其中一个节点发生故障时,该节点上的数据将无法访问。 但是,其他节点(和数据)仍然可以访问。
  • 分布式哈希是一种提供哈希表功能的方案,其方式是添加或删除一个槽不会显着改变键到槽的映射。 这提供了根据容量将负载分配到服务器或节点的能力,进而最大限度地减少停机时间。
  • 客户端界面比较好用。 Cassandra 使用 Apache Thrift 作为其客户端界面。 Apache Thrift 提供了一个跨语言的 RPC 客户端,但大多数开发人员更喜欢构建在 Apple Thrift 之上的开源替代品,例如 Hector。
  • 其他可用性功能。 Cassandra 的功能之一是数据复制。 基本上,它将数据镜像到集群中的其他节点。 例如,复制可以是随机的,也可以是特定的,以通过放置在不同数据中心的节点中来最大限度地保护数据。 Cassandra 中的另一个特性是分区策略。 分区策略决定将密钥放置在哪个节点上。 这也可以是随机的或有序的。 当使用这两种类型的分区策略时,Cassandra 可以在负载平衡和查询性能优化之间取得平衡。
  • 一致性。 复制等功能使一致性具有挑战性。 这是因为所有节点必须在任何时间点以最新值或在触发读取操作时保持最新。 但最终,Cassandra 试图通过向开发人员提供这种可定制性来保持复制操作和读/写操作之间的平衡。
  • 读/写操作。 客户端向单个 Cassandra 节点发送请求。 节点根据复制策略将数据存储到集群中。 每个节点首先在提交日志中执行数据更改,然后随着更改更新表结构,两者都是同步完成的。 读取操作也非常相似,读取请求被发送到单个节点,该单个节点根据分区/放置策略确定哪个节点保存数据。

MongoDB

MongoDB 是一个用 C++ 编写的无模式、面向文档的数据库。 数据库是基于文档存储的,这意味着它以编码数据的形式存储值(称为文档)。

MongoDB 中编码格式的选择是 JSON。 这很强大,因为即使数据嵌套在 JSON 文档中,它仍然是可查询可索引的。

以下小节描述了 MongoDB 中可用的一些关键特性。

碎片

分片是跨多台机器(节点)对数据进行分区和分布。 分片是 MongoDB 节点的集合,而 Cassandra 的节点是对称分布的。 使用分片还意味着能够跨多个节点进行水平扩展。 如果有一个应用程序使用单个数据库服务器,它可以转换为分片集群,只需对原始应用程序代码进行很少的更改,因为分片的方式是由 MongoDB 完成的。 经常软件几乎完全与暴露给客户端的公共 API 解耦。

Mongo 查询语言

如前所述,MongoDB 使用 RESTful API。 要从 db 集合中检索某些文档,需要创建一个查询文档,其中包含所需文档应匹配的字段。

行动

在 MongoDB 中,有一组称为路由器的服务器。 每个都充当一个或多个客户端的服务器。 同样,集群包含一组称为配置服务器的服务器。 每个人都拥有一份元数据副本,指示哪个分片包含哪些数据。 读取或写入操作从客户端发送到集群中的一个路由器服务器,并由该服务器在配置服务器的帮助下自动路由到包含数据的适当分片。

与 Cassandra 类似,MongoDB 中的分片具有数据复制方案,该方案为每个分片创建一个副本集,其中包含完全相同的数据。 MongoDB中有两种副本方案:Master-Slave复制和Replica-Set复制。 Replica-Set 提供了更多的自动化和更好的故障处理,而 Master-Slave 有时需要管理员干预。 无论复制方案如何,在副本集中的任何时间点,只有一个分片充当主分片,所有其他副本分片都是辅助分片。 所有写入和读取操作都转到主分片,然后均匀分布(如果需要)到集合中的其他辅助分片。

在下图中,我们看到了上面解释的 MongoDB 架构,以绿色显示路由器服务器,以蓝色显示配置服务器,以及包含 MongoDB 节点的分片。

四个编号的分片每个都有 3 个“mondgod”节点。 Shard4 为灰色并标记为“副本集”。 Shard1 连接到一组三个标记为“配置服务器”的蓝色“C1 mongod”节点;该组和每个分片都连接到一系列绿色“mongos”节点。该系列反过来又连接到一系列客户端。

需要注意的是,MongoDB 中的分片(或在分片之间共享数据)是完全自动化的,这降低了故障率,使 MongoDB 成为一个高度可扩展的数据库管理系统。

NoSQL 数据库的索引结构

索引是将键与 DBMS 中相应数据记录的位置相关联的过程。 NoSQL 数据库中使用了许多索引数据结构。 以下部分将简要讨论一些更常见的方法; 即B-Tree索引、T-Tree索引和O2-Tree索引。

B树索引

B-Tree 是 DBMS 中最常见的索引结构之一。

在 B 树中,内部节点可以在某个预定义范围内具有可变数量的子节点。

与其他树结构(例如 AVL)的一个主要区别是 B-Tree 允许节点具有可变数量的子节点,这意味着更少的树平衡但更多的空间浪费。

B+-Tree 是 B-Tree 最流行的变体之一。 B+-Tree 是对 B-Tree 的改进,它要求所有的键都驻留在叶子中。

T-树索引

T-Trees 的数据结构是结合 AVL-Trees 和 B-Trees 的特征设计的。

AVL-Trees 是一种自平衡二叉搜索树,而 B-Trees 是不平衡的,每个节点可以有不同数量的子节点。

在 T-Tree 中,其结构与 AVL-Tree 和 B-Tree 非常相似。

每个节点存储多个 {key-value, pointer} 元组。 此外,二进制搜索与多元组节点结合使用以产生更好的存储和性能。

T-Tree 具有三种类型的节点:具有左右子节点的 T-Node、没有子节点的叶节点和只有一个子节点的半叶节点。

相信 T-Trees 比 AVL-Trees 具有更好的整体性能。

O2-树索引

O2-Tree 基本上是对红黑树的改进,红黑树是二叉搜索树的一种形式,其中叶节点包含 {key value, pointer} 元组。

O2-Tree 被提出来提高当前索引方法的性能。 一个 m 阶 (m ≥ 2) 的 O2-Tree,其中 m 是树的最小度数,满足以下性质:

  • 每个节点不是红色就是黑色。 根是黑色的。
  • 每个叶节点都是黑色的,由一个包含“键值,记录指针”对的块或页面组成。
  • 如果一个节点是红色的,那么它的两个子节点都是黑色的。
  • 对于每个内部节点,从节点到后代叶节点的所有简单路径都包含相同数量的黑色节点。 每个内部节点都有一个键值。
  • 叶节点是具有 ⌈m/2⌉ 和 m 个“键值、记录指针”对的块。
  • 如果一棵树只有一个节点,那么它一定是叶子,它是树的根,它可以有 1 到 m 个关键数据项。
  • 叶节点在向前和向后方向上是双重链接的。

在这里,我们看到了 O2-Tree、T-Tree、B+-Tree、AVL-Tree 和 Red-Black Tree 之间的直接性能比较:

将 Y 轴上的“总时间以秒为单位”(0-250) 与 X 轴上的“更新比率”(0-100) 进行比较的图表。五种树类型都从左侧的总次数低于 100 开始,然后在右侧增加。 O2-Tree、T-Tree 和 AVL-Tree 比其他两个向右增加得慢,AVL-Tree 在 125 左右结束,O2-Tree 在 75 左右结束,而 T-Tree 介于两者之间。 Red-Black Tree 和 B+-Tree 有更多的起伏,并且都在右上角彼此接近,Red-Black Tree 的值略高。

使用的 T-Tree、B+-Tree 和 O2-Tree 的顺序是 m = 512。

记录搜索、插入和删除操作的时间,对于 50M 记录的索引,更新率在 0%-100% 之间变化,这些操作导致向索引添加另外 50M 记录。

很明显,在 0-10% 的更新率下,B-Tree 和 T-Tree 的性能优于 O2-Tree。 然而,随着更新率的增加,O2-Tree 索引的性能明显优于大多数其他数据结构,其中 B-Tree 和 Red-Black Tree 结构受到的影响最大。

NoSQL 的案例?

快速介绍 NoSQL 数据库,重点介绍传统关系数据库的不足之处,引出第一个要点:

虽然关系数据库提供了一致性,但它们并未针对频繁存储和处理大量数据的应用程序的高性能进行优化。

NoSQL 数据库因其高性能、高可扩展性和易于访问而广受欢迎; 但是,它们仍然缺乏提供一致性和可靠性的功能。

幸运的是,许多 NoSQL DBMS 通过提供新功能来增强可扩展性和可靠性来应对这些挑战。

并非所有 NoSQL 数据库系统的性能都比关系数据库好。

MongoDB 和 Cassandra 在写入和删除操作方面的性能与关系数据库相似,并且在大多数情况下更好。

存储类型与 NoSQL DBMS 的性能之间没有直接关联。 NoSQL 实现会发生变化,因此性能可能会有所不同。

因此,应始终使用最新版本的数据库软件更新不同研究中跨数据库类型的性能测量,以使这些数字准确。

虽然我无法对性能做出明确的判断,但请记住以下几点:

  • 传统的 B-Tree 和 T-Tree 索引在传统数据库中普遍使用。
  • 一项研究通过结合多个索引结构的特征来提出 O2-Tree,从而提供了改进和增强。
  • 在大多数测试中,O2-Tree 的性能都优于其他结构,尤其是在具有庞大数据集和高更新率的情况下。
  • 在本文介绍的所有索引结构中,B-Tree 结构的性能最差。

可以而且应该做进一步的工作来增强 NoSQL DBMS 的一致性。 NoSQL 和关系数据库这两个系统的集成是一个需要进一步探索的领域。

最后,重要的是要注意 NoSQL 是对现有数据库标准的一个很好的补充,但有一些重要的警告。 NoSQL 以可靠性和一致性特性换取纯粹的性能和可扩展性。 这使它成为一个专门的解决方案,因为可以依赖 NoSQL 数据库的应用程序数量仍然有限。

好处? 专业化可能不会提供太多的灵活性,但是当您想尽可能快速有效地完成专业化工作时,您不需要瑞士军刀。 你需要 NoSQL。

相关:商业智能平台:使用 MongoDB 聚合管道的教程