什么是数据库？

数据定义控制系统中数据的形态和结构

创建和控制数据在数据库中的结构是数据库管理的重要组成部分。这可以帮助你在将数据摄取到系统之前，控制数据的形态或结构。它还允许你设置约束，以确保数据符合特定参数。

在处理高度规范化数据的数据库（如关系型数据库）中，这些定义通常被称为数据库的模式。数据库模式是数据必须如何格式化才能被特定数据库接受的严格大纲。这包括单个记录中必须存在的特定字段，以及数据类型、字段长度、最小值或最大值等值要求。数据库模式是数据库所有者影响和控制系统中存储数据最重要的工具之一。

那些重视灵活性而非规范性的数据库管理系统通常被称为无模式数据库。虽然这似乎暗示这些数据库中存储的数据没有结构，但通常情况并非如此。相反，数据库的结构由数据本身以及应用程序对数据的了解和关联决定。数据库通常仍然遵循某种结构，但数据库管理系统在强制执行约束方面的参与较少。这是一种设计选择，根据具体情况有其优点和缺点。

数据更新：从系统中摄取、修改和删除数据

数据更新包括任何以下操作：

• 向系统中录入新数据
• 修改现有条目
• 从数据库中删除条目

这些功能对于任何数据库都是必不可少的，在许多情况下，它们构成了数据库系统处理的大部分操作。这些类型的活动——即导致系统中数据发生变化的操作——统称为写入操作。

写入操作对于任何会随时间变化的数据源都非常重要。即使是删除数据这种破坏性操作，也被认为是写入操作，因为它修改了系统中的数据。

由于写入操作可以改变数据，这些操作具有潜在危险性。大多数数据库管理员会配置他们的系统，将写入操作限制在特定的应用程序进程中，以最大程度地减少意外或恶意数据损坏的可能性。例如，数据分析（利用现有数据回答关于网站性能或访客行为的问题）只需要读取权限。另一方面，应用程序中记录用户订单的部分则需要能够向数据库写入新数据。

检索数据以提取信息或回答特定问题

存储数据本身用处不大，除非你能在需要时检索它。由于返回数据不会影响数据库中当前存储的任何信息，这些操作被称为读取操作。读取操作是获取数据库中已存储数据的主要方式。

数据库管理系统几乎总是有一种通过唯一标识符（通常称为主键）访问数据的直接方式。这允许通过提供键来访问任何一个条目。

许多系统还拥有复杂的数据库查询方法，以返回符合特定条件的数据集或返回条目的部分信息。这种查询灵活性有助于数据库管理系统除了基本数据存储能力外，还能作为数据处理器运行。通过开发特定的查询，用户可以促使数据库系统只返回他们所需的信息。此功能通常与写入操作结合使用，通过记录的属性来定位和修改特定记录。

管理数据库系统以确保其顺利运行

数据库通常支持的最后一类操作是管理功能。这是一类广泛而通用的操作，旨在支持数据库环境，而不直接影响数据本身。属于此组的一些项目包括：

• 管理用户、权限、认证和授权
• 设置和维护备份
• 配置存储的后端介质
• 管理复制及其他扩展性考量
• 提供在线和离线恢复选项

这组操作与任何现代应用程序共有的基本管理问题相符。

管理操作可能不是核心数据管理功能的中心，但这些能力通常使类似的数据库管理系统脱颖而出。能够轻松备份和恢复数据、实现与现有系统挂钩的用户管理，或者扩展数据库以满足需求，这些都是在生产环境中运行必不可少的功能。未能关注这些领域的数据库往往难以在实际环境中获得采用。

通过忠实记录和重构来保障数据完整性

数据完整性是数据库系统的基本要求，无论其目的或设计如何。加载到数据库中的数据应该能够可靠地检索，而不会发生意外修改、篡改或擦除。这需要可靠的数据加载和检索方法，以及在必要时对数据进行序列化和反序列化以将其存储在物理介质上。

数据库通常依赖于在写入或检索数据时验证数据的功能，例如校验和，或者使用预写日志等技术来防止意外关机导致的问题。数据存储越分布式，数据完整性就越具挑战性，因为系统的每个部分都必须反映每个数据项当前的期望状态。这通常通过在系统中数据发生变化时，对多个成员提出更严格的要求和响应来实现。

提供满足部署环境要求的性能

数据库必须充分发挥性能才能有用。你所需的性能特征在很大程度上取决于应用程序的特定需求。每个环境对读写请求都有独特的平衡要求，你必须决定这两个类别可接受的性能标准。

数据库通常更擅长执行某些类型的操作。操作性能特征通常反映了所使用的数据库类型、数据模式或结构以及操作本身。在某些情况下，索引等功能（它为常用数据创建了性能优化的替代存储）可以为这些项目提供更快的检索。其他时候，数据库可能不适合所请求的访问模式。在决定你需要哪种类型的数据库时，这是一个需要考虑的问题。

设置进程以实现安全的并发访问

虽然这不是一个严格的要求，但实际上，数据库必须允许并发访问。这意味着多个参与方必须能够同时操作数据库。记录应该能够被任意数量的用户同时读取，并且在未被其他用户锁定时代能够写入。

并发访问通常意味着数据库必须实现其他一些基本功能，如用户账户、权限系统以及认证和授权机制。它还必须制定策略，防止多个用户同时尝试操作相同的数据。记录锁定和事务通常用于解决这些问题。

单独或聚合检索数据

数据库的基本职责之一是能够按请求检索数据。请求可能针对与单个记录关联的单个数据，也可能涉及检索许多不同记录中的数据。在大多数系统中，这两种情况都必须是可能的。

在大多数数据库中，检索期间由数据库本身提供一定程度的数据处理。这可能包括以下类型的操作：

• 按条件搜索
• 过滤和遵守约束
• 提取特定字段
• 平均、排序等

这些选项帮助你清晰地表达你想要的数据以及最有用的格式。

本地内存或临时文件系统

有时应用程序会产生无用或仅在应用程序生命周期内相关的数据。在这种情况下，你可能希望将数据保留在内存中或卸载到临时文件系统，因为一旦应用程序退出，你就不再需要它了。对于数据永无用处的情况，你可能希望完全禁用输出或将其记录到/dev/null。

将应用程序数据直接序列化到本地文件系统

数据库可能不需要的另一种情况是，少量数据可以直接序列化和反序列化。这仅适用于数据量小、使用模式可预测且几乎不涉及并发的情况。这种方法扩展性不佳，但对于某些情况（例如输出本地日志信息）可能很有用。

将文件类对象直接存储到磁盘或对象存储

有时，来自应用程序的数据可以直接写入磁盘或替代存储，而不是存储到数据库中。例如，如果数据已经组织成面向文件的格式（如图像或音频文件），并且不需要额外的元数据，那么将其直接存储到磁盘或专用对象存储中可能最简单。

存储和处理站点数据

数据库的主要用途之一是存储和处理与站点相关的数据。这些项影响站点信息的组织方式，并且在许多情况下，构成了站点的主要“内容”。

在上述示例应用程序中，数据库将填充站点的绝大部分内容，包括产品信息、库存详情和用户配置文件信息。这意味着每次需要显示产品列表、产品详情页面或用户配置文件时，都将查询数据库或某个中间缓存。

数据库还会在显示当前和历史订单、计算运费以及通过检查折扣代码或计算常客奖励来应用折扣时涉及。我们的示例站点将使用数据库系统通过结合产品信息、库存和用户信息来正确构建订单。订单中记录的复合信息将再次存储在数据库中，以跟踪订单处理、允许退货、取消或修改订单，或提供更好的客户支持。

分析信息以帮助做出更好的决策

上一类别的操作与网站的基本功能有关。虽然这些对于处理应用程序层的数据需求非常重要，但它们并未涵盖全貌。

一旦你的Web应用程序开始注册用户和处理订单，你可能希望能够回答关于不同产品销售情况、哪些用户最有利可图以及哪些因素影响你的销售等详细问题。这些是可以在任何时候运行的分析性问题，用于收集关于组织趋势和业绩的最新情报。

这些类型的操作通常被称为商业智能或分析。它们共同帮助组织了解过去发生的事情并做出明智的改变。数据库系统存储这些过程中使用的大部分数据，并且必须提供适当的工具或查询能力来回答相关问题。

在我们的示例应用程序中，可以查询数据库来回答关于产品趋势、用户注册数量、我们主要发货到哪些州，或者谁是我们最忠实的用户等问题。这些相对基本的查询可以用于组成更复杂的问题，以便更好地理解和控制影响产品性能的因素。

管理软件配置

某些类型的数据库被用作网络上其他软件的配置值存储库。它们作为网络上配置值的中央真实来源。当新服务启动时，它们被配置为在配置数据库的网络地址处检查特定键的值。这使你能够将引导服务所需的所有信息存储在一个位置。

引导完成后，应用程序可以配置为监视与其配置相关的键的变化。如果检测到更改，应用程序可以重新配置自身以使用新配置。这个过程有时由一个管理过程协调，通过在新服务启动时逐渐关闭旧服务，随着时间推移更改活动配置以保持可用性，从而逐步推出新值。

我们的应用程序可以使用这种类型的数据库来存储整个应用程序环境的持久配置数据。我们的应用服务器、Web服务器、负载均衡器、消息队列等都可以配置为引用配置数据库以获取其生产设置。应用程序的开发者随后可以在一个中心位置通过调整配置值来修改环境的行为。

收集日志、事件及其他输出

正在积极处理请求的运行中应用程序会产生大量输出。这包括日志文件、事件及其他输出。这些数据可以写入磁盘或其他非受管位置，但这限制了它们的有用性。将此类数据收集到数据库中，可以更方便地处理、发现模式，并在发生意外情况或需要了解更多历史性能时分析事件。

我们的示例应用程序可以将每个系统的日志收集到一个数据库中，以便于分析。这可以帮助我们找到事件之间的关联，从而分析问题根源或了解我们整个环境的健康状况。

另外，我们可能将基础设施和代码产生的指标收集到时序数据库中，这是一种专门设计用于跟踪随时间变化的数值的数据库。该数据库可以用于支持实时监控和可视化工具，为应用程序的开发和运营团队提供有关性能、错误率等方面的信息。

数据架构师

数据架构师负责数据库系统的整体宏观结构、它们向应用程序和开发团队公开的接口，以及满足组织数据需求所需的基础技术和基础设施。

担任此角色的人员通常决定用于不同应用程序的适当数据库模型和实现。他们负责通过研究选项、决定技术、与现有系统集成以及为组织开发全面的数据策略来实施数据库决策。他们全面处理数据系统，并参与决定和实施各种项目的数据模型。

DBA（数据库管理员）

数据库管理员（或DBA）是负责确保数据系统平稳运行的人员。他们负责规划新的数据系统、安装和配置软件、为其他方设置数据库系统以及管理性能。他们还经常负责保护数据库安全、监控问题以及调整系统以优化使用模式。

数据库管理员是单个数据库系统以及如何将其与底层操作系统和硬件良好集成以最大化性能的专家。他们与使用数据库的团队广泛合作，帮助管理容量和性能，并协助团队解决数据库系统的问题。

应用程序开发者

应用程序开发者以多种不同方式与数据库交互。他们开发了许多与数据库交互的应用程序。这非常重要，因为这些应用程序几乎总是唯一控制单个用户或客户如何与数据库系统管理的数据交互的应用程序。性能、正确性和可靠性对应用程序开发者而言极其重要。

开发者管理与其应用程序相关的数据结构，以便将数据持久化到磁盘。他们必须创建或使用能够将他们的编程数据映射到数据库系统的机制，以便组件能够协同工作。随着应用程序的变化，他们必须保持数据库系统内的数据和数据结构同步。我们将在文章后面更详细地讨论开发者如何使用数据库。

SRE（站点可靠性工程师）和运维专业人员

SRE（站点可靠性工程师）和运维专业人员从基础设施和应用程序配置的角度与数据库系统交互。他们可能负责预置额外容量、搭建数据库系统、确保数据库配置符合组织指南、监控正常运行时间以及管理备份。

在许多方面，这些人员与DBA的职责有重叠，但他们并非只专注于数据库。运维人员确保组织其他部门所依赖的应用程序系统（包括数据库系统）可靠运行且停机时间最短。

商业智能和数据分析师

商业智能部门和数据分析师主要关注数据库系统中已收集和可用的数据。他们致力于根据数据中的趋势和模式得出洞察，以便预测未来表现，就潜在变化向组织提供建议，并为市场和销售等其他部门回答有关数据的问题。

数据分析师通常只对数据系统拥有只读访问权限。他们运行的查询通常与主应用程序使用的查询具有显著不同的性能特征。因此，他们经常使用数据库副本（或复制品），以便能够执行可能影响主数据库系统资源使用量的长时间运行且性能密集型的聚合查询。

在应用程序和数据库之间转换数据

你需要创建或使用现有接口来与数据库通信。你可以使用常规网络函数直接连接数据库，利用简单的库，或者使用更高级的编程库（例如查询构建器或ORM）。

ORM，即对象关系映射器，是映射层，用于将关系数据库中的表转换为面向对象编程语言中使用的类，反之亦然。虽然这种转换通常很有用，但它从不完美。对象关系阻抗失配是一个术语，用于描述关系数据库和面向对象程序在数据结构方式上的差异所导致的摩擦。

尽管关系型数据库和面向对象编程描述了两种特定的设计选择，但应用程序层和数据库层之间的转换问题是一个普遍存在的问题，无论数据库类型或编程范式如何。数据库抽象层是负责在这两个上下文之间进行转换的软件的更通用术语。

保持结构变化与数据库同步

在你开发应用程序时会发现一个重要事实：由于数据库存在于你的代码库之外，因此它需要特别关注以应对数据结构的变化。这个问题在某些数据库设计中比其他设计更常见。

将应用程序数据结构与数据库同步的最常见方法是一个称为数据库迁移或模式迁移（两者通俗地都简称为迁移）的过程。迁移涉及更新数据库的结构，以反映应用程序数据模型演变时的变化。这些通常以一系列文件的形式出现，每个演变一个文件，其中包含将数据库转换为新格式所需的语句。

保护数据访问和清理输入

作为开发者，在使用数据库时的一个重要职责是确保你的应用程序不允许未经授权的数据访问。数据安全是一个广泛的、多层次的问题，涉及许多利益相关者。最终，某些安全考量将是你的职责范围。

你的应用程序将需要特权访问数据库以执行日常任务。为了安全起见，数据库的授权框架可以帮助限制你的应用程序可以执行的操作类型。但是，你需要确保你的应用程序适当限制这些操作。例如，如果你的应用程序管理用户配置文件数据，你必须防止用户通过操纵访问权限来查看或编辑其他用户的信息。

一个具体的挑战是清理用户输入。清理输入意味着在操作用户提供的任何数据时采取特殊预防措施。恶意行为者利用正常的​​用户输入机制欺骗应用程序泄露敏感数据有着悠久的历史。设计你的应用程序以防止这些情况发生是一项重要的技能。