NoSQL数据库管理系统和模型的比较
介绍
当大多数人想到数据库时，他们通常会想到传统的关系数据库模型，该模型涉及由行和列组成的表。 虽然关系数据库管理系统仍然处理互联网上的大部分数据，但近年来，随着开发人员寻求解决关系模型局限性的变通方法，替代数据模型变得越来越普遍。 这些非关系型数据库模型各有其独特的优势、劣势和用例，已被归类为 NoSQL 数据库。
本文将向您介绍几个比较常用的 NoSQL 数据库模型。 它将权衡它们的一些优点和缺点，并提供一些数据库管理系统示例和每个示例的潜在用例。
关系数据库及其局限性
Databases 是逻辑建模的信息集群，或 data。 同时， 数据库管理系统 (DBMS) 是与数据库交互的计算机程序。 DBMS 允许您控制对数据库的访问、写入数据、运行查询以及执行与数据库管理相关的任何其他任务。 尽管数据库管理系统通常被称为“数据库”，但这两个术语并不完全可以互换。 数据库可以是任何数据集合，而不仅仅是存储在计算机上的数据，而 DBMS 是允许您与数据库交互的特定软件。
所有数据库管理系统都有一个底层模型，用于构建数据的存储和访问方式。 关系数据库管理系统 (RDBMS) 是采用关系数据模型的 DBMS。 在这个模型中，数据被组织成表，在 RDBMS 的上下文中更正式地称为 关系 。 关系数据库管理系统通常使用 结构化查询语言 (SQL) 来管理和访问数据库中保存的数据。
从历史上看，关系模型一直是最广泛使用的数据管理方法，直到今天 ，许多最流行的数据库管理系统都实现了关系模型 。 但是，关系模型存在一些限制，在某些用例中可能会出现问题。
例如，水平扩展关系数据库可能很困难。 水平扩展或向外扩展，是向现有堆栈添加更多机器以分散负载并允许更多流量和更快处理的做法。 这通常与 垂直缩放 形成对比，后者涉及升级现有服务器的硬件，通常通过添加更多 RAM 或 CPU。
难以水平扩展关系数据库的原因与关系模型旨在确保一致性这一事实有关，这意味着查询同一数据库的客户端将始终看到最新数据。 如果您要在多台机器上水平扩展关系数据库，则很难确保一致性，因为客户端可能会将数据写入一个节点而不是其他节点，并且在初始写入和其他节点的时间之间可能会有延迟更新以反映更改。
RDBMS 提出的另一个限制是关系模型旨在管理 结构化数据 ，或与预定义数据类型对齐或至少以某种预定方式组织的数据，使其易于排序和搜索。 然而，随着 1990 年代初期个人计算的普及和互联网的兴起， 非结构化数据 — 例如电子邮件、照片、视频等。 ——变得越来越普遍。
随着这些限制越来越严格，开发人员开始寻找传统关系数据模型的替代方案，从而导致 NoSQL 数据库越来越受欢迎。
关于 NoSQL
标签 NoSQL 本身有一个相当模糊的定义。 “NoSQL”是 1998 年由 Carlo Strozzi 创造的，作为他当时新的 NoSQL 数据库 的名称，之所以选择它只是因为它不使用 SQL 来管理数据。
2009 年之后，Johan Oskarsson 为开发人员组织了一次聚会，讨论“开源、分布式和非关系数据库”的传播，例如 Cassandra 和 Voldemort，该术语有了新的含义。 Oskarsson 将聚会命名为“NOSQL”，从那时起，该术语就被用作任何不使用关系模型的数据库的统称。 有趣的是，Strozzi 的 NoSQL 数据库实际上使用了关系模型，这意味着原始的 NoSQL 数据库不符合 NoSQL 的当代定义。
因为“NoSQL”通常是指任何不使用关系模型的 DBMS，所以有几个与 NoSQL 概念相关的操作数据模型。 下表包括几个这样的数据模型，但请注意，这不是一个完整的列表：
| 操作数据库模型 | 示例 DBMS |
|---|---|
| 键值存储 | Redis、MemcacheDB |
| 列式数据库 | 卡桑德拉，Apache HBase |
| 文档存储 | MongoDB，沙发底座 |
| 图数据库 | 东方数据库，Neo4j |
尽管有这些不同的底层数据模型，但大多数 NoSQL 数据库都具有几个特征。 一方面，NoSQL 数据库通常旨在以牺牲一致性为代价最大化可用性。 从这个意义上说，一致性是指任何读取操作都将返回写入数据库的最新数据的想法。 在为强一致性而设计的分布式数据库中，任何写入一个节点的数据都将立即在所有其他节点上可用； 否则会出现错误。
相反，NoSQL 数据库通常以 最终一致性 为目标。 这意味着新写入的数据最终会在数据库中的其他节点上可用（通常在几毫秒内），但不一定立即可用。 这有利于提高数据的可用性：即使您可能看不到写入的最新数据，您仍然可以查看它的早期版本，而不会收到错误消息。
关系数据库旨在处理完全适合预定义模式的规范化数据。 在 DBMS 的上下文中， 标准化数据 是以消除冗余的方式组织的数据——这意味着数据库占用尽可能少的存储空间——而 schema 是数据库中数据的结构概述。
虽然 NoSQL 数据库能够处理规范化数据并且能够在预定义的模式中对数据进行排序，但它们各自的数据模型通常比关系数据库强加的刚性结构具有更大的灵活性。 正因为如此，NoSQL 数据库被誉为存储半结构化和非结构化数据的更好选择。 但是，考虑到这一点，因为 NoSQL 数据库没有预定义的模式，这通常意味着由数据库管理员来定义如何以最适合其应用程序的方式组织和访问数据。
现在您已经了解了 NoSQL 数据库是什么以及它们与关系数据库的不同之处，让我们仔细看看一些更广泛实施的 NoSQL 数据库模型。
键值数据库
键值数据库，也称为键值存储，通过存储和管理关联数组来工作。 关联数组，也称为 字典 或 哈希表 ，由键值对的集合组成，其中键用作检索关联值的唯一标识符。 值可以是任何东西，从简单的对象（如整数或字符串）到更复杂的对象（如 JSON 结构）。
与定义由具有预定义数据类型的行和列的表组成的数据结构的关系数据库相比，键值数据库将数据存储为没有任何结构或关系的单个集合。 连接到数据库服务器后，应用程序可以定义一个键（例如，the_meaning_of_life）并提供一个匹配的值（例如，42），稍后可以通过提供相同的方式检索该值钥匙。 键值数据库将保存在其中的任何数据视为不透明的 blob； 由应用程序来了解其结构。
键值数据库通常被描述为高性能、高效和可扩展的。 键值数据库的常见用例是缓存、消息队列和会话管理。
一些流行的开源键值数据存储是：
| 数据库 | 描述 |
|---|---|
| 雷迪斯 | Redis 是用作数据库、缓存或消息代理的内存数据存储，支持各种数据结构，从字符串到位图、流和空间索引。 |
| 内存缓存 | 一种通用的内存对象缓存系统，经常用于通过在内存中缓存数据和对象来加速数据驱动的网站和应用程序。 |
| 里亚克 | 具有高级本地和多集群复制的分布式键值数据库。 |
列式数据库
列式数据库，有时也称为面向列的数据库，是按列存储数据的数据库系统。 这可能看起来类似于传统的关系数据库，但不是将列组合成表，而是将每列存储在系统存储中的单独文件或区域中。
存储在列式数据库中的数据按记录顺序出现，这意味着一个列中的第一个条目与其他列中的第一个条目相关。 这种设计允许查询只读取它们需要的列，而不必读取表中的每一行并在将不需要的数据存储在内存中后丢弃它。
因为每一列中的数据是相同类型的，所以它允许各种存储和读取优化策略。 特别是，许多列式数据库管理员实施了一种压缩策略，例如 运行长度编码 ，以最大限度地减少单个列占用的空间量。 这可以加快读取速度，因为查询需要遍历更少的行。 但是，列式数据库的一个缺点是加载性能往往很慢，因为必须单独写入每一列并且数据通常保持压缩状态。 特别是增量负载，以及单个记录的读取，在性能方面可能代价高昂。
自 1960 年代以来，面向列的数据库就已经存在。 但是，自 2000 年代中期以来，列式数据库已更广泛地用于数据分析，因为列式数据模型非常适合快速查询处理。 在应用程序需要频繁执行 聚合函数 的情况下，它们也被认为是有利的，例如在列中查找数据的平均值或总和。 一些列式数据库管理系统甚至能够使用 SQL 查询。
一些流行的开源列式数据库是：
| 数据库 | 描述 |
|---|---|
| 阿帕奇卡桑德拉 | 一种列存储，旨在最大限度地提高可伸缩性、可用性和性能。 |
| Apache HBase | 一个分布式数据库，支持大量数据的结构化存储，旨在与 Hadoop 软件库 配合使用。 |
| 点击屋 | 支持实时生成分析数据和 SQL 查询的容错 DBMS。 |
面向文档的数据库
面向文档的数据库或文档存储，是以文档的形式存储数据的NoSQL数据库。 文档存储是 键值存储 的一种类型：每个文档都有一个唯一的标识符——它的键——并且文档本身作为值。
这两种模型的区别在于，在键值数据库中，数据被视为不透明的，数据库不知道也不关心其中保存的数据； 由应用程序来了解存储了哪些数据。 然而，在文档存储中，每个文档都包含某种元数据，这些元数据为数据提供了一定程度的结构。 文档存储通常带有 API 或查询语言，允许用户根据包含的元数据检索文档。 它们还允许复杂的数据结构，因为您可以将文档嵌套在其他文档中。
与给定对象的信息可能分布在多个表或数据库中的关系数据库不同，面向文档的数据库可以将给定对象的所有数据存储在单个文档中。 文档存储通常将数据存储为 JSON、BSON、XML 或 YAML 文档，有些可以存储二进制格式，如 PDF 文档。 一些使用 SQL 的变体、全文搜索或他们自己的本地查询语言进行数据检索，而另一些则具有多个查询方法。
近年来，面向文档的数据库的受欢迎程度有了巨大的增长。 由于其灵活的架构，它们在电子商务、博客和分析平台以及内容管理系统中得到了经常使用。 文档存储被认为是高度可扩展的，sharding 是一种常见的水平扩展策略。 它们还非常适合保存大量不相关、结构不同的复杂信息。
一些流行的基于开源文档的数据存储是：
| 数据库 | 描述 |
|---|---|
| MongoDB | MongoDB 是一种通用的分布式文档存储，在撰写本文时是 世界上使用最广泛的面向文档的数据库 。 |
| 沙发底座 | 最初称为 Membase，一种基于 JSON、与 Memcached 兼容的基于文档的数据存储。 作为一个 多模型 数据库，Couchbase 还可以用作键值存储。 |
| 阿帕奇沙发数据库 | 作为 Apache 软件基金会的一个项目，CouchDB 将数据存储为 JSON 文档，并使用 JavaScript 作为其查询语言。 |
图数据库
图形数据库 可以被认为是文档存储模型的一个子类别，因为它们将数据存储在文档中，并且不坚持数据遵循预定义的模式。 但是，不同之处在于图形数据库通过突出显示各个文档之间的关系，为文档模型添加了一个额外的层。
为了更好地掌握图数据库的概念，理解以下术语很重要：
- Node：node 是图形数据库跟踪的单个实体的表示。 它或多或少等同于关系数据库中的 record 或 row 或文档存储中的 document 的概念。 例如，在音乐录音艺术家的图形数据库中，一个节点可能代表一个表演者或乐队。
- Property：property是与各个节点相关的相关信息。 基于我们的录音艺术家示例，某些属性可能是“歌手”、“爵士乐”或“白金销售艺术家”，具体取决于与数据库相关的信息。
- Edge：也称为graph或relationship，edge表示两个节点如何关联，是key图数据库的概念将它们与 RDBMS 和文档存储区分开来。 边可以是有向或无向。 无向：在无向图中，节点之间的边的存在只是为了显示它们之间的连接。 在这种情况下，边可以被认为是“双向”关系——一个节点与另一个节点之间的关系没有隐含的差异。 有向：在有向图中，根据关系起源的方向，边可以具有不同的含义。 在这种情况下，边是“单向”关系。 例如，有向图数据库可能会指定从 Sammy 到 Seaweeds 的关系，表明 Sammy 为该小组制作了一张专辑，但可能不会显示从 The Seaweeds 到 Sammy 的等效关系。
使用图形数据库执行某些操作要简单得多，因为它们如何链接和分组相关信息。 这些数据库通常用于能够从数据点之间的关系中获得洞察力很重要的情况，或者在最终用户可用的信息取决于他们与他人的联系的应用程序中，例如在社交网络中。 它们经常用于欺诈检测、推荐引擎以及身份和访问管理应用程序。
一些流行的开源图形数据库是：
| 数据库 | 描述 |
|---|---|
| Neo4j | 一个符合 ACID 的 DBMS，具有原生图形存储和处理功能。 在撰写本文时，Neo4j 是 世界上最流行的图形数据库 。 |
| ArangoDB | ArangoDB 不仅仅是一个图形数据库，它还是一个多模型数据库，它将图形、文档和键值数据模型结合在一个 DBMS 中。 它具有 AQL（一种原生的类似 SQL 的查询语言）、全文搜索和排名引擎。 |
| 东方数据库 | OrientDB 是另一个多模型数据库，支持图形、文档、键值和对象模型。 它支持 SQL 查询和 ACID 事务。 |
结论
在本教程中，我们仅介绍了当今使用的少数 NoSQL 数据模型。 一些 NoSQL 模型，例如 对象存储 ，多年来的使用水平有所不同，但在某些用例中仍然是关系模型的可行替代方案。 其他的，如 对象关系数据库 和 时间序列数据库 ，混合了关系和 NoSQL 数据模型的元素，在频谱的两端形成了一种中间地带。
NoSQL 数据库类别非常广泛，并且一直发展到今天。 如果您有兴趣了解有关 NoSQL 数据库管理系统和概念的更多信息，我们鼓励您查看我们的 NoSQL 相关内容库 。
