简介
数据库类型，有时也称为数据库模型或数据库族，是在数据库管理系统中组织数据的模式和结构。多年来，已经开发了许多不同的数据库类型。有些主要是当前数据库的历史前身，而另一些则经受住了时间的考验。在过去的几十年中，为了满足不断变化的需求和不同的使用模式，开发了新的类型。
您选择的数据库类型会对您的应用程序可以轻松执行的操作类型、您如何概念化数据以及数据库管理系统在开发和运行时为您提供的功能产生深远的影响。在本指南中，我们将了解数据库类型如何随时间演变，以及每种设计中存在的优势和权衡。
传统数据库：为现代系统铺平道路
传统数据库类型代表了通往现代数据库道路上的里程碑。这些数据库类型可能仍然在某些特定环境中找到立足点，但在生产环境中大多已被更强大的替代方案所取代。
本节专门介绍现代开发中不常用的历史数据库类型。如果您对这些背景不感兴趣，可以跳到关于关系数据库的部分。
平面文件数据库：用于组织少量本地数据的简单数据结构
在应用程序之外的计算机上管理数据的最简单方法是将其存储在基本文件格式中。数据管理的第一个解决方案使用了这种方法，并且它仍然是存储少量信息而没有繁重要求的流行选择。
第一个平面文件数据库在文件中以规则的、机器可解析的结构表示信息。数据以纯文本形式存储，这限制了可以在数据库本身中表示的内容类型。有时，会选择一个特殊字符或其他指示符用作分隔符，或用于标记一个字段何时结束以及下一个字段何时开始的标记。例如，逗号用于 CSV（逗号分隔值）文件中，而冒号或空格用于类 Unix 系统中的许多数据文件中。在其他时候，不使用分隔符，而是使用固定长度定义字段，可以为较短的值填充。
/etc/passwd 在*nix 系统上
/etc/passwd 文件定义用户，每行一个用户。每个用户都有属性，如名称、用户和组 ID、主目录和默认 shell，每个属性之间用冒号分隔。
虽然平面文件数据库很简单，但它们可以处理的复杂程度非常有限。读取或操作数据的系统无法在表示的数据之间建立轻松的连接。基于文件的系统通常也没有任何类型的用户或数据并发功能。平面文件数据库通常仅适用于读取或写入要求较低的系统。例如，许多操作系统使用平面文件来存储配置数据。
尽管存在这些限制，但平面文件数据库仍然广泛用于本地进程需要存储和组织少量数据的场景中。这方面的一个很好的例子是 Linux 和其他类 Unix 系统上许多应用程序的配置数据。在这些情况下，平面文件格式充当人类和应用程序都可以轻松读取和管理的接口。这种格式的一些优点是它具有强大而灵活的工具，无需专用软件即可轻松管理，并且易于理解和使用。
示例
/etc/passwd和/etc/fstab在 Linux 和类 Unix 系统上- CSV 文件
层次数据库：使用父子关系将数据映射到树中
首次引入：20 世纪 60 年代
层次数据库是数据库管理发展的下一个演变。它们对项目之间的关系进行编码，其中每个记录都有一个父级。这构建了一个树状结构，可用于根据记录的父记录对记录进行分类。
这种简单的关系映射为用户提供了在树结构中的项目之间建立关系的能力。这对于某些类型的数据非常有用，但不允许进行复杂的关系管理。此外，父子关系的含义是隐含的。一个父子连接可能在客户及其订单之间，而另一个可能代表员工及其已分配的设备。数据本身的结构无法区分这些关系。
层次数据库是朝着以更复杂的术语思考数据管理方向迈进的开始。之后开发的数据库管理系统的轨迹延续了这一趋势。
由于层次数据库组织大多数数据的能力有限以及通过遍历层次结构访问数据的开销，因此如今使用得不多。但是，一些非常重要的系统可以被认为是层次数据库。例如，文件系统可以被认为是专门的层次数据库，因为文件和目录系统完全符合单父/多子范式。同样，DNS 和 LDAP 系统都充当层次数据集的数据库。
示例
网络数据库：使用非层次链接映射更灵活的连接
首次引入：20 世纪 60 年代后期
网络数据库建立在层次数据库提供的基础之上，并增加了额外的灵活性。与层次数据库中始终只有一个父级不同，网络数据库条目可以有多个父级，这有效地使它们能够对更复杂的关系进行建模。在谈论网络数据库时，重要的是要意识到网络用于指代不同数据条目之间的连接，而不是不同计算机或软件之间的连接。
网络数据库可以用通用图而不是树来表示。图的含义由模式定义，该模式布局了每个数据节点和每个关系所代表的内容。这为数据提供了结构，而这种结构以前只能通过推断获得。
定义：模式
数据库模式是对数据库的逻辑结构或其包含的元素的描述。模式通常包括单个条目、条目组以及数据库条目包含的各个属性的结构声明。这些模式还可以定义数据类型和其他约束，以控制可以添加到结构中的数据类型。
网络数据库在灵活性和映射信息之间连接的能力方面向前迈进了一大步。然而，它们仍然受到与层次数据库相同的访问模式和设计思维的限制。例如，要访问数据，您仍然需要遵循网络路径到达有问题的记录。从层次数据库继承下来的父子关系也影响了项目彼此连接的方式。
很难找到现代网络数据库系统的示例。设置和使用网络数据库需要大量的技能和专业的领域知识。大多数可以使用网络数据库近似的系统在关系数据库出现后找到了更好的选择。
示例
关系数据库：使用表格作为组织结构化数据的标准解决方案
首次引入：1969 年
关系数据库是当今仍广泛使用的最古老通用数据库类型。事实上，关系数据库占目前生产中使用的大多数数据库。
关系数据库使用表格组织数据。表格是对其保存的记录强制实施模式的结构。表格中的每一列都有一个名称和一个数据类型。每一行代表表格中的单个记录或数据项，其中包含每一列的值。关系数据库的名称来源于数学关系，这些关系使用元组（如表格中的行）来表示有序的数据集。
表格中的特殊字段，称为外键，可以包含对其他表格中列的引用。这允许数据库按需桥接两个表格，以将不同类型的数据组合在一起。
由严格的表格结构赋予的高度组织化的结构，加上表格之间关系提供的灵活性，使得关系数据库非常强大，并且可以适应多种类型的数据。可以在表格级别强制执行一致性，但数据库操作可以以新颖的方式组合和操作这些数据。
虽然并非关系数据库设计所固有的，但创建了一种名为 SQL 或结构化查询语言的查询语言，用于访问和操作以该格式存储的数据。它可以查询和连接单个语句中多个表格的数据。SQL 还可以筛选、聚合、汇总和限制其返回的数据。因此，虽然 SQL 不是关系系统的一部分，但它通常是使用这些数据库的基本组成部分。
定义：SQL
SQL 或结构化查询语言是用于查询和操作关系数据库中数据的语言系列。它擅长组合来自多个表格的数据，并根据约束进行筛选，这使其可以用于表达复杂的查询。由于其灵活性、强大性和普遍性，几乎所有关系数据库都采用了该语言的变体。
总的来说，关系数据库通常非常适合任何规则、可预测且受益于以各种格式灵活组合信息的数据。由于关系数据库基于模式工作，因此在数据进入系统后更改数据结构可能更具挑战性。但是，模式还有助于强制执行数据的完整性，确保值与预期格式匹配，并包含所需的信息。总的来说，关系数据库对于许多应用程序来说都是可靠的选择，因为应用程序通常会生成有序的结构化数据。
示例
NoSQL 数据库：不适合关系范式的数据的现代替代方案
NoSQL 是各种现代数据库类型的术语，这些类型提供了与标准关系模式不同的方法。NoSQL 术语在某种程度上用词不当，因为此类别中的数据库更多的是对关系原型而不是 SQL 查询语言的反应。据说 NoSQL 代表“非 SQL”或“不仅是 SQL”，有时是为了澄清它们有时允许类似 SQL 的查询。
键值数据库：用于基本存储和检索的简单字典式查找
首次引入：20 世纪 70 年代 | 流行度上升：2000-2010 年
键值数据库或键值存储是最简单的数据库类型之一。键值存储的工作原理是存储可通过特定键访问的任意数据。要存储数据，您需要提供一个键和您希望保存的数据 blob，例如 JSON 对象、图像或纯文本。要检索数据，您需要提供键，然后将获得数据 blob 返回。在最基本的实现中，数据库不评估其存储的数据，并且允许与数据交互的方式有限。
如果键值存储看起来很简单，那是因为它们确实如此。但是，这种简单性通常是它们最常部署的场景中的优势。键值存储通常用于存储配置数据、状态信息以及任何可以用编程语言中的字典或哈希表示的数据。键值存储为此类数据提供快速、低复杂度的访问。
一些实现根据每个键下存储的基本数据类型，在此基础上提供更复杂的操作。例如，它们可能能够递增数值或对列表执行切片或其他操作。由于许多键值存储将其整个数据集加载到内存中，因此可以非常高效地完成这些操作。
键值数据库不为其存储的数据规定任何模式，因此，通常用于同时存储多种不同类型的数据。用户负责定义任何键的命名方案，这将有助于识别值，并负责确保值具有适当的类型和格式。键值存储作为一种轻量级解决方案最有用，用于存储可以在检索后在外部操作的简单值。
键值数据库最流行的用途之一是存储网站和 Web 应用程序的配置值以及应用程序变量和标志。程序可以在启动时检查键值存储（通常非常快）以获取其配置。这允许您通过更改键值存储中的数据来更改服务的运行时行为。还可以将应用程序配置为定期重新检查或在看到更改时重新启动。这些配置存储通常会定期持久化到磁盘，以防止在系统崩溃时丢失数据。
示例
文档数据库：在灵活的自描述结构中存储项目的所有数据
流行度上升：2009 年
文档数据库，也称为面向文档的数据库或文档存储，共享键值存储的基本访问和检索语义。文档数据库也使用键来唯一标识数据库中的数据。事实上，高级键值存储和文档数据库之间的界限可能相当模糊。但是，文档数据库不是存储任意数据 blob，而是以称为文档的结构化格式存储数据，通常使用 JSON、BSON 或 XML 等格式。
尽管文档中的数据在结构内组织，但文档数据库不规定任何特定格式或模式。每个文档可以具有数据库解释的不同内部结构。因此，与键值存储不同，文档数据库中存储的内容可以查询和分析。
在某些方面，文档数据库介于关系数据库和键值存储之间。它们使用键值存储已知的简单键值语义和对数据的宽松要求，但它们也提供了强制实施结构的能力，您可以使用该结构在将来查询和操作数据。
但是，不应过分强调与关系数据库的比较。虽然文档数据库提供了在文档中构建数据结构并基于这些结构操作数据集的方法，但可用的保证、关系和操作与关系数据库非常不同。
文档数据库是快速开发的不错选择，因为您可以随时更改要保存的数据的属性，而无需更改现有结构或数据。只有当您想要回填记录时才需要这样做。数据库中的每个文档都以其自己的组织系统独立存在。如果您仍在研究您的数据结构，并且您的数据主要由不包含大量交叉引用的离散条目组成，那么文档数据库可能是开始的好地方。但是，请注意，额外的灵活性意味着您有责任维护数据的一致性和结构，这可能非常具有挑战性。
示例
图数据库：通过关注数据之间连接的意义来映射关系
流行度上升：21 世纪 00 年代
图数据库是一种 NoSQL 数据库，它采用不同的方法来建立数据之间的关系。图数据库不是使用表格和外键映射关系，而是使用节点、边和属性的概念建立连接。
图数据库将数据表示为单个节点，这些节点可以具有与其关联的任意数量的属性。在这些节点之间，建立边（也称为关系）以表示不同类型的连接。通过这种方式，数据库对节点内的数据项的信息以及连接节点的边中其关系的信息进行编码。
乍一看，图数据库看起来类似于早期的网络数据库。这两种类型都侧重于项目之间的连接，并允许显式映射不同类型数据之间的关系。但是，网络数据库需要逐步遍历才能在项目之间移动，并且它们可以表示的关系类型受到限制。
当处理关系或连接非常重要的数据时，图数据库最有用。必须理解，在谈论关系数据库时，“关系”一词指的是将不同表格中的信息联系在一起的能力。另一方面，对于图数据库，主要目的是定义和管理关系本身。
例如，在关系数据库中查询社交媒体网站的两个用户之间的连接可能需要多个表格连接，因此资源消耗相当大。在直接映射连接的图数据库中，相同的查询将非常简单。图数据库的重点是使处理此类数据直观而强大。
列族数据库：具有灵活列的数据库，用于弥合关系数据库和文档数据库之间的差距
流行度上升：21 世纪 00 年代
列族数据库，也称为非关系列存储、宽列数据库或简称列数据库，可能是 NoSQL 类型中表面上看起来最像关系数据库的类型。与关系数据库一样，宽列数据库使用行和列等概念存储数据。但是，在宽列数据库中，这些元素之间的关联与关系数据库使用它们的方式非常不同。
在关系数据库中，模式通过指定表格将具有的列、它们各自的数据类型和其他条件来定义表格中的列布局。表格中的所有行都必须符合此固定模式。
列族数据库没有表格，而是具有称为列族的结构。列族包含数据行，每行都定义了自己的格式。一行由唯一的行标识符（用于定位该行）组成，后跟列名称和值集。
通过这种设计，列族中的每一行都定义了自己的模式。该模式可以轻松修改，因为它仅影响该单行数据。每一行可以具有不同数量的列和不同类型的数据。有时，将列族数据库视为键值数据库会很有帮助，其中每个键（行标识符）返回任意属性及其值（列名称及其值）的字典。
列族数据库非常适合需要行操作高性能和高扩展性的应用程序。由于可以通过单个行标识符访问条目的所有数据和元数据，因此无需进行计算密集型的连接操作即可查找和提取信息。数据库系统通常还会确保将一行中的所有数据共置在集群中的同一台机器上，从而简化数据分片和扩展。
然而，列族数据库并非在所有场景下都适用。如果您的数据具有高度关联性并需要连接操作，则这种数据库不适合您的应用程序。列族数据库主要面向行操作。这意味着诸如求和、平均和其他面向分析的过程等聚合查询可能变得困难甚至不可能。这可能会对您设计应用程序的方式以及可以使用的使用模式产生重大影响。
示例
时间序列数据库：跟踪随时间变化的值
兴起时间：2010年代
时间序列数据库是专注于收集和管理随时间变化的值的数据存储。尽管有时被认为是其他数据库类型（如键值存储）的子集，但时间序列数据库非常普及且足够独特，值得单独考虑。
许多时间序列数据库被组织成结构，用于记录单个项目随时间变化的值。例如，可以创建一个表或类似的结构来跟踪 CPU 温度。在内部，每个值将包含一个时间戳和一个温度值，以映射特定时间点的温度。
其他实现方式使用时间戳作为键来一次存储多个指标或列的值。例如，这些结构将允许您使用单个时间戳存储和检索 CPU 温度、系统负载和内存使用率的值。
在读取和写入特性方面，时间序列数据库是重写导向的。它们被设计为处理持续涌入的传入数据。通常，时间序列数据库处理规则、一致的数据流，而没有太多峰值，这使得围绕它们进行规划比其他某些类型的数据更简单。性能通常取决于正在跟踪的项目数量、记录新值的轮询间隔以及需要保存的实际数据负载。
时间序列数据库通常本质上是仅追加的。每个传入的数据片段都作为与当前时间点关联的新值存储。数据库中已存在的值通常在摄取后不会被修改。由于最有价值的数据通常是最新的，因此有时较旧的值会被聚合、降采样，并以较低的分辨率进行其他方式的汇总，以保持数据集大小可管理。
时间序列数据库通常用于存储监控或系统性能信息。这使得它们成为管理基础设施的理想选择，尤其是物联网 (IoT) 环境，这些环境会生成大量数据。您可能用于监视部署环境的任何监控或警报系统都可能使用某种类型的时间序列数据库。
示例
NewSQL 数据库：为传统关系模式带来现代可扩展性和性能
兴起时间：2010年代
NoSQL 数据库对于数据不完全符合关系模式的情况来说是非常好的选择。由于它们是最近开发的，NoSQL 系统往往在设计时就考虑了可扩展性和现代性能要求。
然而，直到最近，还没有轻松扩展关系数据的解决方案。为了解决这一需求，开发了一种称为 NewSQL 数据库 的新型关系数据库。
NewSQL 数据库遵循关系结构和语义，但使用更现代、可扩展的设计构建。目标是提供比关系数据库更高的可扩展性，以及比 NoSQL 替代方案更高的一致性保证。它们通过在网络分区事件中牺牲一定程度的可用性来实现这一点。一致性和可用性之间的权衡是分布式数据库的基本问题，CAP 定理 对此进行了描述。
定义：CAP 定理
CAP 定理是关于分布式数据库必须在可用性和一致性之间做出的权衡的陈述。它断言，在发生网络分区时，分布式数据库可以选择保持可用性或保持一致性，但不能两者兼得。分区网络中的集群成员可以继续运行，从而导致至少暂时的不一致。或者，至少一些断开连接的成员必须拒绝在分区期间更改其数据，以确保数据一致性。
为了解决可用性问题，开发了新的架构来最大限度地减少分区的影响。例如，将数据集拆分为称为 分片 的较小范围可以最大限度地减少分区期间不可用的数据量。此外，基于网络条件自动更改各种集群成员角色的机制使它们能够快速恢复可用性。
由于这些特性，NewSQL 数据库最适合在分布式、类似云的环境中使用具有大量关系数据的用例。
虽然 NewSQL 数据库提供了传统关系数据库的大部分熟悉功能，但仍存在一些重要的差异，使其无法成为一对一的替代品。NewSQL 系统通常不如其更传统的对应关系型数据库灵活和通用。它们通常也只提供完整 SQL 和关系功能的子集，这意味着它们可能无法处理某些类型的使用。许多 NewSQL 实现还在计算机的主内存中存储了大部分甚至全部数据集。这提高了性能，但代价是增加了未持久化更改的风险。
NewSQL 数据库非常适合需要扩展到传统关系数据库能力之外的关系数据集。由于它们实现了关系抽象并提供 SQL 接口，因此迁移到 NewSQL 数据库通常比迁移到 NoSQL 替代方案更直接。但是，重要的是要记住，尽管它们主要旨在复制传统的关系环境，但仍存在可能影响您部署的差异。请务必研究这些差异，并确定相似性崩溃的情况。
示例
多模型数据库：结合多种数据库类型的特性
兴起时间：2010年代
多模型数据库是结合了多种数据库类型功能的数据库。这种方法的优点显而易见——同一个系统可以为不同类型的数据使用不同的表示形式。
在同一系统中并置来自多种数据库类型的数据，可以实现原本困难或不可能实现的新颖操作。例如，多模型数据库可能允许用户在单个查询中访问和操作存储在不同数据库类型中的数据。多模型数据库还有助于维护数据一致性，这在执行一次修改多个系统中的数据的操作时可能会成为问题。
在管理方面，多模型数据库有助于减轻数据库系统的运营负担。拥有多功能系统使您可以在需求变化时更改或扩展到新模型，而无需更改底层基础设施或学习新系统的开销。
很难将多模型数据库的特性作为一个集合类别来讨论，因为它们主要继承了它们选择支持的数据库类型的优点。重要的是要记住，您应该评估各个实现对您需要的特定数据库类型的支持程度。某些系统可能支持多种模型，但功能集不均等或存在重要的注意事项。
其他数据库类型
尽管本指南没有深入介绍这些内容，但至少值得熟悉一些其他可用的数据库类型。以下数据库类型值得一提，但它们通常较少使用或在利基环境中使用
- 面向列的数据库：不要与列族数据库混淆，面向列的数据库与关系数据库非常相似，但按列而不是按行将数据存储在磁盘上。这意味着单个列的所有数据都在一起，从而可以更快地对较大数据集进行聚合。由于列彼此分离，因此插入或更新值是一项性能密集型任务，因此面向列的数据库主要用于分析工作，在分析工作中，可以一次预加载整个数据集。
- 语义 RDF 图数据库：语义 RDF 图数据库是使用资源描述框架映射对象的数据库。此框架是一种通过对数据和连接进行分类来详细描述对象及其关系的方法。其思想是像在句子中一样映射主语、动作和宾语（例如，“Bill calls Sue”）。对于大多数用例，标记属性图（通常简称为 图数据库）可以更灵活和简洁地表达关系。
- 面向对象的数据库：面向对象的数据库将数据项存储为对象，旨在弥合面向对象的编程语言和数据库使用的表示形式之间的差距。尽管这解决了在不同数据范式之间进行转换的许多问题，但从历史上看，由于复杂性增加、缺乏标准化以及难以将数据与原始应用程序分离，采用率一直受到影响。
结论
自数据库类型最初引入以来，它们已经发生了很大变化，并且今天仍在积极开发新的数据库理念。现代系统中使用的每种类型都具有独特的优势，在给定的正确访问模式、数据属性和要求下，这些优势值得探索。启动新项目时，首要且最重要的决定之一是评估您的需求并找到与您的项目需求相匹配的类型。
很多时候，混合使用不同数据库类型是处理项目数据的最佳方法。您的应用程序和服务将影响生成的数据类型以及您需要的功能和访问模式。例如，系统的用户信息可能最适合关系数据库，而服务的配置值可能受益于内存键值存储。了解每种数据库类型提供的功能可以帮助您识别哪些系统最适合您的所有不同类型的数据。
您可以使用 Prisma 更轻松地在应用程序代码中使用数据库。查看我们的数据库连接器页面，了解 Prisma 支持的所有数据库。
