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

卡拉先生
发布于 2020年07月11日 | 上次编辑:2020年07月19日

简介

当大多数人提到数据库时,他们通常会想到传统的关系数据库模型,包括由行和列组成的表。比如 MySQL 或者 Postgres 等。

尽管关系数据库管理系统仍然可以处理互联网上绝大部分的数据,但是随着开发人员寻求解决关系模型局限性的方法,近年来,替换关系模型的其它数据模型已变得越来越普遍。

这些非关系数据库模型各自具有独特的优势、劣势和用例,已被归类为 NoSQL 数据库。

本文将介绍一些更为常用的 NoSQL 数据库模型。我们将权衡其优点和缺点,并提供一些数据库管理系统示例以及每个数据库可能的用例。

如果你需要了解如何进行数据库搜索,或如何接入搜索引擎,欢迎尝试和阅读卡拉搜索并了解如何用卡拉搜索轻松接入 MySQL, Postgres 或 NoSQL 数据库,比如 MongoDB, Redis 等

SQL对比 NoSQL
SQL对比 NoSQL

关系数据库及其局限性

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

所有的数据库管理系统都有一个基础模型,其构造决定了如何存储和访问数据。关系数据库管理系统(RDBMS)是采用关系数据模型的DBMS。在此模型中,数据被组织成表格,或者在 RDBMS 的语境下一般称之为关系。RDBMS 通常采用结构化查询语言(SQL)来管理和访问数据库中保存的数据。

从历史上看,关系模型一直是用于管理数据的最广泛使用的方法,并且直到今天许多最受欢迎的数据库管理系统都实现了关系模型。但是,关系模型存在一些限制,这在某些特定情况下可能是有问题的。

例如,很难在水平方向上扩展关系数据库(新型的一些数据库开始解决这个问题,比如 TiDB等)

水平扩展(即横向扩展)是在现有堆栈中添加更多的计算机以分散负载并允许更多的流量及更快的处理速度。这通常与垂直扩展形成对比,垂直扩展通常添加更多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 概念相关的操作数据模型。 下表包括几个此类的数据模型,但请注意,这不是完整的列表:

数据库模型 实例
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 数据库模型。

NoSQL模型比较
NoSQL模型比较

键值数据库

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

与关系数据库由行和列组成的表以及预定义数据类型组成的数据结构相反,键值数据库将数据存储为单个集合,而没有任何的结构或关系。连接到数据库服务器后,应用程序可以定义一个键(例如themeaningof_life)并提供一个匹配的值(例如 42 ),然后可以通过该键以相同的方式检索匹配值。键值数据库将其包含的所有数据视为不透明的一团;并由应用程序决定数据库是何种结构。

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

一些流行的开源键值数据存储为:

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

柱状数据库

列式数据库(有时称为面向列的数据库)是将数据存储在列中的数据库系统。看起来似乎与传统的关系数据库类似,但却不是将各列分组为表格,而是将每列存储在系统存储中的单独文件或区域中。

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

因为每一列中的数据都是同一类型的,所以它允许各种存储和读取的优化策略。特别是许多列式数据库管理员实施了压缩策略(例如行程长度压缩算法),将单个列占用的空间最小化。由于查询需要遍历更少的行,因此可以提升读取的速度。但是列式数据库有一个缺点,由于每一列必须单独的写入并且数据通常会压缩,因此加载性能趋于降低。特别是增量负载以及读取单个记录时就性能而言代价会非常高。

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

一些流行的开源列式数据库是:

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

面向文档的数据库

面向文档的数据库或文档存储是以文档的形式存储数据的 NoSQL 数据库。文档存储是键值存储库的一种:每个文档都有一个唯一的标识符(即其键),而文档本身就是值。

这两个模型之间的区别在于,在键值数据库中数据被视为不透明,并且数据库不知道或不在乎其中的数据;由应用程序决定存储什么样的数据。但是在文档存储中每个文档都包含一些元数据,这些元数据提供了存储数据的一定程度的结构。文档存储通常带有API或查询语言,允许用户根据其包含的元数据来检索文档。它们还允许复杂的数据结构,因此可以将文档嵌套在其他文档中。

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

近年来,面向文档的数据库越来越受欢迎。 凭借灵活的架构,它们在电子商务,博客和分析平台以及内容管理系统中被频繁地使用。 文档存储被认为是高度可伸缩的,分片是一种常见的水平扩展策略。 它们对于保留大量的结构上不相关的复杂信息也非常有用。

一些流行的开源文档存储是:

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

图形数据库

图形数据库可以被认为是文档存储模型的子类别,因为它们将数据存储在文档中,而不是要求数据遵循预定义的架构。但是区别在于,图形数据库通过突出显示各个文档之间的关系为文档模型增加了额外的一层。

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

  • 节点:节点是图形数据库跟踪的单个实体的表示。它或多或少地等同于关系数据库中的一条记录或行或者文档存储中的文档的概念。例如,在唱片艺术家的图形数据库中,一个节点可能代表一个表演者或乐队。
  • 属性:属性是与各个节点有关的相关信息。以我们的唱片艺术家为例,根据数据库的相关信息,某些属性可能是“歌手”、“爵士”或“白金唱片销售艺术家”。
  • 边缘:边缘也称为图形或关系,它表示两个节点之间的关系,是图形数据库中一个将它们与RDBMS和文档存储数据库区分开的关键概念。边缘可以是有向的或无向的。

    • 无向的:在无向图中,节点之间的边仅用于显示它们之间的连接。在这种情况下,可以将边缘视为“双向”关系—— 一个节点与另一节点的关联间没有隐含的区别。
    • 有向的:在有向图中,基于关系起始的方向,边可以具有不同的含义。在这种情况下,边缘是“单向”关系。例如,一个有向图形数据库可能会明确 Sammy 和 Seaweeds 之间的关系,Sammy 为该乐队制作了一张专辑,但可能不会表明 The Seaweeds 与 Sammy之间的对等关系。

某些操作由于使用图形数据库进行链接和分组相关信息而更加容易执行。这些数据库通常用于必须从数据点之间的关系中获得洞察力的情况下,或者在社交网络中,终端用户可用的信息由他们与其他人的连接关系决定的应用程序。 它们常用于欺诈检测、推荐引擎以及身份识别和授权访问管理程序。

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

Database Description
Neo4j 带有ACID的DBMS,具有本机图形存储和处理功能。 撰写本文时,Neo4j是世界上最受欢迎的图形数据库。
ArangoDB ArangoDB不仅是图形数据库,还是一个多模型数据库,将图形、文档和键值数据模型组合在一个DBMS中。 具有AQL(类似于SQL的本地查询语言)、全文搜索和排名引擎的特性。
OrientDB 另一个多模型数据库 OrientDB 支持图形、文档、键值和对象模型。它支持 SQL 查询和 ACID 事务。

与关系数据库类似的地方

与关系数据库类似,NoSQL 也不适合用作搜索型数据处理。虽然常见的 NoSQL 数据库,比如 MongoDB 或 Redis 有支持一定程度上的搜索功能,但是它们的搜索均不是用索引来做的。因此,当需要快速搜索功能的时候,不管是关系型数据库的 MySQL,Postgres 或是 NoSQL 里的 MongoDB 或 Redis,都不能很好地满足要求。

而像 Lucene,Elastic Search 或卡拉搜索这样的工具,则可以更好地解决搜索需求。如果你需要比较快的文本搜索、文档查询功能,请看看卡拉搜索或在社区中继续阅读关于ElasticSearch的文章。

结论

本节教程我们只介绍了一些现在使用的NoSQL数据模型。 多年来某些 NoSQL 模型(例如对象存储)有着不同层次的使用,但在某些用例中仍可作为关系模型的可行替代方案。 其他的如对象关系数据库和时间序列数据库则将关系模型和NoSQL数据模型的元素混合在一起,形成了频谱两端之间的一种中间立场。

数据库的 NoSQL 类别非常广泛,并且一直持续发展到今天。 如果有兴趣了解有关 NoSQL 数据库系统或其它数据库、运维和搜索相关的知识,请到卡拉技术社区 继续学习。

友情链接更新日志© 2020, 卡拉搜索, Built with ❤️ in San Francisco + Beijing

京ICP备15049164号-3