16-Oracle 23 ai-JSON-Relational Duality-知识准备

发布于:2025-06-08 ⋅ 阅读:(15) ⋅ 点赞:(0)

一直做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.数据结构​:键值对集合(对象) + 有序列表(数组) 

{
  "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_id
        WHERE 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部署,一般够用)


网站公告

今日签到

点亮在社区的每一天
去签到