DBPA · 18.3

区块链与数据库的对比与融合

可信共享与高效管理需要不同的技术取舍

VER. 2608.3 Built with impress.js

学习目标

完成本节后，你应该能够

区块链的工作机制、架构和准入模式决定比较基线；融合方案还要明确数据、责任和性能边界

01比较两类系统的设计目标、信任环境和错误模型
02区分链式交易历史、节点状态库和关系表，并说明各自的事务边界
03解释副本、协调、提交以及查询和状态组织的差异
04在一致验证条件下说明数据库技术如何缓解区块链瓶颈
05说明链式日志和签名如何提供数据库的可验证审计证据
06用信任、吞吐、历史证据和复杂查询判断数据库、区块链或融合方案

2/12

LEARNING OBJECTIVES

区块链与关系数据库的设计目标和信任假设不同

两类系统的典型取向不是绝对二分；许可链和分布式数据库可能处于中间

区块链全章概念总览：业务输入、Merkle 汇总、链式记录、多节点副本、状态查询与可信性和效率取舍 — 概念总览图展示业务输入、链式记录、状态查询以及可信性和效率取舍

维度	区块链	关系数据库
典型设计重点	强调改动可检测、可追溯和多主体验证	强调响应、吞吐、完整功能和事务并发
典型错误模型	需要处理恶意节点、分歧和开放网络协调	重点处理宕机、故障、非法访问和组织治理
典型运行环境	开放或多主体，也可采用许可网络	受控组织，也可处于分布式多方环境

Takeaway

两类系统都需要完整性、可用性和性能；差异在于优先级、信任假设和协调边界

3/12

DESIGN GOALS

链式历史、状态库与关系表保存不同事实

三者都能承载结构化信息，但保存的事实、可执行操作和事务边界不同

链式交易历史

区块保存已接受的追加式交易及其顺序；它不等于业务当前表，也不等于数据库 WAL

节点状态库

根据链上历史物化出的本地可查询状态，常见键值结构但不限定为一种实现

关系表与 SQL

按关系模式组织当前或历史业务数据；SQL 支持增删改查和事务并发，表不必只保存当前数据

Takeaway

链式历史回答“接受了哪些操作”；状态库回答“节点当前可查询什么”；关系表回答“业务如何组织和操作数据”

4/12

DATA AND OPERATIONS

副本与协调边界决定请求如何处理

副本位置、验证、提交和协调责任比“中心”或“去中心化”标签更能说明架构差异

历史与副本

区块链的全节点、轻节点、归档节点职责不同；分布式数据库也可分片、复制或保留控制平面

验证与提交

节点按协议验证和接受历史；关系数据库按事务与协调机制提交，具体架构依系统而异

查询与状态

区块链常由状态库提供当前查询；关系系统用表、索引和查询执行组织业务状态

Takeaway

架构比较应说明副本范围、请求协调、提交边界和查询路径

5/12

ARCHITECTURE

数据库技术可缓解部分链上性能瓶颈

技术要对应具体瓶颈；跨片协调、冲突回滚、索引维护和一致验证仍然存在

区块链通过分片、并发执行、索引和 Bloom Filter 减少全网处理与区块扫描 — 分片、并发、索引和 Bloom Filter 可以组合使用；它们不是固定流水线，每片仍需一致验证

01分片：不同片处理不同事务；跨片事务仍需协调，每片仍需满足安全和数据可用性要求
02并发：STM 或 MVCC 利用多核并行；系统仍需进行冲突检测、回滚和确定性验证
03索引：辅助定位区块和交易；索引维护不等于共识数据本身
04布隆过滤器 Bloom Filter：可排除不可能命中的区块，可能假阳性；命中仍需实际验证

Takeaway

数据库技术可以改变处理与查询路径，但不能替代跨片协调、冲突处理和一致验证

6/12

DATABASE INTO BLOCKCHAIN

链式日志与签名提供可验证审计

关系库保存业务状态，链式日志保存操作证据；两者需要绑定事务 ID 并共同设计恢复路径

关系数据库保存当前业务状态，链式操作日志保存时间、摘要和签名证据，分层支持可验证审计 — 链式日志保存操作证据，不是业务表本身；虚线表示审计、校验或补偿路径，不是普通查询路径

Takeaway

关系表　＋　链式操作日志　＋　数字签名　→　可验证审计；签名不自动证明现实事实，按时点回溯数据仍需完整事件、同步和恢复设计

7/12

TRUST INTO DATABASE

两条反向路径可以组合，但不自动相加

两条路径的数据位置与验证责任不同，组合时要分别说明链上和库内的边界

示意路线	方向	数据位置与验证边界	可能收益与代价
数据库技术进入区块链	数据库 → 区块链	分片、并发、索引辅助处理；跨片与一致验证仍需保留	可能改善扩展或查询；增加协调、维护和确定性执行成本
区块链特征进入数据库	区块链 → 数据库	关系库保存业务状态，链式日志保存摘要、时间和签名证据	可能增强审计与追溯；同步、恢复和隐私边界仍需设计
代表性融合思路	分层组合	BigchainDB、ChainSQL 类或共享数据库可作为案例，具体实现各异	收益取决于日志内容、提交绑定、查询路径和治理，不能由产品名称直接保证

Takeaway

融合不是把所有组件叠加；必须说明数据位置、验证责任、同步恢复和查询代价

8/12

FUSION EXAMPLES

四个维度决定单一或融合方案的选择

多机构物流需要同时权衡信任、写入、历史证据和查询并发；组件堆叠本身不是方案

四个判断轴

判断轴包括参与者与治理、写入吞吐与延迟、可验证且改动成本高的历史证据，以及复杂查询、更新与事务并发

关系数据库

单一可信主体、复杂查询、低延迟和可修改数据优先；仍需普通审计、备份和权限治理

区块链／分布式账本

多主体需要独立验证追加历史时可能合适；需承担共识、同步、隐私和运维成本

融合方案

业务查询与跨组织审计并存时，可让关系库保存状态、链式日志保存证据；必须设计事务绑定、恢复和治理

Takeaway

“可能合适”不是自动保证；最终选择还要核对数据真实性、权限、最终性、同步失败和密钥管理

9/12

CHOOSE THE SYSTEM

区块链与数据库的融合需要明确责任与代价

两类系统各有目标和边界；融合方案仍需明确同步、恢复、治理与性能代价

目标与环境

安全、可追溯、性能和完整功能都重要；优先级取决于信任与协调假设

数据对象

链式交易历史、节点状态库和关系表保存不同事实，操作与事务边界不同

两条路径

数据库技术可以进入区块链，链式日志、签名和审计证据也可以进入数据库

选择边界

方案选择应按信任、吞吐、历史证据、复杂查询、同步恢复和治理判断

Takeaway

融合方案只有明确数据位置、验证责任、同步恢复和查询代价，才便于评估

10/12

RECAP

本节知识地图

11/12

KNOWLEDGE MAP

本节问题

01给定业务场景，区块链与关系数据库的信任假设和设计目标有何不同？
02如何区分链式交易历史、节点状态库、关系表以及数据库 WAL／审计日志？
03分片、STM／MVCC、索引分别缓解什么瓶颈，又留下哪些协调或验证代价？
04布隆过滤器能排除什么、不能证明什么，命中后为什么仍需实际验证？
05链式日志和数字签名能提供哪些可验证审计证据，何时仍不能完成时点回溯？
06在单一可信中心、多方协作、混合审计三个场景中如何选择方案并说明理由？

12/12

CHECK YOUR UNDERSTANDING