5-Oracle 23ai True Cache&ADG &In-Memory对比和选择

原创已于 2025-06-02 10:14:28 修改

· 909 阅读

7 ·

版权

文章标签：

#oracle #数据库

于 2025-06-02 10:03:31 首次发布

一、单个特性拿出来都很能打

Oracle Database 23ai 重要的新特性 True Cache，当遇见此前在EXADATA上深度使用的In-Memory、落在寻常百姓家的ADG，甚至去和ElasticSearch、Redis一众在应用背后，数据库之前，扛下很多流量的他们，如何选择？

二、功能区别列表

Oracle Database 23ai 中 True Cache、In-Memory 和 Active Data Guard (ADG) 三者均来自于Oracle中重要的特性，结合其技术特性与定位总结：

特性	True Cache	In-Memory	Active Data Guard (ADG)
定位	中间层全功能只读缓存	主库内存列式加速引擎	高可用灾备 + 只读负载分流
数据一致性	事务级一致（亚秒级延迟）	与主库行式数据实时一致	与主库物理一致（实时日志应用）
存储形式	内存中行式存储（无磁盘数据文件）	内存中列式存储（双格式架构）	磁盘存储 + 可选内存缓存（需独立实例）
功能支持	完整 SQL/JSON/Graph 查询	优化分析型扫描、聚合类查询	只读查询（部分分析受限）
部署拓扑	可分布式部署	仅限主库或 ADG 备库内部	独立物理备库实例
数据更新机制	Redo Apply 同步（类 ADG）	主库事务直接更新	Redo Apply 同步
资源消耗	低磁盘占用（仅日志文件）	占用主库 SGA 内存	完整实例资源（CPU/内存/存储）

三、底层技术相通处

True Cache 本质是无盘的 ADG 物理备库，复用 ADG 的 Redo Apply 机制实现数据同步，数据存于内存单独做出了低延迟缓存设计。二者共享日志传输、依赖于日志的传输、数据一致性保障等核心架构。
In-Memory 在 ADG 上的扩展 ADG 备库可启用 In-Memory 选件，将列式存储应用于备库，分担主库分析压力（如报表查询）。在企业大部分使用场景中 ADG 同时具数据的备灾备份与只读查询和内存加速能力。
True Cache 与 In-Memory 的互补性 True Cache 通过block级别的快速复制和应用，解决物理距离与连接扩展问题（例如边缘计算、数据全球部署）； In-Memory 优化主库本地分析性能（如实时聚合）；二者均可卸载主库负载，适用场景又各有不同（网络延迟、计算密集型等各种情况）

三、应用场景

True Cache 适用场景

低延迟读访问：用户会话存储、实时业务的排行、身份认证（微秒级响应）。
地理分布式架构：数据主权合规（如 GDPR），边缘节点就近读取。数据全球或是跨地域部署的快速读取。
高并发读分流：大型系统ITEM或是BOM目录浏览、业务信息推送等读密集型业务。
透明缓存集成

特点：无需改造应用，通过 JDBC 驱动自动路由只读请求。

In-Memory 适用场景

实时分析混合负载（HTAP）：在 OLTP 库上直接运行分析查询（如即时报表）。
聚合/扫描优化：大表过滤（where）、列投影（少量列访问）、星型连接查询。
压缩加速场景：内存列式压缩提升扫描效率，同时减少磁盘索引依赖。
自治数据库加速

特点：Oracle Autonomous Database 自治数据库中透明启用内存加速。

ADG 适用场景

核心高可用与容灾：RTO/RPO 趋近零的故障切换（制造业7*24，金融核心系统）。
只读负载隔离：报表库、BI 查询专用备库，避免影响主库交易性能。
滚动升级与备份：在备库执行备份/升级测试，减少主库停机窗口。
地理冗余：跨数据中心部署灾备节点（配合 Data Guard Broker）。

ADG在自11g以后的OCM考试中必考，从前是大名鼎鼎的DataGuard，12c以后的版本有更新的特性Active特性，名字变成ADG。企业级应用场景中必备RAC+ADG，ADG作为11g以来的OCM考试必备，很多人会在这里掉下来，四场考试中最惊心动魄的一场。

四、使用建议

需亚秒级近端缓存 → True Cache（例如全国--省--地市，或是跨国公司全球应用加速）；
需主库分析加速 → In-Memory（例如混合 HTAP 负载）；
需灾备、配合RAC + 只读扩展 → ADG（例如金融容灾+报表分离）；
场景：ADG 备库启用 In-Memory 实现灾备与分析加速；True Cache 扩展 ADG 的只读能力至边缘侧。

TIPS：True Cache 是 23ai 的创新特性，将 ADG 的灾备能力转化为轻量级缓存层；In-Memory 持续增强 HTAP 支持；ADG 仍企业级最基础也最为实用高可靠高可用方案。三者可组合构建多层次数据架构。

五、展开想象，既有True Cache，和ES、Redis如何对标

维度	Oracle TrueCache	Redis	Elasticsearch
本质	数据库中间层只读缓存 (基于 ADG 技术)	内存键值存储 + 数据结构服务	分布式搜索与分析引擎 (基于 Lucene)
数据一致性	事务级强一致 (亚秒级同步主库 Redo)	最终一致 (主从异步复制) 或弱一致	最终一致 (近实时刷新机制)
查询能力	完整 SQL/JSON/Graph 查询	键值操作 + 扩展模块 (如 RedisSearch)	全文检索 + 聚合分析 + 复杂 DSL 查询
存储结构	内存行式存储 (无磁盘数据文件)	内存数据结构 (字符串/哈希/列表等)	磁盘存储 + 内存缓存 (倒排索引 + DocValues)
扩展性	自动负载均衡 (Uniform/分区部署)	集群分片需手动配置 (Redis Cluster)	原生分布式分片 (自动数据分布)

六、技术差异点与协同场景

Redis 适用场景

会话管理：用户登录状态存储（低延迟读写）；
消息队列：Streams 数据结构实现异步任务；
实时排行榜：Sorted Set 结构更新典型业务的累计，多次违规或是积分。

Elastic search 适用场景

日志分析：ELK Stack 处理 TB 级日志（例如错误追踪）；
全文搜索：大型系统中产品多字段检索（例如“感冒药品日期”）；
聚合分析：用户或是企业行为画像（例如某一类手术、某一款工具和耗材的多次使用）

True Cache 与 Redis 的互补性

True Cache：卸载数据库关联型查询（如多表 JOIN），保证 SQL 兼容性与事务一致性；

Redis：处理高频键值操作（如会话存储、实时计数器），支持丰富数据结构；

协同示例：大型高频交易系统中，True Cache 缓存Item物料关系数据，Redis 存储用户钱包业务购物车等。

Elasticsearch 与 Redis/True Cache 的分工

Elasticsearch：专注文本搜索/日志分析（例如日志聚合、模糊匹配）；

Redis/True Cache：服务低延迟数据访问（例如实时查询、事务处理）；

协同示例：用户行为日志先写入 Elasticsearch 分析，结果摘要缓存到 Redis 供实时展示。

True Cache 与 Elasticsearch 的替代性

两者均支持只读查询，但适用场景不同：

TrueCache 替代 Oracle 只读副本，减少主库负载；

Elasticsearch 替代关系型数据库复杂查询（如全文检索）。

回到原点：Redis 是通用内存存储，Elasticsearch 是搜索引擎。三者定位互补，可协同构建高性能数据架构——True Cache 优化数据库负载，Redis 支撑应用层状态管理，Elasticsearch 解决复杂检索问题。TrueCache + Redis：OLTP 系统分层缓存（关系型+键值）；Elasticsearch + Redis：搜索分析+结果缓存。

True Cache 是 Oracle 生态的专用缓存新特性，结合Oracle核心特性RAC、ADG、ASM、分布式文件系统等形成短时间内业界难以挑战的护城河。