简介

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

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

关系数据库及其局限性

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

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

在历史上，关系模型一直是管理数据最广泛使用的方法，直到今天许多最流行的数据库管理系统都实现了关系模型.但是，关系模型存在几个限制，这些限制在某些用例中可能会有问题。

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

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

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

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

关于NoSQL

标签_NoSQL_本身的定义相当模糊。)，]的名称，之所以选择它，仅仅是因为它没有使用Sql来管理数据。

2009年，Johan Oskarsson组织了一次开发人员会议，讨论)和Voldemort。Oskarsson将这种方法命名为NOSQL，从那时起，这个术语就被用作任何不采用关系模型的数据库的统称。有趣的是，Strozzi的NoSQL数据库实际上采用了关系模型，这意味着原始的NoSQL数据库不符合NoSQL的当代定义。

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

运营数据库模型|DBMS示例

键值存储|Redis、MemcacheDB 分栏式数据库|Cassandra、ApacheHBase 文档存储|MongoDB、Couchbase 图形数据库|OrientDB、Neo4j

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

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

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

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

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

键值数据库

键-值数据库，也称为_键-值存储_，通过存储和管理关联数组来工作。关联数组也称为_DICTIONARY_或_HASH TABLE_，由键-值对的集合组成，其中键充当检索关联值的唯一标识符。值可以是任何对象，从简单的对象(如整数或字符串)到更复杂的对象(如JSON结构)。

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

键值数据库通常被描述为高性能、高效率和可伸缩的。键值数据库的常见用例是caching，消息queuing，和会话management.

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

柱状数据库

分栏式数据库，有时称为面向列的数据库，是以列存储数据的数据库系统。这似乎类似于传统的关系数据库，但不是将列组合到表中，而是将每列存储在系统存储中的单独文件或区域中。

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

因为每列中的数据属于同一类型，所以它允许各种存储和读取优化策略。特别是，许多列式数据库管理员实施压缩策略，如Run-Long encoding]，以最大限度地减少单列占用的空间量。这具有加快读取速度的好处，因为查询需要遍历的行数更少。然而，列数据库的一个缺点是负载性能往往很慢，因为每列都必须单独写入，而且数据通常是压缩的。尤其是增量加载，以及读取单个记录，在性能方面可能会代价高昂。

以列为导向的数据库自20世纪60年代以来一直存在。然而，自本世纪头十年中期以来，列式数据库已被更广泛地用于数据分析，因为列式数据模型非常适合快速查询处理。在应用程序需要频繁执行聚合functions，]的情况下，它们也被视为优势，例如查找列中数据的平均值或总和。一些分栏式数据库管理系统甚至能够使用SQL查询。

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

数据库|说明

ApacheCassandra|旨在最大化可伸缩性、可用性和性能的列存储。 ApacheHBase|支持海量数据的结构化存储的分布式数据库，旨在与Hadoop软件库. ClickHouse|支持实时生成分析数据和SQL查询的容错数据库管理系统。

面向文档的数据库

面向文档的数据库或文档存储是以文档的形式存储数据的NoSQL数据库。文档存储是一种Key-Value store：]，每个文档都有一个唯一的标识符--它的键--并且文档本身充当这个值。

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

与关系数据库不同，在关系数据库中，给定对象的信息可能分布在多个表或数据库中，而面向文档的数据库可以将给定对象的所有数据存储在单个文档中。文档存储通常将数据存储为JSON，BSON，XML，或[YAML)(https://en.wikipedia.org/wiki/YAML)文档)，有些还可以存储二进制格式，如PDF文档。有些使用SQL的变体、全文搜索或它们自己的原生查询语言进行数据检索，而另一些则使用多种查询方法。

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

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

数据库|说明

[https://www.mongodb.com/)](MongoDB|一个通用的分布式文档存储，在撰写本文时，MongoDB是世界上使用最广泛的面向文档的database。 CouchBase|最初称为Membase，一个基于JSON的、兼容Memcached的、基于文档的数据存储。A_MULTI-MODEL_DATABASE，Couchbase还可以作为键值存储。 阿帕奇CouchDB|阿帕奇软件基金会的一个项目，CouchDB将数据存储为JSON文档，并使用JSON作为其查询语言。

图形数据库

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

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

• 节点 ：A_NODE_是图形数据库跟踪的单个实体的表示。它或多或少等同于关系数据库中的记录或行的概念或文档存储中的文档。例如，在音乐录制艺术家的图形数据库中，节点可能表示单个表演者或乐队。
• 属性 ：A_PROPERTY_是与单个节点相关的信息。在我们的录音艺术家示例的基础上，根据与数据库相关的信息，一些属性可能是歌手、爵士或白金销售艺术家。
• 边 ：也称为_graph_或_Relationship_，an_edge_是两个节点如何相关的表示，是图形数据库的一个关键概念，它区别于RDBMS和文档存储。边可以是定向的，也可以是非定向的。 -无向图 ：在无向图中，节点之间的边的存在只是为了表示它们之间的连接。在这种情况下，边可以被认为是双向关系--一个节点与另一个节点的关联方式之间没有隐含的区别。 -有向图 ：在有向图中，根据关系起源的方向，边可以有不同的含义。在这种情况下，边是单向关系。例如，有向图数据库可能指定从Sammy到海藻的关系，表明Sammy为该组制作了专辑，但可能不会显示从海藻到Sammy的等价关系。

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

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

数据库|说明

Neo4j|具有原生图形存储和处理功能的ACID-compliant数据库管理系统。在撰写本文时，Neo4j是world.中最流行的图形数据库 ArangoDB|不仅仅是图形数据库，ArangoDB是一个多模型数据库，它将图形、文档和键值数据模型统一到一个数据库管理系统中。它的特点是AQL(一种原生的类似SQL的查询语言)、全文搜索和排名引擎。 OrientDB|另一个多模型数据库，支持图形、文档、键值和对象模型。它支持SQL查询和ACID事务。

结论

在本教程中，我们只介绍了当今使用的几个NoSQL数据模型。一些NoSql模型，如Object stores，]，多年来得到了不同程度的使用，但在某些用例中仍然是关系模型的可行替代方案。其他的，如对象-关系databases和时间序列databases，]混合了关系数据模型和NoSQL数据模型的元素，形成了一种介于两者之间的中间地带。

NoSQL数据库的类别非常广泛，并且一直发展到今天。如果您有兴趣了解更多有关noSQL数据库管理系统和概念的知识，我们鼓励您查看我们的与noSQL相关的content.库