Day28-01｜6.1.1 数据库技术的发展：从文件管理到云原生数据架构

本文对应《系统架构设计师教程（第2版）》第6章“数据库设计基础知识”6.1.1“数据库技术的发展”。数据库技术的发展不是简单地把旧数据库替换成新数据库，而是随着数据规模、数据类型、并发访问、业务模式、网络环境和一致性要求变化，逐步形成了不同的数据组织、管理和服务方式。系统架构师需要理解这些阶段背后的问题与解决思路，才能在案例题中判断何时使用关系数据库、分布式数据库、NoSQL、数据仓库或云数据库。

一、学习目标与考试定位

完成本节后，应能够梳理数据库技术从人工管理、文件系统、数据库管理系统、分布式数据库到云数据库和大数据平台的发展脉络；理解每个阶段试图解决的核心问题；能够比较数据独立性、共享性、一致性、扩展性、可用性和管理成本；能够解释关系数据库、NoSQL、数据仓库、数据湖和云原生数据服务的适用场景；能够在案例分析和论文中根据业务约束做出有依据的数据架构选择。

本节常见考法并不是要求背诵年份，而是给出系统演进背景，让考生判断技术选择。例如：多个应用各自保存客户数据，导致更新不一致；数据量和访问量增长后单机数据库成为瓶颈；互联网业务需要灵活保存半结构化数据；分析查询影响在线交易；云环境要求弹性扩缩容和高可用。答题时要说明旧方案的问题、目标约束、候选方案、关键机制和代价。

二、数据库技术演进的主线

数据库技术大致经历了人工管理、文件系统、数据库系统、分布式数据库、面向对象和多媒体数据库、NoSQL 与大数据平台、云数据库与云原生数据架构等阶段。不同阶段并非完全替代，很多系统今天仍然使用文件、关系数据库和分布式存储的组合。

可以用下面的主线记忆：

从“程序自己管理数据”走向“数据库统一管理数据”，再走向“数据服务化、分布式化、弹性化和智能化”。

三、人工管理阶段

在计算机广泛应用之前，数据主要由人工登记、分类、统计和查找。即使已经使用早期计算设备，数据也可能通过纸带、卡片或批量介质保存。这个阶段的特点是数据规模较小、处理周期长、访问主体少，系统重点是保存和计算，而不是多用户共享。

人工管理的主要缺点包括数据录入和维护效率低，容易产生丢失、重复和错误；数据更新不能及时反映现实；不同部门使用各自的记录，难以汇总；数据查询依赖熟悉业务的人，缺少统一的检索和校验机制。随着组织业务扩大，人工数据处理不能满足实时性和准确性要求，文件系统应运而生。

从架构角度看，人工管理阶段已经隐含了数据治理问题：谁负责数据、数据的来源是什么、怎样校验、怎样备份、谁可以查看和修改。现代系统虽然使用更强的工具，但这些治理问题仍然存在。

四、文件系统阶段

文件系统把数据保存在磁盘文件或其他存储介质中，由应用程序负责定义记录格式、读写方式、索引和校验。相对于人工管理，它提高了处理速度，能够支持批量计算和一定程度的自动化。早期工资、库存、学生档案和财务系统都可能采用文件方式。

但是，文件系统通常存在数据与程序高度依赖的问题。记录格式、字段位置和访问逻辑写在应用程序中，文件结构一旦变化，多个程序都可能需要修改。文件之间缺少统一的关系和约束，应用程序各自维护客户、部门或商品数据，容易形成冗余和不一致。

文件系统还存在数据孤立和共享困难。一个应用生成的文件未必能被另一个应用直接理解；即使共享同一文件，也可能产生并发写入冲突。安全控制、恢复、事务和备份常由各个程序自行实现，难以统一管理。

文件系统适用于简单、单用户、批处理或交换场景，例如日志归档、临时导入文件、静态资源和数据交换文件，但不适合让多个业务程序长期共同维护核心主数据。架构师应区分“文件作为接口或归档格式”和“文件作为在线核心数据源”，两者的风险完全不同。

五、数据库管理系统阶段

数据库管理系统（DBMS）是位于应用程序和数据之间的系统软件，负责数据定义、存储、检索、更新、事务、并发控制、安全、备份恢复和完整性维护。它把原来散落在应用程序中的通用数据管理能力集中起来，使多个应用能够按照统一规则访问共享数据。

1. 数据共享与集中管理

DBMS 允许多个用户和应用访问同一数据库，减少各自维护相同数据造成的冗余。客户基本信息、商品目录和组织结构可以成为受控的共享数据源，由授权的业务流程维护。

2. 数据独立性

数据独立性是数据库系统的重要价值。物理数据独立性是指存储结构、索引、分区或文件组织变化时，尽量不影响应用程序；逻辑数据独立性是指逻辑模式发生一定变化时，外部视图和应用可以通过映射保持相对稳定。数据独立性降低了程序对存储细节的依赖，为系统演进提供空间。

3. 完整性与一致性

DBMS 可以通过实体完整性、参照完整性、用户定义约束、事务和并发控制保证数据满足规则。例如订单明细必须引用存在的订单，商品数量不能为负，扣款和订单状态更新要满足事务条件。完整性约束应尽量在合理层次落实，关键规则不能只依赖界面校验。

4. 并发控制与恢复

多个用户同时读写数据时，DBMS 通过锁、时间戳、多版本并发控制等机制协调操作，避免脏读、丢失更新和不可重复读等问题。事务日志、检查点、备份和恢复机制则用于应对进程故障、介质故障和系统崩溃。

5. 数据库阶段的新问题

集中式数据库解决了共享和管理问题，但随着数据量、用户数和地域范围增长，单机数据库可能面临 CPU、内存、磁盘、网络、连接数和维护窗口瓶颈。系统也需要更高可用性、更低延迟和跨地域容灾，于是分布式数据库和多种数据服务逐渐发展。

六、分布式数据库阶段

分布式数据库把数据和处理能力分布到多个通过网络连接的节点上，对外提供相对统一的数据库服务。分布式设计可以通过分片扩展容量和吞吐，通过副本提高可用性，通过就近部署降低访问延迟。

1. 分片与复制

分片把逻辑数据划分到不同节点，例如按租户、地域或哈希范围分布；复制把同一数据保存到多个节点，以支持读扩展和故障切换。分片键选择会影响数据倾斜、跨分片查询、事务范围和扩容难度；副本策略会影响一致性、存储成本和写入延迟。

2. 分布式事务与一致性

数据跨节点后，事务不再只是单机内部操作。系统需要考虑网络延迟、节点故障、消息重复、部分成功和脑裂。一致性要求可以通过强一致、最终一致或业务补偿实现，但选择不是一句“保证一致性”就结束，需要明确哪些数据必须强一致，哪些场景允许短暂不一致。

3. CAP 与架构权衡

在分布式系统发生网络分区时，通常需要在一致性和可用性之间做取舍，不能同时无条件保证三者。CAP 不是说系统平时只能选择两个特性，也不是所有架构决策都能简单归结为 CAP。架构师应结合故障模型、业务容忍度和恢复机制说明选择。例如账户余额、库存扣减对一致性要求高；推荐列表、统计看板可能接受短暂延迟。

4. 分布式数据库的代价

分布式数据库引入网络依赖、运维复杂度、数据倾斜、跨节点查询、时钟和故障处理问题。若业务规模并不需要分布式能力，盲目分片可能使系统复杂度超过收益。架构师要以容量、可用性、地域、合规和团队能力为依据，而不是把“分布式”当作先进性的同义词。

七、面向对象、对象数据库和多媒体数据

随着软件系统采用面向对象方法，复杂对象、继承、封装和对象关系映射问题受到关注。对象数据库尝试直接保存对象及其关系，减少对象到关系表之间的转换。多媒体应用又带来图像、音频、视频和空间数据等大对象及非结构化内容的管理需求。

在实际架构中，关系数据库仍常用于结构化元数据、事务和索引，多媒体文件通常进入对象存储或文件存储，数据库保存标识、权限、摘要、标签和生命周期信息。这样可以避免把大文件全部塞进在线事务表，同时利用数据库的事务能力管理文件元数据。架构师应根据访问模式、容量、备份、合规和检索需求选择组合，而不是简单争论“文件还是数据库”。

八、NoSQL 与大数据平台

互联网业务产生大量半结构化、非结构化、流式和高并发数据，传统关系模型在灵活性、水平扩展或特定访问模式上可能存在不足，于是出现键值数据库、文档数据库、列族数据库和图数据库等 NoSQL 类型。

键值数据库适合按照唯一键快速读取，例如会话、缓存和配置；文档数据库适合结构较灵活、以聚合文档访问的业务；列族数据库适合海量宽表、写入量大和按列族访问的场景；图数据库适合关系遍历、路径和网络分析。NoSQL 并不等于没有任何约束或不需要设计，数据模型通常要围绕访问模式设计，应用需要承担更多一致性、关联和生命周期责任。

大数据平台把分布式文件系统、批处理、流处理、数据仓库、数据湖、消息系统和分析引擎组合起来，用于海量数据采集、存储、计算和分析。在线事务库和分析平台往往通过日志、消息或数据同步解耦，避免复杂分析直接压垮交易系统。

九、云数据库与云原生数据架构

云数据库以服务方式提供数据库能力，平台负责部分或大部分部署、备份、补丁、监控、扩缩容和故障切换。云原生数据架构进一步强调服务化、自动化、弹性、可观测、按需使用和计算存储分离。

云数据库降低了基础设施运维门槛，但不等于架构师不再需要设计。仍需评估区域和可用区、网络延迟、备份恢复、服务等级、数据安全、成本、供应商锁定、配额、连接管理和故障退出方案。多云或混合云场景还要考虑数据迁移格式、接口兼容和跨云复制。

计算存储分离能够让计算节点和存储容量独立扩展，适合分析和弹性负载；但网络访问成为关键依赖，缓存、数据局部性和带宽成本需要重新设计。云上的自动扩缩容也必须配合连接池、限流、热点保护和容量上限，否则扩容可能把压力传递给下游数据库。

十、数据库技术演进中的不变原则

虽然数据库技术不断变化，但几项原则长期有效。第一，数据必须有明确的所有者、口径和生命周期；第二，核心业务规则和一致性边界必须清楚；第三，访问模式决定数据模型和索引；第四，备份不等于可恢复，恢复必须被演练；第五，安全要覆盖身份、授权、加密、审计和脱敏；第六，性能优化必须以测量和容量模型为依据；第七，技术选择要考虑团队能力、成本和退出路径。

架构师还要警惕技术名词驱动。把所有数据迁移到 NoSQL，不一定解决查询和一致性问题；把所有业务拆成分布式数据库，不一定提高可用性；使用云数据库，也不代表默认具备合规、低延迟和无限扩展能力。正确做法是从业务场景、质量属性和数据生命周期出发，选择必要的能力。

十一、案例分析：交易系统与分析系统的数据架构演进

某零售企业早期使用单个关系数据库支撑订单、库存、会员和报表。业务发展后，报表查询经常占用大量资源，促销期间订单响应变慢；不同分公司又建立了本地数据库，客户资料出现重复和口径不一致。企业计划“一次性改造成分布式 NoSQL 平台”，但团队没有明确事务边界、数据主责和迁移方案。

问题分析

当前问题包含在线交易与分析负载耦合、组织数据孤岛、主数据缺少统一治理和容量增长带来的性能压力。直接全量迁移到 NoSQL 可能破坏订单、库存和支付之间的事务语义，且不能自动解决数据口径问题。技术选型应先解决职责、访问模式和边界，再选择存储技术。

建议方案

保留关系数据库作为核心交易系统的权威数据源，重新设计索引、分区、读写分离或分片，并明确订单、库存和支付的事务边界。通过 CDC、消息或批流一体同步将经过治理的数据送入数仓或分析平台，报表查询与交易库隔离。会员和商品等主数据建立统一标识、数据标准和同步规则；对会话、缓存和高并发查询按场景引入键值或文档存储。迁移前进行容量、性能、一致性和恢复验证，采用灰度、双写校验、对账和可回退方案。

十二、综合知识练习与详细答案

练习一

某团队认为“分布式数据库一定比集中式数据库先进”，要求将一个用户数很少的内部系统改造成多节点分片架构。请评价。

参考答案：该观点片面。分布式数据库适合容量、吞吐、可用性、地域和弹性等需求达到一定规模的场景，但会引入网络、分片、复制、跨节点事务、运维和一致性复杂度。内部系统若规模小、事务边界清晰、单机能力足够，集中式关系数据库可能更经济可靠。应先进行容量和故障目标分析，再比较集中式扩展、主从、集群、分片等方案，说明收益、成本和团队能力。

练习二

某系统将订单和报表放在同一个数据库中，报表查询导致订单超时。请给出数据库架构改进方向。

参考答案：应将在线事务负载和分析负载解耦。交易库继续承担订单写入和核心一致性，分析数据通过日志、消息或增量同步进入数仓、数据湖或只读分析库；按业务需要采用读写分离、报表副本、缓存、预聚合和查询限流；明确同步延迟、数据校验、失败重试、补偿和监控；不能直接复制生产库而不考虑一致性、权限和资源隔离。

练习三

某互联网业务采用文档数据库保存订单，开发人员把所有关联数据嵌套到一个超大文档中，更新和查询都变慢。应如何分析？

参考答案：文档模型应围绕访问模式和聚合边界设计，超大文档会造成读写放大、并发冲突、版本膨胀和局部更新成本增加。应区分必须原子更新的字段与可独立维护的实体，合理嵌入或引用；为高频查询建立合适索引和冗余视图，控制文档大小和生命周期；对订单、库存、支付等核心边界重新评估一致性和事务需求，不能因为使用 NoSQL 就忽略数据约束。

十三、论文写作素材

论文可以这样描述数据库架构演进：面对早期系统中交易与报表耦合、数据冗余和访问量增长问题，我首先梳理业务数据的所有权、生命周期、读写模式、一致性边界、容量和质量属性，而不是直接选择某种流行数据库。对订单、库存、支付等核心交易数据保留关系模型和事务约束，通过索引、分区、读写分离或合理分片提升能力；对会话、缓存和灵活聚合数据根据访问模式引入合适的 NoSQL 服务；通过消息、日志或增量同步将数据送入分析平台，隔离在线负载和分析负载。

在分布式和云环境中，我重点评估分片键、数据倾斜、复制、一致性、故障切换、备份恢复、网络延迟、成本和供应商锁定，明确强一致与最终一致的业务边界。迁移过程中采用数据标准、主数据治理、双写校验、增量对账、灰度切换和回滚方案，使用容量压测、故障演练和恢复验证确认质量目标。通过监控延迟、错误率、复制滞后、热点、资源使用和数据一致性，持续调整架构，确保技术演进服务于业务目标。

十四、今日复盘

数据库技术发展可以概括为：人工管理效率低，文件系统解决自动化但带来数据孤立，DBMS 解决共享、独立性、完整性、并发和恢复，分布式数据库解决容量、可用性和地域扩展，NoSQL 和大数据平台适应海量、灵活和多样化数据，云数据库进一步提供弹性和服务化能力。每一步都解决了部分问题，也引入了新的代价。

答题时要形成“业务场景—数据特征—质量目标—技术方案—风险与治理”的链条。关系数据库、NoSQL、数仓、数据湖和云服务不是相互排斥的标签，关键是明确权威数据源、事务边界、访问模式、同步机制、恢复目标和退出路径。

记忆主线：

文件管理 → DBMS 共享管理 → 分布式扩展 → 多模型与大数据 → 云数据库服务化；技术随问题演进，架构必须保留边界、治理和验证。

下一篇继续 6.1.2 数据模型，重点掌握层次模型、网状模型、关系模型、面向对象模型以及概念、逻辑和物理数据模型之间的联系。