NoSQL数据库比较

本文翻译自：A Comparison of NoSQL Database Management Systems and Models

背景介绍

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

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

关系型数据库和它们的缺陷

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

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

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

水平扩展关系数据库可能很困难。水平扩展或横向扩展是向现有堆栈添加更多机器以分散负载并允许更多流量和更快处理的做法。这通常与垂直扩展形成对比，垂直扩展涉及升级现有服务器的硬件，通常是通过添加更多 RAM 或 CPU。
难以横向扩展关系数据库的原因在于关系模型旨在确保一致性，这意味着查询同一数据库的客户端将始终看到最新数据。如果您要跨多台机器水平扩展关系数据库，则很难确保一致性，因为客户端可能会将数据写入一个节点而不是其他节点，并且初始写入和其他节点的时间之间可能会有延迟更新以反映更改。
RDBMS 提出的另一个限制是，关系模型旨在管理结构化数据，或与预定义数据类型一致或至少以某种预定方式组织的数据，使其易于排序和搜索。然而，随着 1990 年代初期个人计算的普及和互联网的兴起，非结构化数据（例如电子邮件、照片、视频等）变得更加普遍。

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

NoSQL介绍

标签 NoSQL 本身有一个相当模糊的定义。 “NoSQL”是 Carlo Strozzi 在 1998 年创造的，作为他当时新的 NoSQL 数据库的名称，之所以选择它，只是因为它不使用 SQL 来管理数据。

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

因为“NoSQL”通常是指不使用关系模型的任何 DBMS，所以有几个与 NoSQL 概念相关的操作数据模型。下表包括几个这样的数据模型，但请注意，这不是一个完整的列表：

Operational Database Model	Example DBMSs
Key-value store	Redis, MemcacheDB
Columnar database	Cassandra, Apache HBase
Document store	MongoDB,Couchbase
Graph database	OrientDB, Neo4j

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

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

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

虽然 NoSQL 数据库具备处理规范化数据的能力，并且能够在预定义的模式中对数据进行排序，但它们各自的数据模型通常比关系数据库强加的刚性结构具有更大的灵活性。正因为如此，NoSQL 数据库因是存储半结构化和非结构化数据的更好选择而享有盛誉。但是，请记住这一点，因为 NoSQL 数据库不带有预定义的模式，这通常意味着由数据库管理员定义应如何组织和访问数据，以对其应用程序最有意义的方式进行。

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

Key-value Databases

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

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

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

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

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

Columnar Databases

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

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

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

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

一些流行的开源列式数据库有：

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

Document-oriented Databases

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

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

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

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

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

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

Graph Databases

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

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

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

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

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

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

总结

在本教程中，我们仅讨论了当今使用的少数 NoSQL 数据模型。多年来，一些 NoSQL 模型（例如对象存储）的使用水平各不相同，但在某些用例中仍然是关系模型的可行替代方案。其他的，比如对象关系数据库和时间序列数据库，混合了关系和 NoSQL 数据模型的元素，在频谱的两端之间形成一种中间地带。

NoSQL 数据库类别非常广泛，并且一直发展到今天。如果您有兴趣了解有关 NoSQL 数据库管理系统和概念的更多信息，我们鼓励您查看我们的 NoSQL 相关内容库（地址）。