什么是数据库？

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

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

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

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

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

数据更新包括任何操作，这些操作

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

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

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

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

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

存储数据并没有多大用处，除非您有一种在需要时检索它的方法。由于返回数据不会影响数据库中当前存储的任何信息，因此这些操作称为读取操作。读取操作是收集数据库中已存储数据的主要方式。

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

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

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

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

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

这组操作与任何现代应用程序常见的基本管理问题相一致。

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

通过忠实记录和重建来保护数据完整性

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

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

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

数据库必须具备足够的性能才能有用。您所需的性能特性很大程度上取决于应用程序的特定需求。每个环境在读写请求方面都有独特的平衡，您必须决定这两种类别可接受的性能意味着什么。

数据库通常在执行某些类型的操作方面比其他类型更好。操作性能特性通常反映所使用的数据库类型、数据模式或结构以及操作本身。在某些情况下，索引等功能可以创建常用数据替代的性能优化存储，从而为这些项目提供更快的检索速度。其他时候，数据库可能只是不适合所请求的访问模式。在决定所需数据库类型时，这是需要考虑的问题。

设置允许安全并发访问的流程

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

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

单独或聚合检索数据

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

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

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

这些选项有助于您清晰表达所需的数据以及最有用的格式。

本地内存或临时文件系统

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

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

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

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

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

存储和处理站点数据

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

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

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

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

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

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

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

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

管理软件配置

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

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

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

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

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

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

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

数据架构师

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

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

DBA（数据库管理员）

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

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

应用程序开发人员

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

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

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

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

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

商业智能和数据分析师

商业智能部门和数据分析师主要关注数据库系统中已经收集和可用的数据。他们致力于根据数据中的趋势和模式开发见解，以便他们可以预测未来绩效，就潜在变化向组织提供建议，并回答其他部门（如营销和销售）的数据问题。

数据分析师通常可以专门使用对数据系统的只读访问。他们运行的查询通常具有与主应用程序使用的查询截然不同的性能特征。因此，他们经常使用数据库副本，以便他们可以执行长时间运行和性能密集型聚合查询，这些查询否则可能会影响主数据库系统的资源使用。

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

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

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

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

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

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

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

保护数据访问和清理输入

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

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

一个具体的挑战是清理用户输入。清理输入意味着在操作用户提供的任何数据时采取特殊预防措施。恶意行为者利用普通用户输入机制欺骗应用程序泄露敏感数据的历史悠久。构建应用程序以防范这些场景是一项重要的技能。