DBPA · 14.2

关系系统扩展与 SQL、NoSQL、NewSQL

从数据表达、事务一致性和扩展方式理解不同系统路线

VER. 2608.3 Built with impress.js

学习目标

关系扩展和数据库路线取决于负载、模型与系统取舍

01解释 OLTP 与 OLAP 为什么分离，以及 ETL/ELT 如何把事务数据送入分析环境
02区分面向对象数据库、对象关系数据库与 XML 的表达能力
03按模型、接口、事务和一致性边界比较 SQL、NoSQL 与 NewSQL
04解释分片、副本和横向扩展分别改善什么，并指出协调成本
05区分 ACID 与 BASE 的关注点，说明 BASE 不是没有一致性
06根据负载、事务范围、模式稳定性和一致性要求选择候选路线

2/11

LEARNING OBJECTIVES

关系模型扩展的方向

新的负载和数据形态暴露了单一关系系统的边界

数据库从文件、层次／网状、关系到分布式与多模型的演进示意 — 概念示意：关系扩展回应新的负载和数据形态

扩展方向	新压力	主要扩展	保留能力与代价
数据仓库	OLTP 与 OLAP 互相干扰	ETL/ELT 后按主题组织历史、集成数据	保留关系基础，但存在数据延迟和额外处理链
面向对象／对象关系	复杂对象、用户自定义类型和操作	在关系与 SQL 基础上扩展对象表达	保留事务和工具链，但实现与语言更复杂
XML	半结构化交换与异构集成	树状、自描述数据表达	便于跨系统交换，但查询和约束语义需要额外机制

3/11

RELATIONAL EXTENSIONS

按负载组合多种数据库

不同负载需要不同模型、接口和一致性取舍

单一通用模型→承认不同负载的差异→多种互补系统按任务组合

One Size Fits All

关系数据库和 SQL 试图覆盖大多数数据管理与事务需求

One Size Does Not Fit All

分析、复杂对象、半结构化数据、海量和分布式负载暴露单一系统的边界

One Size Fits a Bunch

SQL、NoSQL、NewSQL 与数据仓库在不同负载中共存并相互借鉴

Takeaway

可以按负载组合互补系统：订单与库存采用关系型 SQL，历史报表进入数据仓库，结构变化快或高吞吐的访问再评估其他路线

4/11

ONE SIZE

关系数据库与 ACID 事务

在正确配置事务、约束和隔离级别的前提下，订单与库存更新可保持清晰边界

模型

关系模式和完整性约束使数据结构与可接受状态更明确

接口

SQL 表达目标，不要求用户直接写出物理访问路径

事务

ACID、并发控制与恢复支持订单和库存的整体更新

写入订单＋扣减库存→一个 ACID 事务→两步全部成功，或失败时整体回滚

原子性要求全做或全不做；一致性要求状态变化保持完整性约束；隔离性避免并发事务看到未定义的中间状态；持久性要求提交后故障恢复仍能保留结果

Takeaway

具体保证取决于事务边界、隔离级别和系统配置，跨节点协调可能增加扩展成本

5/11

SQL DATABASE

NoSQL：模型与一致性取舍

典型系统在柔性、吞吐、可用性与一致性之间做不同组合

概念	解决的问题	得到什么	代价或边界
数据模型	键值、宽表、文档、图	针对结构与访问模式提供选择	不同模型的关系语义和接口不统一
分片	把数据分到多个节点	扩大容量、并行处理和横向扩展	跨分片查询和事务需要协调
副本	同一分片保存多份	提高节点故障下的可用性，也可能支持读扩展	同步带来通信和一致性成本
BASE 与最终一致性	部分系统放宽即时一致性	换取特定负载下的可用性或吞吐；更新停止后副本可能收敛	BASE 不是所有 NoSQL 的统一契约，也不等于没有一致性
查询与事务	NoSQL 仍可提供查询和局部事务	由具体系统定义灵活边界	跨分片事务和全局关系语义可能受限
模式	模式较柔性，更多语义由应用解释	快速适应结构变化	数据质量由系统、应用和管道共同维护

Takeaway

分片解决数据如何分布和扩展，副本解决节点故障下如何继续服务；最终一致性描述副本传播过程，不等于 BASE 适用于所有系统

6/11

NOSQL

NewSQL 的目标与代价

它是多种系统路线的共同目标，不是单一产品或固定实现

SQL／关系接口　＋　分布式事务与一致性机制　＋　分片、多副本与横向扩展→NewSQL 路线

保留

SQL 接口、关系语义和事务开发接口

吸收

分片、多副本、横向扩展和分布式事务

代价

跨节点协调、延迟、故障处理、运维复杂度和一致性实现成本

Takeaway

NewSQL 的目标需要共识、分片、动态迁移和云原生支撑，具体机制会增加协调与运维成本

7/11

NEWSQL

按负载选择数据库路线

先描述负载、事务范围、模式和一致性，再判断扩展方式与代价

路线	模型与接口	一致性／事务	扩展方式	典型负载与边界
关系型 SQL	关系模式、SQL、完整性约束	通常强调 ACID	传统扩展或特定分布式方案	精细事务；极大规模扩展可能成本较高
NoSQL	键值、宽表、文档、图等	取舍多样，部分系统采用 BASE	分片和副本	海量、柔性或高吞吐负载；跨分片语义可能复杂
NewSQL	关系模型和 SQL	目标是保留分布式事务语义	分片、多副本、横向扩展	跨节点关系事务；协调和运维成本更高

一种可能的系统分工是：订单与库存先检查 ACID 和完整性约束；零部件目录与缓存先检查模型柔性、吞吐和横向扩展；历史报表先检查 OLAP 与数据仓库分工

Takeaway

系统分工取决于负载和约束，不能仅按业务名称固定选择

8/11

CHOOSE BY WORKLOAD

本节回顾

同一组织可以组合多条数据库路线，先描述负载和约束再判断代价

关系扩展

OLTP 与分析分工；对象关系和 XML 扩展数据表达

SQL

关系模式、SQL 和 ACID 适合边界清晰的精细事务

NoSQL 与 NewSQL

NoSQL 以柔性模型、分片和副本应对特定负载；NewSQL 尝试保留 SQL 事务并扩展到分布式节点

Takeaway

先看数据模型和负载，再看事务与一致性，最后判断分片、副本和横向扩展需求

9/11

RECAP

本节知识地图

10/11

KNOWLEDGE MAP

本节问题

01订单与月度分析为何分开？事务数据如何进入分析环境？
02对象关系数据库与 XML 各解决什么问题？
03分片与副本各解决什么问题？
04订单扣库存属于 ACID 的哪一性质？副本未同步体现 BASE 的哪一特点？
05NewSQL 为何适合跨节点 SQL 事务？协调代价是什么？
06订单、事件、跨节点 SQL 事务如何选择路线？各自边界是什么？

11/11

CHECK YOUR UNDERSTANDING