主题
第六章 数据库技术发展与新型架构
📖 ⏱️ 预计阅读时长 1 分钟 👑 会员专属
1. 分布式数据库系统
随着互联网应用规模的持续增长和企业全球化布局的深入，单台数据库服务器无论在存储容量还是计算能力上都已难以满足大规模数据管理的需求。分布式数据库系统 (Distributed Database System, DDBS) 通过在计算机网络上将数据分布存储在多个物理节点上，同时为用户提供逻辑上统一的数据访问接口，成为支撑现代大规模应用的核心技术方案之一。
1.1 分布式数据库的基本特征
分布式数据库系统具有以下三个基本特征。
第一是物理分布性。数据不集中存储在单一节点上，而是分散在网络中的多个节点上。各节点可能位于同一机房内的不同服务器上，也可能分布在不同城市甚至不同国家的数据中心中。
第二是逻辑整体性。尽管数据在物理上是分散存储的，但从用户的角度来看，整个系统呈现为一个逻辑统一的数据库。用户在提交查询时无需指定数据存储在哪个节点，系统会自动将查询路由到相应的节点执行并合并结果。
第三是场地自治性。每个参与分布式系统的节点都具备独立的数据处理能力，可以独立执行本地事务。每个节点运行着自己的局部 DBMS，能够管理本地数据并处理本地查询。
1.2 数据分片
为了将关系合理地分布到多个节点上，需要对关系进行分片处理。分片是将一个全局关系分割为若干片段（子集）的过程，每个片段存储在一个或多个节点上。
水平分片 (Horizontal Fragmentation) 按行将关系分成若干不相交的子集。每个子集中的元组满足某个选择条件。例如可以按照地区将订单表分片，华东地区的订单存储在上海节点，华南地区的订单存储在广州节点。水平分片在逻辑上等价于对关系执行若干次选择操作，每次选择的结果构成一个片段。
垂直分片 (Vertical Fragmentation) 按列将关系分成若干子集。每个子集包含原关系的一部分属性，但必须包含主键列以保证后续能够通过自然连接重构原关系。垂直分片在逻辑上等价于对关系执行投影操作。例如可以将员工表的基本信息（编号和姓名和部门）和薪资信息（编号和基本工资和绩效奖金）分别存储在不同的节点上。
混合分片则是水平分片和垂直分片的组合，先进行一种分片再对结果进行另一种分片。
无论采用哪种分片方式，都需要满足三个条件。完备性条件要求原关系中的每一条数据都必须能在某个片段中找到，不能有数据遗漏。可重构性条件要求通过对各片段执行相应的操作（水平分片用并操作重构，垂直分片用自然连接重构）能够精确还原出完整的原关系。不相交条件（对于水平分片）要求各片段之间没有重叠的元组。
分片设计最常见的误区，是只从“能不能把数据拆开”来思考，而没有从“最常怎样访问数据”来思考。事实上，分片方案一旦确定，就会长期影响查询路由、跨节点通信、热点分布和后续扩容成本。若按地区分片，但大量查询都跨地区汇总，就会频繁发生跨分片聚合；若按时间分片，但新写入都集中在最近时间段，就可能形成写热点。因此，分片不是单纯的存储拆分问题，而是访问模式、增长模式和治理策略的综合设计问题。
1.3 分布透明性
分布透明性是衡量分布式数据库系统对用户隐藏数据分布细节程度的重要指标。按照透明程度从高到低依次为以下三个层次。
分片透明性是最高层次的透明性。具有分片透明性的系统使用户完全不需要知道数据是否被分片以及如何分片。用户可以直接使用全局关系名进行查询，就像操作一个普通的集中式数据库一样。系统自动将用户的全局查询分解为针对各个片段的子查询并合并结果。
位置透明性是次一级的透明性。用户需要知道数据被分成了哪些片段，但不需要知道每个片段具体存储在哪个物理节点上。用户在查询时需要使用片段名而不是全局关系名，但系统负责将片段名映射到具体的存储位置。
局部数据模型透明性是最低层次的透明性。用户不仅需要知道数据的分片方案，还需要知道各片段的存储位置，但不需要了解各个节点上使用的具体 DBMS 类型和数据模型。
从更高层看，分布式数据库的发展其实一直围绕三个长期问题展开：数据规模变大后如何继续扩展，系统节点变多后如何继续保持正确，组织协作复杂后如何继续保持治理。分布透明性之所以重要，不只是为了让用户“少写几行定位语句”，更是为了避免业务逻辑被底层部署细节绑死。透明性的层次越高，应用越容易把系统当作统一数据库使用；但透明性越高，数据库内核需要承担的路由、重写、合并与故障处理责任也越重。这说明分布式能力从来不是白得的，它本质上是在把复杂性从应用侧转移到数据库系统内部。
2. 分布式事务处理
分布式环境下的事务可能涉及多个节点上的数据操作，这使得保证事务原子性的难度大大增加。
2.1 两阶段提交协议 (2PC)
2PC 是分布式事务中最经典的原子提交协议，由一个协调者和多个参与者共同执行。
在第一阶段（称为投票阶段或准备阶段），协调者向所有参与者发送准备提交的请求。每个参与者在收到请求后执行事务操作，将修改写入本地的日志文件，但并不真正提交。如果参与者的本地操作一切正常，它向协调者反馈同意投票。如果本地操作出现问题，则反馈中止投票。
在第二阶段（称为执行阶段），协调者根据收集到的投票结果做出全局决策。如果所有参与者都投了同意票，协调者向所有参与者发出提交指令。如果有任何一个参与者投了中止票或超时未响应，协调者向所有参与者发出回滚指令。参与者收到指令后执行相应的提交或回滚操作，并向协调者发送确认。
2PC 虽然概念清晰，但存在两个主要问题。一是同步阻塞问题：在等待协调者发出最终决策的过程中，所有参与者都必须保持其已加锁的资源处于锁定状态，无法被其他事务使用，这会降低系统的整体并发能力。二是协调者单点故障问题：如果协调者在发出准备请求之后、发出最终决策之前崩溃，所有参与者将无限期地处于不确定状态，不知道应该提交还是回滚。
2.2 三阶段提交协议
三阶段提交协议在两阶段提交的基础上引入了一个额外的预提交阶段，形成 canCommit、preCommit 和 doCommit 三个阶段。同时在各阶段引入了超时机制。当参与者在等待协调者指令时超时，可以根据当前所处的阶段做出默认决策（例如在预提交阶段超时则默认提交），在一定程度上缓解了协调者单点故障导致的参与者无限期阻塞问题。但三阶段协议增加了一轮网络通信的开销。
2.3 CAP 定理
CAP 定理由 Eric Brewer 于 2000 年提出，指出在一个分布式系统中，一致性 (Consistency)、可用性 (Availability) 和分区容忍性 (Partition Tolerance) 三个特性不可能同时完全满足，最多只能同时保证其中两个。
一致性要求所有节点在同一时刻看到的数据完全相同。可用性要求系统对每一个请求都能够在有限时间内给出非错误的响应。分区容忍性要求系统在网络分区（即节点之间的通信链路发生中断）的情况下仍能继续提供服务。
由于网络分区在分布式系统中是不可避免的，因此系统设计者必须在一致性和可用性之间做出选择。传统的关系型分布式数据库通常选择保证一致性和分区容忍性（即 CP 系统），在网络分区时牺牲可用性。而许多 NoSQL 系统选择保证可用性和分区容忍性（即 AP 系统），允许数据在短时间内不一致。
2.4 BASE 理论
BASE 理论是针对 CAP 定理中 AP 选择的一种具体实践指导。它是 Basically Available（基本可用）、Soft state（软状态）和 Eventually Consistent（最终一致性）的缩写。基本可用是指系统在出现故障时允许在响应时间和功能范围上有所损失。软状态是指系统中的数据允许在一段时间内处于不同步的中间状态。最终一致性是指经过一段不确定的时间后，系统中所有数据副本最终将达到一致。
学习分布式事务时，最需要建立的是边界意识。2PC 等协议能够在理论上保证全局原子性，但它们会带来阻塞、协调超时、链路复杂和故障恢复困难等代价。因此，工程上越来越强调“缩小强事务边界”：把必须强一致的动作限制在核心链路中，把外围链路交给幂等重试、补偿流程、对账任务和事件驱动去完成。这样做并不是降低质量，而是把一致性要求按业务重要程度分层处理。真正成熟的系统设计，不是隐含地假设处处都能强一致，而是明确哪些地方必须强一致，哪些地方可以接受延迟一致。
3. 数据仓库与联机分析处理
3.1 数据仓库的基本概念
数据仓库 (Data Warehouse) 是面向分析和决策支持的数据管理系统，其概念由 W.H. Inmon 系统阐述。与面向事务处理的操作型数据库 (OLTP) 不同，数据仓库的主要功能是支持联机分析处理 (OLAP) 和数据挖掘。
数据仓库具有四个基本特征。面向主题是指数据围绕特定的业务分析主题来组织，而非围绕日常事务处理的功能来组织。例如零售业的数据仓库可能围绕销售分析、客户行为分析和供应链分析等主题来构建。集成性是指数据来源于多个分散的、异构的业务系统，在进入仓库之前需要经过抽取、清洗、转换和统一编码等处理。相对稳定性是指数据一旦加载到仓库中主要用于查询和分析，通常不进行更新和删除操作。反映历史变化是指数据仓库保留了数据在不同时间点的快照，能够支持趋势分析和同比环比计算等时间维度的分析需求。
数据仓库最容易被误解成“把业务数据搬到另一台机器上”。其实它更深层的价值，在于把原本分散、口径不一、编码不统一的数据，整理成可用于稳定分析的公共认知基础。换句话说，ETL 不只是技术搬运过程，也是语义对齐过程。若源系统中“订单完成”“活跃用户”“有效客户”各有各的定义，仓库就必须在进入分析层之前先统一口径。没有这一步，数据再多也难以支撑可靠决策。
3.2 ETL 过程
将数据从源系统加载到数据仓库需要经过 ETL 过程。抽取 (Extract) 阶段从各种源系统中按照预定的规则提取所需数据。转换 (Transform) 阶段对抽取到的数据进行清洗（处理缺失值、纠正错误数据）、格式统一（将不同源系统中的日期格式和编码方式等统一化）和业务规则计算（如计算衍生指标）等处理。加载 (Load) 阶段将转换后的数据按照仓库的模式结构装入目标表中。
3.3 数据仓库的模式设计
星型模式以一个中央的事实表 (Fact Table) 为核心，事实表中存储业务度量数据（如销售额和销售数量），周围连接多个维度表 (Dimension Table)。维度表描述业务分析的角度（如时间维度、地区维度、产品维度）。维度表通常不做规范化处理，保留一定的冗余以减少查询时的连接次数。星型模式结构简单、查询效率高，是数据仓库中最常用的模式。
雪花模式是在星型模式的基础上对维度表进一步进行规范化处理。例如将地区维度表拆分为省份表和城市表，形成维度表的层次结构。雪花模式减少了维度表中的数据冗余，但增加了查询时的连接层次。
教材学习这一部分时，最好把星型模式中的“事实”和“维度”真正区分清楚。事实表记录的是可加总、可统计、会不断累积的业务事件或度量，例如销售额、订单数、点击量；维度表记录的是观察这些事实的角度，例如时间、地区、商品、用户。很多分析建模错误，本质上不是 SQL 写得不对，而是把维度当成事实、把事实当成维度，最终导致指标口径混乱。只要事实与维度边界清晰，后续的 OLAP、报表和指标体系建设就会稳定得多。
3.4 OLAP 的基本操作
OLAP 提供了一组对多维数据进行交互式分析的操作。上卷 (Roll-up) 是沿着维度层次从细节向汇总方向聚合数据，例如从按月份统计销售额汇总到按季度统计。下钻 (Drill-down) 是上卷的逆操作，从汇总数据向更细的粒度展开。切片 (Slice) 是在某个维度上选取一个特定值，将多维数据降为低一维的数据。切块 (Dice) 是在多个维度上同时选取某些范围内的值。旋转 (Pivot) 是交换行和列的维度，从不同角度观察数据。
这些操作之所以重要，不是因为它们提供了几个新名词，而是因为它们准确描述了分析人员看数据时的典型动作。管理者看到某个月销售异常下降，往往会先下钻到地区或品类，再切片查看某个渠道，再旋转维度比较不同地区与时间的组合表现。换句话说，OLAP 操作并不是数据库内部的抽象玩法，而是把现实分析过程形式化。只要理解它们分别对应什么观察动作，就更容易把技术结构和业务分析连接起来。
4. 数据挖掘
数据挖掘 (Data Mining) 是从大量数据中发现隐含的、之前未知的、有潜在价值的模式和知识的过程。它综合运用了数据库技术、统计学方法和机器学习算法。
教材学习数据挖掘时，还需要补上一层边界意识。数据挖掘得到的是模式和相关性，不等于自动得到因果解释。一个规则即使支持度和置信度都很高，也不一定意味着它适合作为业务决策直接依据。若忽视数据质量、样本偏差和业务背景，再复杂的算法也可能得出误导性结论。因此，数据库课程讲数据挖掘，不是为了把数据库变成万能智能系统，而是帮助学习者理解：从数据到知识的过程仍然需要模型假设、统计判断和业务解释共同参与。
4.1 关联规则挖掘
关联规则用于发现事务数据库中不同数据项之间的有趣关联或相关关系。最典型的应用是超市购物篮分析。衡量关联规则的两个核心指标是支持度和置信度。规则 A 到 B 的支持度定义为同时包含 A 和 B 的事务占总事务数的比例。置信度定义为在包含 A 的事务中同时包含 B 的事务所占的比例。Apriori 算法是最经典的关联规则挖掘算法，其核心思想是频繁项集的任何子集也必然是频繁的。算法通过逐层生成候选项集并利用这一性质进行剪枝，有效减少了搜索空间。
4.2 分类与预测
分类是一种有监督学习方法，通过分析已知类别标签的训练数据来构建分类模型，然后用该模型预测新数据所属的类别。常用的分类算法包括：决策树算法（如 ID3 和 C4.5），通过在每个内部节点上选择最优划分属性来递归构建树形分类器，选择标准通常基于信息增益或增益率；朴素贝叶斯分类器，基于贝叶斯定理和属性之间条件独立性假设进行概率分类；支持向量机 (SVM)，通过寻找能够最大化类间间隔的超平面来进行分类。
4.3 聚类分析
聚类是一种无监督学习方法。与分类不同，聚类处理的数据没有预先定义的类别标签。聚类算法根据数据点之间的相似度或距离，将它们自动划分为若干组（簇），使得同一簇内的数据点尽可能相似，不同簇的数据点尽可能不同。K-means 是最常用的聚类算法，其基本过程为：随机选取 K 个数据点作为初始聚类中心，将每个数据点分配到距其最近的中心所在的簇，然后重新计算每个簇的中心（取簇内所有点的均值），反复迭代直到中心不再变化或达到预设的最大迭代次数。
5. NoSQL 数据库
NoSQL (Not Only SQL) 是一类非关系型数据管理系统的总称。它们的出现主要是为了应对传统关系型数据库在Internet海量数据、高并发访问和灵活模式设计等方面的不足。
NoSQL 数据库按照数据模型主要分为四类。键值存储（如 Redis 和 DynamoDB）以键值对的形式存储数据，支持极高的读写吞吐量，适用于缓存和会话管理等场景。文档存储（如 MongoDB 和 CouchDB）以 JSON 或 BSON 格式的文档作为基本数据单元，支持灵活的无模式设计，适用于内容管理系统和用户配置等场景。列族存储（如 HBase 和 Cassandra）以列族为基本存储单元，适合处理大规模稀疏数据和时间序列数据。图数据库（如 Neo4j）以节点、边和属性构成的图结构来存储和查询数据，擅长处理社交网络和知识图谱等需要频繁进行关系遍历的场景。
NoSQL 系统与传统关系型数据库各有优势。关系型数据库提供严格的 ACID 事务保证和强大的 SQL 查询能力，适合数据之间关系复杂且对一致性要求高的场景。NoSQL 系统具有灵活的模式设计、良好的水平扩展能力和更高的写入吞吐量，适合半结构化数据、超大规模数据存储和高并发读写场景。
因此，NoSQL 的正确定位从来不是“替代关系数据库”，而是“补充关系数据库无法经济解决的问题”。现实系统里，交易核心常用关系数据库，缓存与会话常用键值存储，内容对象和画像常用文档数据库，关系遍历密集场景常用图数据库。若把 NoSQL 理解成一个统一方案，往往会在选型时过度简化问题；若把它看成一组针对不同约束的专门工具，就更容易做出合理决策。
6. 发展趋势
NewSQL 数据库是近年来出现的一类新型关系型数据库，致力于同时提供传统关系型数据库的 ACID 事务保证和 NoSQL 系统的水平扩展能力。代表产品包括 Google Spanner、TiDB 和 CockroachDB 等。它们通常采用分布式一致性算法（如 Raft 或 Paxos）来实现跨节点的强一致性。
云原生数据库（如 Amazon Aurora 和阿里云 PolarDB）采用计算与存储分离的架构设计。数据库的计算层和存储层可以独立扩展。多个计算节点共享同一份存储数据，能够根据负载变化快速弹性地增减计算资源。这种架构降低了运维复杂度，同时在成本效率和可用性方面都有明显优势。
湖仓一体 (Lakehouse) 是一种正在兴起的数据管理架构，尝试融合数据湖的低成本海量存储能力和数据仓库的高性能查询和数据管理能力。以 Delta Lake 和 Apache Iceberg 为代表的开源方案，在数据湖使用的廉价对象存储（如 S3 或 HDFS）之上构建了事务支持、模式管理和高效索引等企业级数据管理功能，使得数据工程师不必在数据湖和数据仓库之间维护两套独立的基础设施。
这些发展趋势表面上名词很多，背后其实有一条清晰主线：数据库正在同时向“更大规模”“更多场景”和“更强治理”三个方向演化。云原生数据库强调计算与存储分离、弹性伸缩和托管运维，解决的是基础设施弹性和运维复杂度问题；湖仓一体强调批流一体、统一元数据和统一权限治理，解决的是数据生命周期割裂问题；NewSQL 则试图把关系事务能力扩展到分布式环境。理解这些产品时，不应只记住某个架构名词，而应先问它主要在解决哪一类旧问题，又引入了什么新代价。
从能力结构看，学习高级数据库主题的目标也不只是记住若干前沿概念，而是形成复合判断力。需要理解一致性、并发、恢复这些原理问题，也需要理解架构选型、成本治理、元数据治理、权限治理这些工程问题。只要抓住扩展性、一致性和治理性三条主线，面对不断变化的新产品和新术语，仍然可以保持稳定分析框架。
🔒 会员专属内容
检查登录状态中...