NoSQL 数据库管理系统和模型的比较

前些天发现了一个人工智能学习网站，通俗易懂，风趣幽默，最重要的屌图甚多，忍不住分享一下给大家。点击跳转到网站。

NoSQL 数据库管理系统和模型的比较

介绍

当大多数人想到数据库时，他们通常会想到传统的关系数据库模型，其中涉及由行和列组成的表。虽然关系数据库管理系统仍然处理互联网上的大部分数据，但近年来，随着开发人员寻求解决关系模型局限性的方法，替代数据模型变得更加普遍。这些非关系数据库模型各有其独特的优点、缺点和用例，已被归类为NoSQL 数据库。

本文将介绍一些比较常用的NoSQL数据库模型。并将权衡它们的一些优点和缺点，并提供一些数据库管理系统的示例以及每个系统的潜在用例。

关系数据库及其局限性

数据库是逻辑建模的信息或数据集群。同时，数据库管理系统（DBMS）是一种与数据库交互的计算机程序。DBMS 允许我们控制对数据库的访问、写入数据、运行查询以及执行与数据库管理相关的任何其他任务。尽管数据库管理系统通常被称为“数据库”，但这两个术语并不完全可以互换。数据库可以是任何数据集合，而不仅仅是存储在计算机上的数据，而 DBMS 是允许我们与数据库交互的特定软件。

所有数据库管理系统都有一个底层模型来构建数据的存储和访问方式。关系数据库管理系统（RDBMS）是采用关系数据模型的 DBMS。在此模型中，数据被组织成表，在 RDBMS 的上下文中更正式地称为关系。关系数据库管理系统通常采用结构化查询语言（SQL）来管理和访问数据库中保存的数据。

从历史上看，关系模型一直是最广泛使用的数据管理方法，迄今为止，许多最流行的数据库管理系统都实现了关系模型。然而，关系模型存在一些限制，在某些用例中可能会出现问题。

例如，水平扩展关系数据库可能很困难。水平扩展或横向扩展是向现有堆栈添加更多机器以分散负载并允许更多流量和更快处理的做法。这通常与垂直扩展形成对比，垂直扩展涉及升级现有服务器的硬件，通常通过添加更多 RAM 或 CPU 来实现。

关系数据库难以水平扩展的原因与关系模型旨在确保一致性有关，这意味着查询同一数据库的客户端将始终看到最新的数据。如果要在多台机器上水平扩展关系数据库，则很难确保一致性，因为客户端可能会将数据写入一个节点而不是其他节点，并且初始写入与其他节点写入的时间之间可能存在延迟。更新以反映更改。

RDBMS 带来的另一个限制是，关系模型旨在管理结构化数据，或者与预定义数据类型一致的数据，或者至少以某种预定方式组织的数据，使其易于排序和搜索。然而，随着 20 世纪 90 年代初个人计算的普及和互联网的兴起，非结构化数据（例如电子邮件、照片、视频等）变得更加普遍。

随着这些限制变得越来越严格，开发人员开始寻找传统关系数据模型的替代方案，从而导致 NoSQL 数据库越来越受欢迎。

关于NoSQL

NoSQL标签本身的定义相当模糊。“NoSQL”是 Carlo Strozzi 于 1998 年创造的，之所以选择它，只是因为它不使用 SQL 来管理数据。

2009 年，Johan Oskarsson 为开发人员组织了一次聚会，讨论Cassandra和Voldemort等“开源、分布式和非关系数据库”的传播，该术语有了新的含义。Oskarsson 将此次聚会命名为“NOSQL”，从那时起，该术语就被用作任何不采用关系模型的数据库的统称。Strozzi 的 NoSQL 数据库实际上采用了关系模型，这意味着原始的 NoSQL 数据库并不符合当代 NoSQL 的定义。

由于“NoSQL”通常指任何不采用关系模型的 DBMS，因此有多种与 NoSQL 概念相关的操作数据模型。下表包括几个此类数据模型，但请注意，这不是完整的列表：

操作数据库模型	DBMS 示例
键值存储	Redis, MemcacheDB
列式数据库	Cassandra, Apache HBase
文件存储	MongoDB、Couchbase
图形据库	OrientDB, Neo4j

尽管底层数据模型不同，但大多数 NoSQL 数据库都有几个共同特征。其一，NoSQL 数据库通常旨在以牺牲一致性为代价来最大化可用性。从这个意义上说，一致性是指任何读操作都会返回最近写入数据库的数据。在强一致性设计的分布式数据库中，写入一个节点的任何数据都将立即在所有其他节点上可用；否则会出现错误。

相反，NoSQL 数据库通常以最终一致性为目标。这意味着新写入的数据最终会在数据库中的其他节点上可用（通常在几毫秒内），但不一定立即可用。这样做的好处是提高数据的可用性：即使我们可能看不到写入的最新数据，我们仍然可以查看它的早期版本，而不会收到错误。

关系数据库旨在处理完全符合预定义模式的规范化数据。在 DBMS 的上下文中，规范化数据是以消除冗余的方式组织的数据，这意味着数据库占用尽可能少的存储空间，而模式是数据库中数据的结构的概述。

虽然 NoSQL 数据库能够处理标准化数据，并且能够在预定义模式内对数据进行排序，但它们各自的数据模型通常比关系数据库强加的严格结构具有更大的灵活性。因此，NoSQL 数据库被誉为存储半结构化和非结构化数据的更好选择。不过，考虑到这一点，因为 NoSQL 数据库没有预定义模式，这通常意味着需要由数据库管理员来定义如何组织和访问数据，无论哪种方式对其应用程序最有意义。

现在我们已经了解了 NoSQL 数据库是什么以及它们与关系数据库的不同之处，接下来让我们仔细看看一些更广泛实施的 NoSQL 数据库模型。

键值数据库

键值数据库，也称为键值存储，通过存储和管理关联数组来工作。关联数组，也称为字典或哈希表，由键值对的集合组成，其中键用作检索关联值的唯一标识符。值可以是任何内容，从简单的对象（如整数或字符串）到更复杂的对象（如 JSON 结构）。

关系数据库定义了由具有预定义数据类型的行和列的表组成的数据结构，与此相反，键值数据库将数据存储为单个集合，没有任何结构或关系。连接到数据库服务器后，应用程序可以定义一个键（例如，the_meaning_of_life）并提供一个匹配值（例如，42），稍后可以通过提供该键以相同的方式检索该值。键值数据库将其中保存的任何数据视为不透明的 blob；由应用程序来理解它的结构。

键值数据库通常被描述为高性能、高效且可扩展。键值数据库的常见用例是缓存、消息队列 和 会话管理。

一些流行的开源键值数据存储是：

数据库	描述
Redis	Redis 是一种用作数据库、缓存或消息代理的内存数据存储，支持各种数据结构，从字符串到位图、流和空间索引。
Memcached	通用内存对象缓存系统，经常用于通过在内存中缓存数据和对象来加速数据驱动的网站和应用程序。
Riak	具有高级本地和多集群复制功能的分布式键值数据库。

列式数据库

列式数据库有时也称为面向列的数据库，是按列存储数据的数据库系统。这看起来与传统的关系数据库类似，但不是将列分组到表中，而是将每个列存储在系统存储中的单独文件或区域中。

列式数据库中存储的数据按记录顺序显示，这意味着一列中的第一个条目与其他列中的第一个条目相关。这种设计允许查询仅读取所需的列，而不必读取表中的每一行并在将不需要的数据存储在内存中后丢弃这些数据。

由于每列中的数据属于相同类型，因此允许采用各种存储和读取优化策略。特别是，许多列式数据库管理员实施压缩策略，例如游程编码，以最大限度地减少单个列占用的空间量。这样做的好处是可以加快读取速度，因为查询需要遍历的行更少。然而，列式数据库的一个缺点是加载性能往往很慢，因为每一列必须单独写入，并且数据通常保持压缩状态。特别是增量加载以及读取单个记录，在性能方面可能会付出高昂的代价。

面向列的数据库自 20 世纪 60 年代以来就已出现。然而，自 2000 年代中期以来，列式数据库已更广泛地用于数据分析，因为列式数据模型非常适合快速查询处理。在应用程序需要频繁执行聚合函数（例如查找列中数据的平均值或总和）的情况下，它们也被认为是有利的。一些列式数据库管理系统甚至能够使用 SQL 查询。

一些流行的开源柱状数据库是：

数据库	描述
Apache Cassandra	旨在最大限度地提高可扩展性、可用性和性能的列存储。
Apache HBase	一种分布式数据库，支持大量数据的结构化存储，旨在与Hadoop 软件库配合使用。
ClickHouse	支持实时生成分析数据和 SQL 查询的容错 DBMS。

面向文档的数据库

面向文档的数据库或文档存储是以文档形式存储数据的 NoSQL 数据库。文档存储是一种键值存储：每个文档都有一个唯一的标识符——它的键——文档本身充当值。

这两种模型之间的区别在于，在键值数据库中，数据被视为不透明，数据库不知道也不关心其中保存的数据；由应用程序来了解存储了哪些数据。然而，在文档存储中，每个文档都包含某种元数据，为数据提供一定程度的结构。文档存储通常附带 API 或查询语言，允许用户根据文档包含的元数据检索文档。它们还允许复杂的数据结构，因为我们可以将文档嵌套在其他文档中。

与关系数据库不同，关系数据库中给定对象的信息可能分布在多个表或数据库中，面向文档的数据库可以将给定对象的所有数据存储在单个文档中。文档存储通常将数据存储为JSON、BSON、XML或YAML文档，有些可以存储二进制格式，例如 PDF 文档。有些使用 SQL 的变体、全文搜索或它们自己的本机查询语言来进行数据检索，而另一些则采用不止一种查询方法。

近年来，面向文档的数据库越来越受欢迎。由于其灵活的架构，它们经常用于电子商务、博客和分析平台以及内容管理系统。文档存储被认为是高度可扩展的，分片是一种常见的水平扩展策略。它们还非常适合保存大量不相关、结构各异的复杂信息。

一些流行的基于开源文档的数据存储是：

数据库	描述
MongoDB	MongoDB 是一种通用的分布式文档存储，在撰写本文时是世界上使用最广泛的面向文档的数据库。
Couchbase	最初称为 Membase，一种基于 JSON、与 Memcached 兼容的基于文档的数据存储。Couchbase是一个多模型数据库，也可以充当键值存储。
Apache CouchDB	CouchDB 是 Apache 软件基金会的一个项目，将数据存储为 JSON 文档，并使用 JavaScript 作为其查询语言。

图形据库

图形数据库可以被认为是文档存储模型的子类别，因为它们将数据存储在文档中并且不坚持数据遵循预定义的模式。但不同之处在于，图形数据库通过突出显示各个文档之间的关系，为文档模型添加了一个额外的层。

为了更好地掌握图数据库的概念，理解以下术语很重要：

• 节点：节点是图形数据库跟踪的单个实体的表示。它或多或少相当于关系数据库中的记录或行或文档存储中的*文档的概念。*例如，在音乐录音艺术家的图形数据库中，节点可能代表单个表演者或乐队。
• 属性：属性是与各个节点相关的相关信息。基于我们的唱片艺术家示例，某些属性可能是“歌手”、“爵士乐”或“白金唱片销售艺术家”，具体取决于与数据库相关的信息。
• 边：也称为图或关系，边是两个节点如何相关的表示，是图数据库的关键概念，将其与 RDBMS 和文档存储区分开来。边可以是有向的，也可以是无向的。
  • 无向：在无向图中，节点之间的边的存在只是为了显示它们之间的连接。在这种情况下，边可以被认为是“双向”关系——一个节点与另一个节点的关系之间没有隐含的差异。
  • 有向：在有向图中，根据关系起源的方向，边可以具有不同的含义。在这种情况下，边是“单向”关系。例如，有向图数据库可能会指定从 Sammy 到 Seaweeds 的关系，显示 Sammy 为该团体制作了一张专辑，但可能不会显示从 The Seaweeds 到 Sammy 的等效关系。

使用图形数据库执行某些操作要简单得多，因为它们如何链接和分组相关信息。这些数据库通常用于以下情况：必须能够从数据点之间的关系中获取见解，或者用于最终用户可用的信息由其与其他人的连接决定的应用程序（如社交网络）。它们经常用于欺诈检测、推荐引擎以及身份和访问管理应用程序。

一些流行的开源图形数据库是：

数据库	描述
Neo4j	具有本机图形存储和处理功能的ACID兼容DBMS 。截至撰写本文时，Neo4j 是世界上最流行的图形数据库。
ArangoDB	ArangoDB 不仅仅是一种图形数据库，它还是一种多模型数据库，它将图形、文档和键值数据模型统一在一个 DBMS 中。它具有 AQL（一种原生的类似 SQL 的查询语言）、全文搜索和排名引擎。
OrientDB	OrientDB 是另一个多模型数据库，支持图、文档、键值和对象模型。它支持 SQL 查询和 ACID 事务。

结论

在本文中，我们仅介绍了当今使用的一些 NoSQL 数据模型。一些 NoSQL 模型（例如对象存储多年来已经得到了不同程度的使用，但在某些用例中仍然是关系模型的可行替代方案。其他数据库，如对象关系数据库和时间序列数据库，混合了关系数据模型和 NoSQL 数据模型的元素，形成了介于两端之间的一种中间立场。

NoSQL 数据库类别极其广泛，并且至今仍在不断发展。