数据库简介 比较数据库类型：数据库类型如何演变以满足不同需求目录简介传统数据库：为现代系统铺平道路关系型数据库：使用表作为组织结构化数据的标准解决方案NoSQL 数据库：不适合关系型范式的数据的现代替代方案NewSQL 数据库：为传统关系型模式带来现代可伸缩性和性能多模型数据库：结合多种数据库类型的特性其他数据库类型结论分享至简介数据库类型，有时也被称为数据库模型或数据库家族，是用于在数据库管理系统内组织数据的模式和结构。多年来，已经开发了许多不同的数据库类型。有些主要是当前数据库的历史前身，而另一些则经受住了时间的考验。在过去的几十年中，为了应对不断变化的需求和不同的使用模式，开发了新的类型。

你选择的数据库类型可能会对应用程序可以轻松执行的操作、你如何概念化数据以及数据库管理系统在开发和运行时为你提供的功能产生深远的影响。在本指南中，我们将探讨数据库类型如何随着时间的推移而演变，以及每种设计中存在的优点和权衡。

传统数据库：为现代系统铺平道路传统数据库类型代表了通向现代数据库道路上的里程碑。它们可能仍在某些专业环境中占有一席之地，但在生产环境中大多已被更强大的替代方案取代。

本节专门介绍在现代开发中不常用到的历史数据库类型。如果你对背景不感兴趣，可以跳到关系型数据库部分。

平面文件数据库：用于组织少量本地数据的简单数据结构在应用程序之外管理计算机数据的最简单方法是将其存储在基本的文件格式中。第一个数据管理解决方案采用了这种方法，它仍然是存储少量信息而没有严格要求的流行选择。

第一个平面文件数据库以规则的、机器可解析的结构在文件中表示信息。数据以纯文本形式存储，这限制了数据库本身可以表示的内容类型。有时，会选择一个特殊字符或其他指示符作为分隔符，或表示一个字段结束而下一个字段开始的标记。例如，在 CSV（逗号分隔值）文件中使用逗号，而在类 Unix 系统中的许多数据文件中使用冒号或空格。其他时候，不使用分隔符，而是通过固定长度定义字段，对于较短的值可以进行填充。

/etc/passwd on*nix 系统

root:x:0:0:root:/root:/bin/bashdaemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologinbin:x:2:2:bin:/bin:/usr/sbin/nologinsys:x:3:3:sys:/dev:/usr/sbin/nologinsync:x:4:65534:sync:/bin:/bin/syncgames:x:5:60:games:/usr/games:/usr/sbin/nologinman:x:6:12:man:/var/cache/man:/usr/sbin/nologinlp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologinmail:x:8:8:mail:/var/mail:/usr/sbin/nologinnews:x:9:9:news:/var/spool/news:/usr/sbin/nologinbackup:x:34:34:backup:/var/backups:/usr/sbin/nologinlist:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologinnobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologinsyslog:x:102:106::/home/syslog:/usr/sbin/nologinbob:x:1000:1000:Bob Smith,,,:/home/bob:/bin/bash/etc/passwd 文件定义了用户，每行一个。每个用户都有姓名、用户和组 ID、主目录和默认 Shell 等属性，每个属性之间用冒号分隔。

虽然平面文件数据库很简单，但它们能够处理的复杂程度非常有限。读取或操作数据的系统无法在所表示的数据之间轻松建立连接。基于文件的系统通常也没有任何类型的用户或数据并发功能。平面文件数据库通常只适用于读写要求小的系统。例如，许多操作系统使用平面文件来存储配置数据。

尽管存在这些限制，平面文件数据库仍广泛用于本地进程需要存储和组织少量数据的场景。一个很好的例子是 Linux 和其他类 Unix 系统上许多应用程序的配置数据。在这些情况下，平面文件格式充当了人类和应用程序都可以轻松读取和管理的接口。这种格式的一些优点是它具有健壮、灵活的工具，无需专业软件即可轻松管理，并且易于理解和使用。

示例

Linux 和类 Unix 系统上的/etc/passwd 和 /etc/fstabCSV 文件层次数据库：使用父子关系将数据映射到树中最初引入：20 世纪 60 年代

层次数据库是数据库管理开发的下一次演进。它们编码了项目之间的关系，其中每个记录都有一个父级。这构建了一个树状结构，可用于根据其父记录对记录进行分类。

这种简单的关系映射为用户提供了在树状结构中建立项目之间关系的能力。这对于某些类型的数据非常有用，但不支持复杂的关系管理。此外，父子关系的含义是隐含的。一个父子连接可能发生在客户和他们的订单之间，而另一个可能代表员工和他们被分配的设备。数据本身的结构并没有区分这些关系。

层次数据库是向以更复杂的术语思考数据管理迈进的开始。之后开发的数据库管理系统的发展轨迹延续了这一趋势。

由于其组织大多数数据能力有限，并且由于遍历层次结构访问数据会产生开销，层次数据库如今使用不多。然而，一些极其重要的系统可以被认为是层次数据库。例如，文件系统可以被认为是专门的层次数据库，因为文件和目录系统与单一父/多子范式完美契合。同样，DNS 和 LDAP 系统都充当层次数据集的数据库。

示例

文件系统DNSLDAP 目录网络数据库：使用非层次链接映射更灵活的连接最初引入：20 世纪 60 年代末

网络数据库在层次数据库提供的基础上增加了额外的灵活性。与层次数据库中始终只有一个父级不同，网络数据库条目可以有多个父级，这有效地允许它们建模更复杂的关系。谈论网络数据库时，重要的是要认识到网络指的是不同数据条目之间的连接，而不是不同计算机或软件之间的连接。

网络数据库可以用通用图而不是树来表示。图的含义由模式定义，模式规定了每个数据节点和每个关系所代表的内容。这以以前只能通过推断才能达到的方式为数据提供了结构。

定义：模式

数据库模式是数据库或其包含的元素的逻辑结构的描述。模式通常包括单个条目、条目组以及组成数据库条目的各个属性的结构声明。这些还可以定义数据类型和附加约束，以控制可以添加到结构中的数据类型。

网络数据库在灵活性和映射信息之间连接的能力方面取得了巨大飞跃。然而，它们仍然受到与层次数据库相同的访问模式和设计思维的限制。例如，要访问数据，仍然需要遵循网络路径到达目标记录。从层次数据库继承而来的父子关系也影响了项目之间连接的方式。

很难找到现代网络数据库系统的例子。设置和使用网络数据库需要大量的技能和专业的领域知识。大多数可以使用网络数据库近似表示的系统在关系型数据库出现后找到了更好的契合点。

示例

IDMS关系型数据库：使用表作为组织结构化数据的标准解决方案最初引入：1969 年

关系型数据库是现今仍广泛使用的最古老的通用数据库类型。事实上，关系型数据库占目前生产环境中使用的数据库的大多数。

关系型数据库使用表来组织数据。表是为它们所持有的记录强制执行模式的结构。表中的每一列都有一个名称和一种数据类型。每一行表示表中的单个记录或数据项，其中包含每一列的值。关系型数据库的名称来源于使用元组（如表中的行）来表示有序数据集的数学关系。

表中称为外键的特殊字段可以包含对其他表中列的引用。这允许数据库按需连接两个表，将不同类型的数据整合在一起。

通过严格的表结构赋予的高度组织化结构，结合表之间关系提供的灵活性，使得关系型数据库功能强大，并能适应多种类型的数据。可以在表级别强制执行一致性，但数据库操作可以以新颖的方式组合和操作数据。

虽然并非关系型数据库设计的固有部分，但一种称为 SQL（结构化查询语言）的查询语言被创建用于访问和操作以该格式存储的数据。它可以在单个语句中查询和连接来自多个表的数据。SQL 还可以过滤、聚合、汇总和限制返回的数据。因此，虽然 SQL 不是关系型系统的一部分，但它通常是使用这些数据库的基本组成部分。

定义：SQL

SQL，或结构化查询语言，是用于在关系型数据库中查询和操作数据的一系列语言。它擅长将来自多个表的数据进行组合并根据约束进行过滤，从而能够表达复杂的查询。由于其灵活性、功能和普遍性，几乎所有关系型数据库都采用了该语言的变体。

总的来说，关系型数据库通常非常适合那些规则、可预测且受益于灵活组合各种格式信息的数据。由于关系型数据库基于模式工作，因此在数据进入系统后更改数据结构可能会更具挑战性。然而，模式也有助于强制执行数据的完整性，确保值与预期格式匹配，并包含所需信息。总体而言，关系型数据库是许多应用程序的可靠选择，因为应用程序通常会生成结构良好、有序的数据。

示例

MySQLMariaDBPostgreSQLSQLiteNoSQL 数据库：不适合关系型范式的数据的现代替代方案NoSQL 是指各种现代数据库类型的总称，它们提供与标准关系型模式不同的方法。NoSQL 一词有些用词不当，因为此类别的数据库更多地是对关系型原型的反应，而不是对 SQL 查询语言的反应。NoSQL 据说代表“非 SQL”或“不仅仅是 SQL”，有时是为了澄清它们有时允许类 SQL 查询。

键值数据库：简单的字典式查找，用于基本存储和检索最初引入：20 世纪 70 年代 | 流行度上升：2000-2010 年

键值数据库，或键值存储，是最简单的数据库类型之一。键值存储通过特定键来存储可访问的任意数据。要存储数据，你需要提供一个键和要保存的数据块，例如 JSON 对象、图像或纯文本。要检索数据，你提供键，然后将返回数据块。在最基本的实现中，数据库不评估它存储的数据，并且对其交互方式有限制。

如果键值存储看起来很简单，那是因为它们确实如此。但这种简单性在它们最常部署的场景中通常是一种优势。键值存储常用于存储配置数据、状态信息以及编程语言中可能由字典或哈希表示的任何数据。键值存储提供了对这类数据快速、低复杂度的访问。

一些实现在此基础之上提供了更复杂的操作，具体取决于每个键下存储的基本数据类型。例如，它们可能能够增加数值或对列表执行切片或其他操作。由于许多键值存储将其整个数据集加载到内存中，因此这些操作可以非常高效地完成。

键值数据库不规定它们存储的任何数据模式，因此，它们通常用于同时存储许多不同类型的数据。用户负责为有助于识别值的键定义任何命名方案，并负责确保值具有适当的类型和格式。键值存储最适用于轻量级解决方案，用于存储可以在检索后外部操作的简单值。

键值数据库最流行的用途之一是存储网站和 Web 应用程序的配置值以及应用程序变量和标志。程序启动时可以检查键值存储（通常速度非常快）以获取其配置。这允许你通过更改键值存储中的数据来更改服务的运行时行为。应用程序还可以配置为定期重新检查或在看到更改时重新启动。这些配置存储通常会定期持久化到磁盘，以防止系统崩溃时数据丢失。

示例

Redismemcachedetcd文档数据库：将所有项目数据存储在灵活的自描述结构中流行度上升：2009 年

文档数据库，也称为面向文档的数据库或文档存储，共享键值存储的基本访问和检索语义。文档数据库也使用键来唯一标识数据库中的数据。事实上，高级键值存储和文档数据库之间的界限可能相当模糊。然而，文档数据库不是存储任意数据块，而是将数据存储在称为文档的结构化格式中，通常使用 JSON、BSON 或 XML 等格式。

尽管文档中的数据在结构内组织，但文档数据库不规定任何特定的格式或模式。每个文档可以具有数据库解释的不同内部结构。因此，与键值存储不同，存储在文档数据库中的内容可以被查询和分析。

在某些方面，文档数据库介于关系型数据库和键值存储之间。它们使用键值存储所知晓的简单键值语义和对数据的宽松要求，但它们也提供施加结构的能力，你可以在将来使用该结构查询和操作数据。

然而，与关系型数据库的比较不应被过分强调。虽然文档数据库提供了在文档内构建数据以及基于这些结构对数据集进行操作的方法，但可用的保证、关系和操作与关系型数据库截然不同。

文档数据库是快速开发的好选择，因为你可以在任何时候更改要保存的数据属性，而无需更改现有结构或数据。如果你愿意，只需回填记录即可。数据库中的每个文档都独立存在，拥有自己的组织系统。如果你仍在确定数据结构并且数据主要由不包含大量交叉引用的离散条目组成，那么文档数据库可能是一个不错的起点。但要小心，因为额外的灵活性意味着你需要负责维护数据的一致性和结构，这可能极具挑战性。

示例

MongoDBRethinkDB图数据库：通过关注数据之间的连接如何有意义来映射关系流行度上升：21 世纪

图数据库是一种 NoSQL 数据库，它采用不同的方法来建立数据之间的关系。图数据库不是使用表和外键来映射关系，而是使用节点、边和属性的概念来建立连接。

图数据库将数据表示为单个节点，这些节点可以具有任意数量的关联属性。在这些节点之间，建立边（也称为关系）以表示不同类型的连接。通过这种方式，数据库编码了节点内关于数据项的信息以及连接节点的边中关于它们关系的信息。

乍一看，图数据库似乎与早期的网络数据库相似。两种类型都关注项目之间的连接，并允许显式映射不同类型数据之间的关系。然而，网络数据库需要逐步遍历才能在项目之间移动，并且其表示关系的能力有限。

图数据库在处理关系或连接高度重要的数据时最有用。理解这一点很重要：当谈到关系型数据库时，“关系型”一词指的是将不同表中的信息关联起来的能力。另一方面，对于图数据库，主要目的是定义和管理关系本身。

例如，在关系型数据库中查询社交媒体网站的两个用户之间的连接可能需要多次表连接，因此资源消耗相当大。在直接映射连接的图数据库中，相同的查询将非常简单。图数据库的重点是使这种类型的数据处理直观且功能强大。

Neo4jJanusGraphDgraph列族数据库：具有灵活列的数据库，以弥合关系型数据库和文档数据库之间的差距流行度上升：21 世纪

列族数据库，也称为非关系型列存储、宽列数据库，或简称列数据库，可能是表面上与关系型数据库最相似的 NoSQL 类型。与关系型数据库一样，宽列数据库使用行和列等概念存储数据。然而，在宽列数据库中，这些元素之间的关联与关系型数据库使用它们的方式非常不同。

在关系型数据库中，模式通过指定表将具有哪些列、它们各自的数据类型以及其他条件来定义表中的列布局。表中的所有行都必须符合这种固定模式。

列族数据库没有表，而是具有称为列族的结构。列族包含数据行，每行都定义自己的格式。一行由一个唯一的行标识符（用于定位行）组成，后跟一组列名和值。

通过这种设计，列族中的每一行都定义了自己的模式。该模式可以轻松修改，因为它只影响单行数据。每行可以有不同数量的列，并包含不同类型的数据。有时，将列族数据库视为键值数据库会有所帮助，其中每个键（行标识符）返回一个包含任意属性及其值（列名及其值）的字典。

列族数据库适用于需要对基于行的操作和高可扩展性提供出色性能的应用程序。由于所有条目的数据和元数据都可以通过单个行标识符访问，因此无需计算成本高昂的连接即可查找和获取信息。数据库系统通常还确保一行中的所有数据都位于集群中的同一台机器上，从而简化了数据分片和扩展。

然而，列族数据库并非在所有场景中都表现良好。如果你的数据具有高度关系性且需要连接，那么这不是适合你应用程序的数据库类型。列族数据库牢固地围绕基于行的操作。这意味着聚合查询（如求和、求平均值和其他面向分析的流程）可能很困难或不可能。这可能对你如何设计应用程序以及可以使用哪种类型的使用模式产生重大影响。

示例

CassandraHBase时序数据库：跟踪随时间变化的值流行度上升：2010 年代

时序数据库是专注于收集和管理随时间变化的值的数据存储。尽管有时被认为是其他数据库类型（如键值存储）的一个子集，但时序数据库普遍且足够独特，值得单独考虑。

许多时序数据库被组织成记录单个项目随时间变化的值的结构。例如，可以创建一个表或类似的结构来跟踪 CPU 温度。在其中，每个值将包含一个时间戳和一个温度值，以映射在特定时间点的温度是多少。

其他实现使用时间戳作为键来一次存储多个指标或列的值。例如，这些结构将允许你使用单个时间戳存储和检索 CPU 温度、系统负载和内存使用情况的值。

在读写特性方面，时序数据库是重写导向的。它们旨在处理持续不断涌入的数据流。一般来说，时序数据库处理规则、一致的数据流，没有太多峰值，这使得规划比某些其他类型的数据更简单。性能通常取决于跟踪的项目数量、记录新值之间的轮询间隔以及需要保存的实际数据负载。

时序数据库本质上通常是仅追加的。每条传入的数据都作为与当前时间点相关联的新值存储。数据库中已有的值在摄取后通常不会被修改。由于最有价值的数据通常是最新数据，有时旧值会以较低的分辨率进行聚合、降采样和以其他方式汇总，以保持数据集的大小可管理。

时序数据库通常用于存储监控或系统性能信息。这使它们成为管理基础设施的理想选择，尤其是物联网（IoT）环境，因为物联网会生成大量数据。你可能用于监控部署环境的任何监控或警报系统都可能使用某种时序数据库。

示例

OpenTSDBPrometheusInfluxDBTimescaleDBNewSQL 数据库：为传统关系型模式带来现代可伸缩性和性能流行度上升：2010 年代

NoSQL 数据库对于数据不完全符合关系型模式的情况来说是很好的选择。由于它们是最近才开发的，NoSQL 系统往往在设计时就考虑到了可伸缩性和现代性能要求。

然而，直到最近，还没有一种解决方案可以轻松扩展关系型数据。为了解决这一需求，一种新型的关系型数据库——NewSQL 数据库——应运而生。

NewSQL 数据库遵循关系型结构和语义，但采用更现代化、可扩展的设计构建。其目标是提供比关系型数据库更高的可伸缩性，以及比 NoSQL 替代方案更强的一致性保证。它们通过牺牲在网络分区事件中一定程度的可用性来实现这一点。一致性和可用性之间的权衡是分布式数据库的一个基本问题，由CAP 定理描述。

定义：CAP 定理

CAP 定理是关于分布式数据库在可用性和一致性之间必须做出权衡的陈述。它断言，在网络分区事件中，分布式数据库可以选择保持可用性或保持一致性，但不能同时做到两者。分区网络中的集群成员可以继续操作，导致至少是暂时不一致。或者，至少一些断开连接的成员必须在分区期间拒绝更改其数据，以确保数据一致性。

为了解决可用性问题，开发了新的架构以最小化分区的影响。例如，将数据集分割成更小的范围（称为分片）可以最小化分区期间不可用的数据量。此外，根据网络条件自动更改各种集群成员角色的机制使它们能够快速恢复可用性。

由于这些特性，NewSQL 数据库最适合在分布式、类似云的环境中处理大量关系型数据的用例。

虽然 NewSQL 数据库提供了传统关系型数据库的大部分熟悉功能，但仍存在一些重要差异，使其无法完全一对一替代。NewSQL 系统通常不如其更传统的、通用的关系型数据库灵活。它们通常也只提供 SQL 全功能和关系型功能的一个子集，这意味着它们可能无法处理某些类型的使用。许多 NewSQL 实现还将大部分或整个数据集存储在计算机主内存中。这提高了性能，但代价是增加了未持久化更改的风险。

NewSQL 数据库非常适合需要超越传统关系型数据库所能提供规模的关系型数据集。由于它们实现了关系型抽象并提供了 SQL 接口，因此过渡到 NewSQL 数据库通常比迁移到 NoSQL 替代方案更简单。然而，需要记住的是，尽管它们主要旨在复制传统关系型环境，但仍然存在可能影响你部署的差异。务必研究这些差异，并找出相似性失效的情况。

示例

MemSQLVoltDBSpannerCalvinCockroachDBFaunaDByugabyteDBPlanetScale多模型数据库：结合多种数据库类型的特性流行度上升：2010 年代

多模型数据库是结合了多种数据库类型功能的数据库。这种方法的优点显而易见——同一个系统可以使用不同的表示方式来处理不同类型的数据。

将来自多种数据库类型的数据归置在同一系统中，可以实现否则难以或不可能完成的新颖操作。例如，多模型数据库可能允许用户在单个查询中访问和操作存储在不同数据库类型中的数据。多模型数据库还有助于保持数据一致性，这在一次修改多个系统数据时可能会成为问题。

在管理方面，多模型数据库有助于减轻数据库系统的运营负担。拥有一个多功能系统允许你在需求变化时更改或扩展到新的模型，而无需更改底层基础设施或学习新系统的开销。

很难将多模型数据库作为一个整体类别来讨论其特性，因为它们主要继承了它们所选择支持的数据库类型的优势。重要的是要记住，你应该评估各个实现对你所需特定数据库类型的支持程度。有些系统可能支持多种模型，但功能集不均衡或存在重要注意事项。

ArangoDBOrientDBCouchbase其他数据库类型虽然本指南没有深入探讨这些类型，但至少了解一些其他可用的数据库类型是值得的。以下数据库类型值得一提，但它们通常使用频率较低或仅在小众环境中使用

面向列的数据库： 不要与列族数据库混淆，面向列的数据库与关系型数据库非常相似，但数据在磁盘上按列而不是按行存储。这意味着单列的所有数据都存储在一起，从而可以更快地对大型数据集进行聚合。由于列是彼此独立的，插入或更新值是一项性能密集型任务，因此面向列的数据库主要用于分析工作，其中整个数据集可以一次性预加载。语义 RDF 图数据库： 语义 RDF 图数据库是使用资源描述框架映射对象的数据库。此框架是一种详细描述对象及其关系的方法，通过对数据和连接进行分类。其思想是像句子一样映射主体、动作和对象（例如，“比尔打电话给苏”）。对于大多数用例，标记属性图（通常简称为图数据库）可以更灵活、更简洁地表达关系。面向对象数据库： 面向对象数据库将数据项存储为对象，旨在弥合面向对象编程语言和数据库之间表示的差距。尽管这解决了在不同数据范式之间转换的许多问题，但从历史上看，由于复杂性增加、缺乏标准化以及难以将数据与原始应用程序分离，其采用受到了影响。结论数据库类型自最初引入以来发生了很大变化，新的数据库理念今天仍在积极开发中。现代系统使用的每种类型都具有独特的优势，值得在正确的访问模式、数据属性和要求下进行探索。启动新项目时，最重要和首要的决策之一是评估你的需求并找到与项目需求匹配的类型。

很多时候，混合使用不同类型的数据库是处理项目数据的最佳方法。你的应用程序和服务将影响生成的数据类型以及你所需的功能和访问模式。例如，你的系统中的用户信息可能最适合关系型数据库，而你服务的配置值可能受益于内存中的键值存储。了解每种数据库类型提供的功能可以帮助你识别哪些系统最适合你所有不同类型的数据。

Prisma.io 相关内容你可以在应用程序代码中使用 Prisma 更轻松地操作数据库。查看我们的数据库连接器页面，了解 Prisma 支持的所有数据库。

Prisma 是一个用于 Typescript 和 Node.js 的开源数据库工具包，旨在提高应用程序开发人员在使用数据库时的生产力和信心。关于作者Justin EllingwoodJustin 自 2013 年以来一直在撰写关于数据库、Linux、基础设施和开发工具的文章。他目前与妻子和两只兔子住在柏林。他通常不需要以第三人称写作，这对所有相关方都是一种解脱。上一页什么是数据库？下一页数据库模式简介在 GitHub 上编辑此页面