The Development of DBMS in History--人工翻译

导言

数据库类型 ，有时称为数据库模型或数据库族，是用于在数据库管理系统内组织数据的模式和结构。多年来已经开发了许多不同的数据库类型。一些主要是当前数据库的历史前辈，而另一些则经受住了时间的考验。在过去的几十年中，新的类型已经开发出来，以满足不断变化的需求和不同的使用模式。

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

遗留数据库：为现代系统铺平了道路

平面文件数据库(Flat-file databases): 用于组织少量本地数据的简单数据结构

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

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

示例：①在Linux和类Unix系统上的/etc/password 以及 /etc/fstab②CSV 文件

分层数据库(Hierarchical databases):使用父子关系将数据映射到树中

分层数据库编排元素之间的关系，每个元素都有一个父元素。构建了一个树状结构，可用于根据其父元素对元素进行分类。

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

示例：①文件系统②DNS域名系统

网络数据库(Network databases):用非分层链路映射更灵活的连接

网络数据库建立在分层数据库提供的基础上，增加了额外的灵活性。网络数据库条目可以有多个父项，而不是像分层数据库那样总是有一个父项，这有效地允许它们对更复杂的关系进行建模。当谈论网络数据库时，重要的是要认识到网络是用来指不同数据条目之间的连接，而不是不同计算机或软件之间的连接。

网络数据库用图结构去进行展现，图结构列出了每个数据节点和每个关系所表示的内容。
网络数据库在灵活性和映射信息之间联系的能力方面是一个巨大的飞跃。然而，它们仍然受到分层数据库相同的访问模式和设计思维的限制。例如，要访问数据，您仍然需要沿着网络路径访问相关记录。从分层数据库中继承下来的父子关系也影响了项目彼此连接的方式。

示例：IDMS内部数据管理系统

关系数据库：使用表去组织结构化的数据

关系型数据库使用表去组织数据，表是一种强制将所存数据进行模板化的数据结构。表的每一列都有一个名称和数据类型。表的每一行表示一条数据，每条数据包含所有列的值。

表中的特殊字段（外键）可以包含对其他表中列的引用。这允许数据库根据需要桥接两个表，以将不同类型的数据合并在一起。

严格的表结构，与表之间的关系提供的灵活性相结合，使关系数据库非常强大，适用于许多类型的数据。一致性可以在表级别强制执行，但是数据库操作可以以新的方式联合和操作数据。

一般来说，关系数据库通常非常适合任何规则的、可预测的数据，并且可以灵活地以各种方式组合数据。因为关系数据库是在模板化的基础上工作的，所以在数据存入数据库之后，再去改变数据的结构是不容易的。但是，模板化还有助于加强数据的完整性，确保值与预期的格式相匹配，并且包含所需的信息。总的来说，关系数据库是许多应用程序的可靠选择，因为应用程序通常生成有序的结构化数据。

示例：①MySQL数据库②PostgreSQL③SQLite

NoSQL数据库：不符合关系范式的数据的现代替代方案

NoSQL是现代数据库类型的各种集合的术语，这些数据库类型提供与标准关系模式不同的方法。术语NoSQL有点用词不当，因为这个类别中的数据库更多地是对关系原型的反应，而不是SQL查询语言。

键值数据库(Key-value databases)：用于基本存储和检索的简单的字典式查找

键值数据库是最简单的数据库类型之一，工作原理是存储可以通过特定的键访问的任意数据，您需要提供一个键和要保存的一块数据，例如JSON对象、图像或纯文本。要检索数据，您需要提供键，然后将返回这块数据。在大多数基础的实现中，数据库不核验它存储的数据，并且只允许有限的方式与它交互。

键值数据库通常用于存储配置数据、状态信息以及可能在程序中由字典或者哈希代表的各种数据。键值数据库提供了对这种类型数据的快速、低复杂性的访问。

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

键值数据库不为存储的数据规定任何模板，因此通常用于同时存储许多不同类型的数据。用户负责定义键的名称，以帮助识别值，并负责确保值具有适当的类型和格式。

示例：①Redis②memcached内存缓存

文档数据库(Document databases): 以灵活的自描述结构存储元素的所有数据

面向文档的数据库。类似于键值数据库，文档数据库也是使用键来唯一地标识数据库中的数据。事实上，高级键值数据库和文档数据库之间的界限可能相当模糊。然而，文档数据库不是存储任意的数据块，而是以称为文档的结构化格式存储数据，通常使用JSON、BSON或XML等格式。

虽然文档中的数据具有结构化特性，但文档数据库并不规定任何固定的结构或模板，每个文档都可以有不同的内部结构。因此，与键值数据库不同，存储在文档数据库中的内容可以被查询和分析

在某些方面，文档数据库位于关系数据库和键值数据库之间。它使用简单的键-值语义和对数据的宽松要求，这是键值数据库的特点，而且它也提供了强制模板化的能力，您可以在将来使用该模板对数据进行查询和操作

然而，文档数据库与关系数据库的比较不应该被夸大。虽然文档数据库提供了在文档中结构化数据并基于这些结构对数据集进行操作的方法，但数据一致性、数据关系和可用的数据操作与关系数据库非常不同

文档数据库是快速开发的一个很好的选择，因为您可以在任何时候更改要保存的数据的属性，而无需更改现有的结构或数据。您只用在需要时回填记录。数据库中的每个文件都有自己的组织结构。如果数据结构还没有最终确定下来，并且数据都是离散的并且不包含大量关系引用，那么文档数据库可能是一个很好的起点。但是要小心，因为额外的灵活性意味着您需要负责维护数据的一致性和数据结构，这可能极具挑战性

示例：MongoDB

图数据库(Graph databases): 映射数据间有意义的联系

图数据库 是一种NoSQL数据库，它采用不同的方法来建立数据之间的关系。图数据库不是使用表和外键来映射关系，而是使用 节点(Node) ，边(Edge) ，以及 属性(properties).

图数据库将数据表示为有任何数量属性的单个节点。在这些节点之间，使用边（也称为关系）来表示不同类型的连接。通过这种方式，数据库记录节点内部数据项以及节点与其他节点的联系的信息

乍一看，图数据库与早期的网络数据库很相似。这两种类型都关注数据元素之间的连接，并允许不同类型数据之间关系的显式映射。然而，网络数据库需要一步一步在数据元素之间遍历，并且它们可以表示的关系类型有限

在处理关系和连接非常重要的数据时，图数据库时最有用的。在讨论关系数据库时，“关系”一词指的是将不同表中的信息联系在一起的能力，理解这一点至关重要。另一方面，对于图数据库，主要目的是定义和管理关系本身

例如，在关系数据库中查询社交媒体站点的两个用户之间的连接可能需要多个表联接，因此是相当资源密集的。在直接映射连接的图数据库中，同样的查询将是直接的。图数据库的重点是使这种类型的数据的工作直观和强大。

示例：①neo4j②Dgraph

列簇数据库(Column-family databases): 具有灵活列的数据库，介于关系型数据库和文档数据库之间

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

在关系数据库中，一个模板通过指定表具有哪些列、它们各自的数据类型和其他条件来定义表中的列布局。表中的所有行都必须符合此固定模板结构

列簇数据库不使用表，而是使用称为列簇的一种结构.列簇包含数据行，每个数据行定义自己的格式。行由唯一的行标识符(用于定位行)以及列名称和值的集组成

通过这种设计，列簇中的每一行都可以定义自己的结构。这些结构可以很容易地修改，因为它只影响单行数据。每一行都可以有不同数量的列，其中可以包含不同类型的数据。有时候，可以将列簇数据库和键-值数据库进行类比，其中每个键（行标识符）返回一个多个属性及其值（列名及其值）的字典

列簇数据库适用于需要高可伸缩性和高性能的行操作的应用程序。由于数据元素的所有数据和元数据都可以用单个行标识符访问到，因此不需要计算上高消耗的join来查找和提取信息。数据库系统通常还确保一行中的所有数据都配置在集群中的同一台机器上，从而简化了数据分片和缩放。

但是，列簇数据库并不是在所有情况下都能正常工作。如果您有需要join的关系复杂的数据，则这不是适合您的应用的数据库类型。列簇数据库高度面向基于行的操作，这意味着像求和、求平均值和其他面向分析的这样的聚合查询可能很困难甚至不可能。这会对您如何设计应用程序以及可以使用什么类型的使用模式产生很大的影响。

示例：Hbase

时间序列数据库(Time series databases): 跟踪值随时间变化

时间序列数据库专注于收集和管理随时间变化的值。虽然有时被认为是其他数据库类型（如键值数据库）的子集，但时间序列数据库是流行且独特的，足以保证自己的地位。

许多时间序列数据库被当作记录单个数据元素随时间变化的值的结构。例如，可以创建表或类似结构来跟踪CPU温度。在内部，每个值将由时间戳和温度值组成，以映射特定时间点的温度。

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

就读写特性而言，时间序列数据库是严重面向写的。它们旨在处理不断涌入的传入数据。一般来说，时间序列数据库使用规则的、一致的数据流，而不会有很多尖峰，这使得它比其他类型的数据更容易规划。性能通常取决于跟踪的项目数量、记录新值之间的轮询间隔以及需要保存的实际数据负载。

时间序列数据库本质上通常是只追加的。每个传入的数据片段被存储为与当前时间点相关联的新值。已经存在于数据库中的值在储存后通常不会被修改。由于最有价值的数据通常是最新的，因此有时会对较旧的值进行聚合、降低分辨率，或者以较低的分辨率提炼总结，以保持数据集的大小可管理。

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

示例：InfluxDB流入数据库

NewSQL数据库：为传统的关系模式带来现代的可伸缩性和性能

NoSQL数据库是数据不完全符合关系模式的情况下的绝佳选择。由于NoSQL系统是最近开发的，因此它们的设计往往考虑到可扩展性和现代性能要求。

然而，直到最近，还没有解决方案可以轻松地平衡关系数据。为了满足这种需求，一种新型的关系数据库 NewSQL数据库被开发出来。

NewSQL数据库遵循关系结构和语义，但使用更现代、可扩展的设计构建。目标是提供比关系数据库更强大的可伸缩性，比NoSQL更加靠谱的一致性保证。它们通过在网络分区的情况下牺牲一定量的可用性来实现这一点。一致性和可用性之间的权衡是分布式数据库的一个基本问题：CAP定理

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

为了解决可用性问题，开发了新的体系结构来最小化分区的影响。例如，将数据集拆分为称为 碎片 可以最大限度地减少分区期间不可用的数据量。此外，基于网络条件自动改变各种集群成员的角色的机制允许它们快速恢复可用性。

由于这些特性，NewSQL数据库最适合分布式云环境中具有大量关系数据的用例。

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

NewSQL数据库非常适合需要扩展到传统关系数据库所能提供的范围之外的关系数据集。由于它们实现了关系抽象并提供了SQL接口，因此转换到NewSQL数据库通常比迁移到NoSQL替代方案更简单。然而，重要的是要记住，尽管它们主要寻求复制传统的关系环境，但存在可能影响您的部署的差异。一定要研究这些差异，并确定相似性被打破的情况

示例：MemSQL内存SQL、VoltDB电压数据库、Spanner、Calvin卡尔文、CockroachDB

多模型数据库：组合一种以上类型的数据库的特征

多模型数据库是联合了多种类型数据库的功能的数据库。这种方法的好处是显而易见的–同一个数据库系统可以对不同类型的数据使用不同的表示。

将来自多个数据库类型的数据并置在同一系统中提供一种可能性，可以进行一些非常新颖的操作。例如，多模型数据库可以允许用户在单个查询内访问和操作存储在不同数据库类型中的数据。多模型数据库还有助于维护数据的一致性，在这之前，当同时在多个系统中执行修改数据的操作时，可能会出现问题。

在管理方面，多模型数据库有助于减轻数据库系统的占用空间。拥有一个多功能的数据库系统可以让您在需求发生变化时更改或扩展到新的模型，而无需更改底层基础设施或学习新系统的开销。

很难将多模型数据库的特征作为一个集合类别来讨论，因为它们大多继承了它们选择支持的数据库类型的优点。一定要记住，您应该评估各个实现对所需特定数据库类型的支持程度。一些系统可能支持多个模型，但具有不相等的特征集或重要的警告。

示例：ArangoDB阿兰戈数据库、OrientDB东方数据库、Couchbase沙发底座

其他数据库类型

**面向列的数据库：**不要与列簇数据库混淆，面向列的数据库与关系数据库非常相似，但按列而不是按行在磁盘上存储数据。这意味着单个列的所有数据都在一起，允许更快地聚合更大的数据集。由于列是相互独立的，因此插入或更新值是一项性能密集型任务，因此面向列的数据库主要用于分析工作，其中可以一次预加载整个数据集。

**语义RDF图数据库：**语义RDF图数据库是使用资源描述框架来映射数据对象的数据库。该框架通过对数据和连接进行分类，详细描述了对象及其关系。这种数据库的思想是是映射主语、动作和宾语，就像你在句子中一样（例如，“Bill calls Sue”）。对于大多数用例，标记的属性图，通常称为图数据库，可以更灵活，更简洁地表达关系。

**面向对象的数据库：**面向对象的数据库将数据项存储为对象，寻求弥合面向对象编程语言和数据库所使用的表示之间差距。虽然这解决了在不同数据范式之间转换的许多问题，但从历史上看，由于复杂性增加、缺乏标准化以及难以将数据与原始应用程序解耦，没有被广泛采用。

结语

从数据库概念最初面世到新的数据库的想法积极发展的今天，数据库类型已经改变了很多。现代系统中使用的每种数据库类型都有独特的优势，如果有正确的访问模式、数据属性和需求，这些优势值得探索。在开始一个新项目时，最重要的决定之一是评估您的需求并找到符合项目需求的类型。

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