一直做DBA的小伙伴，是不是对开发相对陌生一些。JSON 关系二元性是 Oracle Database 23ai 中重要的特性，同时带来的是范式革命。JSON关系二元性解决了数据库领域的根本矛盾，结构化数据的严谨性与半结构化数据的灵活性之间的矛盾。
JSON Relational Duality为 Oracle 数据库开发人员提供了改变游戏规则的灵活性和简单性。这一突破性创新克服了开发人员在构建应用程序时（无论是使用关系模型还是使用文档模型）所面临的历史挑战。
一、JSON，JSON关系二元性，JSON二元性视图
JSON格式的数据：
- JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，易于人阅读和编写，同时也易于机器解析和生成。
- 在数据库中，JSON数据可以以文本形式存储，也可以以二进制形式（如Oracle的JSON类型，PostgreSQL的JSONB）存储，以便更高效地处理和查询。
JSON关系二元性（JSON Relational Duality）： - 这是一种数据库技术，旨在弥合关系型数据库和文档数据库之间的鸿沟。它允许数据同时以关系表和JSON文档的形式存在，并且两种形式之间是实时同步的。
- 核心思想：同一份数据，两种表达方式（关系和文档），并且保持自动、实时的双向转换。当通过关系表修改数据时，JSON文档视图会自动更新；反之，当通过JSON文档修改数据时，底层的关系表也会自动更新。
JSON二元性视图（JSON Duality View） ： - 这是实现JSON关系二元性的具体技术手段。在Oracle 23ai中，通过创建一种特殊的视图（称为Duality View）来定义JSON文档的结构，并映射到底层的关系表。
- 该视图不仅提供了一种只读的JSON文档视图，而且支持通过JSON文档的插入、更新和删除操作来修改底层的关系表数据。
相关的 联系 ： - 数据表达的统一：JSON二元性视图是JSON关系二元性概念的具体实现。它允许开发者以JSON文档的形式操作数据，而数据库自动将这些操作转换为对关系表的操作，反之亦然。
- 实时同步：底层的数据存储可以是关系表，但通过二元性视图，数据以JSON文档形式呈现。任何一方的修改都会实时反映到另一方，无需ETL或额外的同步机制。
- 开发灵活性：开发者可以根据需要选择使用SQL操作关系表（适合复杂查询和事务）或使用文档操作（如RESTful接口）来处理JSON文档，而数据始终保持一致。
1. JSON的诞生背景
JSON（JavaScript Object Notation）由Douglas Crockford于2001年正式提出，源于JavaScript的对象字面量语法。其核心设计目标：
- 轻量化：相比XML减少60-70%的数据体积
- 易读性：人类可读的键值对结构，自描述性，数据结构与数据一体
- 语言无关：独立于编程语言的通用数据格式。中立，所有编程语言通用
- 灵活性：无固定模式，随时增减字段
2.数据结构：键值对集合（对象） + 有序列表（数组）
bash
{
"id": 101,
"name": "康有为",
"roles": ["admin", "editor"],
"contact": {
"email": "[email protected]",
"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 二元性视图：技术实现的核心
视图定义
代码实例
bash
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_id
WHERE a.employee_id = e.employee_id
]
}
FROM employees e WITH UPDATE;存储行为
五、实现JSON二元性技术的改变
1. 动态双向映射引擎
- 增量处理：仅更新修改字段（性能提升3-5倍）
- 智能缓存：热文档缓存命中率90%+
2. 混合事务管理器
- 全局SCN(系统变更号)保证读写一致性
- 文档级乐观锁（ETag机制避免死锁）
bash
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部署，一般够用）