16-Oracle 23 ai-JSON-Relational Duality-知识准备
一直做DBA的小伙伴,是不是对开发相对陌生一些。JSON 关系二元性是 Oracle Database 23ai 中重要的特性,同时带来的是范式革命。JSON关系二元性解决了数据库领域的根本矛盾,结构化数据的严谨性与半结构化数据的灵活性之间的矛盾。
JSON Relational Duality为 Oracle 数据库开发人员提供了改变游戏规则的灵活性和简单性。这一突破性创新克服了开发人员在构建应用程序时(无论是使用关系模型还是使用文档模型)所面临的历史挑战。
一、JSON,JSON关系二元性,JSON二元性视图
- JSON(JavaScript Object Notation)是一种轻量级的数据交换格式,易于人阅读和编写,同时也易于机器解析和生成。
- 在数据库中,JSON数据可以以文本形式存储,也可以以二进制形式(如Oracle的JSON类型,PostgreSQL的JSONB)存储,以便更高效地处理和查询。
- 这是一种数据库技术,旨在弥合关系型数据库和文档数据库之间的鸿沟。它允许数据同时以关系表和JSON文档的形式存在,并且两种形式之间是实时同步的。
- 核心思想:同一份数据,两种表达方式(关系和文档),并且保持自动、实时的双向转换。当通过关系表修改数据时,JSON文档视图会自动更新;反之,当通过JSON文档修改数据时,底层的关系表也会自动更新。
- 这是实现JSON关系二元性的具体技术手段。在Oracle 23ai中,通过创建一种特殊的视图(称为Duality View)来定义JSON文档的结构,并映射到底层的关系表。
- 该视图不仅提供了一种只读的JSON文档视图,而且支持通过JSON文档的插入、更新和删除操作来修改底层的关系表数据。
- 数据表达的统一:JSON二元性视图是JSON关系二元性概念的具体实现。它允许开发者以JSON文档的形式操作数据,而数据库自动将这些操作转换为对关系表的操作,反之亦然。
- 实时同步:底层的数据存储可以是关系表,但通过二元性视图,数据以JSON文档形式呈现。任何一方的修改都会实时反映到另一方,无需ETL或额外的同步机制。
- 开发灵活性:开发者可以根据需要选择使用SQL操作关系表(适合复杂查询和事务)或使用文档操作(如RESTful接口)来处理JSON文档,而数据始终保持一致。
1. JSON的诞生背景
- 轻量化:相比XML减少60-70%的数据体积
- 易读性:人类可读的键值对结构,自描述性,数据结构与数据一体
- 语言无关:独立于编程语言的通用数据格式。中立,所有编程语言通用
- 灵活性:无固定模式,随时增减字段
2.数据结构:键值对集合(对象) + 有序列表(数组)
{"id": 101,"name": "康有为","roles": ["admin", "editor"],"contact": {"email": "kang@china.com","phone": "+86 98765432100"}
}
3. 核心使用场景
- Web API通信:90%的RESTful API采用JSON作为数据交换格式
- NoSQL数据库:MongoDB等文档数据库的底层存储格式
- 配置管理:Kubernetes等云原生系统的配置格式
- 实时数据流:Kafka等消息队列的常用数据格式
三、传统架构核心问题
1. 关系型数据库(RDBMS)
- ACID事务保证(银行交易等关键系统)
- 强大的关联查询能力(JOIN操作)
- 成熟的数据完整性约束(主键、外键等)
- 模型不匹配:对象模型与关系模型转换成本高(30-40%开发时间)
- 结构僵化:修改表结构需DDL操作(生产环境风险高)
- 扩展困难:水平扩展复杂(分库分表技术门槛高)
2. NoSQL文档数据库
- 灵活的数据模型(随时添加新字段)
- 快速开发迭代(无需预定义模式)
- 天然水平扩展(分布式架构)
- 弱事务支持:跨文档事务实现复杂
- 关联查询低效:$lookup操作性能差
- 数据冗余:相同数据在多文档重复存储(存储成本增加30-70%)
3. 传统数据处理
四、JSON关系二元性和view实现
1. 关键概念解析
Duality View--虚拟 JSON 文档接口,基于底层关系表实时生成。
WITH UPDATE--视图字段级更新控制(指定可写字段)。
ETag--文档版本标识符(解决并发冲突)。
JSON_mergepatch--部分文档更新函数(避免全文档替换)。
2. 技术实现
JSON关系二元性
JSON 二元性视图
3. JSON二元性核心优势
功能核心优势
对比维度 | 传统架构 | JSON二元性 | 改进效果 |
开发效率 | ORM+ETL多层转换 | 自动双向映射 | 开发周期缩短40% |
事务一致性 | 跨库事务复杂(2PC/XA) | 原生跨模型ACID | 错误率降低90% |
查询性能 | 关联查询需应用层拼接 | 单请求获取完整文档 | 响应时间提升5-10倍 |
存储效率 | 双重存储(关系+文档) | 单一存储双视图 | 存储成本降低60% |
架构复杂度 | 多组件协同(DB+Cache+MQ) | 单一数据库引擎 | 运维成本减少70% |
扩展灵活性 | 模式变更需停机维护 | 动态添加JSON字段 | 业务中断时间减少95% |
操作方式与传统架构对比
操作类型 | 传统架构 | 二元性架构 |
读取用户数据 | 多表JOIN查询 → ORM转换 → JSON序列化 | 直接查询二元性视图获得完整JSON |
更新用户信息 | 解析JSON → 更新多表 → 验证一致性 | JSON_mergepatch单视图操作 |
添加关联记录 | 事务中插入多行 → 刷新缓存 | JSON数组添加元素自动创建关联行 |
并发控制 | 行级锁或应用层锁 | ETag乐观锁自动处理 |
4. JSON 二元性视图:技术实现的核心
视图定义
代码实例
CREATE JSON RELATIONAL DUALITY VIEW employee_dv
AS
SELECT JSON {'empId': e.employee_id,'fullName': e.first_name || ' ' || e.last_name,'department': (SELECT JSON {'id': d.department_id, 'name': d.department_name}FROM departments d WHERE d.department_id = e.department_id),'projects': [ SELECT JSON {'projectId': p.project_id, 'name': p.project_name}FROM projects p JOIN assignments a ON p.project_id = a.project_idWHERE a.employee_id = e.employee_id]
}
FROM employees e WITH UPDATE;
存储行为
五、实现JSON二元性技术的改变
1. 动态双向映射引擎
- 增量处理:仅更新修改字段(性能提升3-5倍)
- 智能缓存:热文档缓存命中率90%+
2. 混合事务管理器
- 全局SCN(系统变更号)保证读写一致性
- 文档级乐观锁(ETag机制避免死锁)
BEGIN-- 关系操作(扣减库存)UPDATE products SET stock = stock - 1 WHERE sku = 'A123';-- 文档操作(创建订单)INSERT INTO order_v VALUES ('{"items":[{"sku":"A123"}]}');-- 跨模型事务提交
COMMIT;
3.多协议适配层
协议转换开销的大幅降低
六、JSON 关系二元性推荐使用场景
- 微服务架构中需要混合数据模型
- 从MongoDB迁移到关系数据库的系统
- 需要实时分析的事务系统(HTAP)
- 纯键值访问场景(Redis更合适)
- 超大规模日志处理(专用时序数据库更优)
- 简单博客系统(MySQL,甚至Docker部署,一般够用)