Oracle内存计算应用模式

前言

内存计算是利用内存来加速数据访问和应用的性能，并降低应用开发复杂度的技术。近十年来，随着软硬件技术的发展和用户需求的成熟，内存计算技术已经得到了广泛地应用。

Oracle在内存计算领域具有非常重要的地位，这主要得益于Oracle在技术领域的长期耕耘和深厚积累。Oracle在内存计算领域的产品和解决方案包括：Oracle TimesTen，Oracle Database In-Memory和Oracle True Cache。

按照时间顺序。TimesTen 1996年成立，2005年6月被Oracle收购，在电信和金融行业得到广泛应用。Database In-Memory作为数据库选件，于2014年7月首次发布，极大增强了Oracle数据库的分析能力。True Cache 于2023年9月推出，包含在即将发布的Oracle 23c数据库中，极大简化了只读缓存的管理和应用开发。

来看一下官网对这3种内存计算技术的介绍：

TimesTen：超快速、超高可用且弹性可扩展的 OLTP 数据库。Oracle TimesTen In-Memory Database 是一个功能全面、内存优化的关系型数据库，可助力众多行业的任务关键型应用实现微秒级响应和超高的吞吐量性能。
Oracle Database In-Memory：将列功能引入 Oracle Database，透明地加快分析查询速度高达数个量级。它支持企业基于实时数据制定明智决策，降低成本、提高工作效率和竞争力。
Oracle True Cache ：是一项只读的内存中高性能 SQL 和键值缓存服务，它支持自动化管理，可确保数据一致。Oracle True Cache 能够在改善应用响应速度的同时降低数据库服务器负担。此外，得益于自动化管理和数据一致性，它还能简化应用开发，降低开发人员工作量和成本。

基于以上3种技术，下面我们将对Oracle主要的内存计算应用模式进行简要地介绍。

模式1：TimesTen作为Oracle数据库只读缓存

在这里插入图片描述
将内存作为缓存，是一种非常流行的内存计算应用模式。使用缓存的好处包括：

降低延迟：内存的高性能
更高的吞吐量：内存的高性能
可扩展性：缓存比数据库更容易扩展
数据库减压：可以将数据库任务卸载到缓存执行
高可用性：如果数据库宕机，缓存仍可对外服务

使用Redis，Memcached作为缓存是一种非常普遍的做法，但这一类缓存为Key/Value模式，而Oracle数据库是关系型，因此需要额外的开发在两种模式间做转换。如果使用TimesTen，由于都是关系型数据库，加之作为同一家公司的产品，Oracle和TimesTen之间做了深度集成，因此缓存的管理会更简单，包括定义，配置更改，刷新等，这些都不需要编程来实现。应用程序只需要将连接指向TimesTen即可，之前在Oracle运行的SQL也可以在TimesTen上运行，可以无需修改或经过很少的修改。

也就是说，使用TimesTen实现的只读缓存，不仅运行得快，而且开发也快，管理更简单。

关于此模式，可参考eBay使用TimesTen满足每日服务1400亿调用并满足延迟要求的案例。

模式2：TimesTen作为Oracle数据库写缓存

在这里插入图片描述
TimesTen也可以作为Oracle数据库的写缓存。在这种模式中，数据的流向和模式1是相反的，也就是数据先进入TimesTen，然后再自动同步到后端的Oracle数据库中，这特别适合于数据采集和数据汇聚类的应用，如IoT。

这种模式可以极大减轻后端数据库的压力，提升整体架构的稳定性和高可用性。另外，和模式1一样，缓存管理简单，开发快也是其差异化优势。

TimesTen作为写缓存还支持一种滑动窗口模式，可以按照用户的业务需要在内存中自动保留指定时间窗口期内的数据，如一周，半个月或一个月的数据，从而可以更精准地满足业务需求，也可以将更多后端Oracle的负载转移到写缓存中来运行。

关于此模式，可参考Oracle官网的美国邮政服务使用TimesTen实现防欺诈的案例。

模式3：TimesTen替换中小型数据库

在这里插入图片描述

这里说的中小型数据库是指数据量相对较小，并发访问相对较少。

TimesTen本身就是一个关系型数据库，只不过数据全部在内存中。因此对于数据量不大（如<1TB），同时又需要满足低延迟访问的数据库，就可以直接使用TimesTen运行，这样架构更简洁，开发和运维也更简单。

作为商用数据库，TimesTen也支持高可用和灾备等企业级功能。

关于此模式，可参考Oracle官网的Ericsson使用TimesTen实现实时计费的案例。

在《铁路计算机应用》2019年第28卷第2期，也有一篇用户文章“基于TimesTen内存数据库提升股道现车同步应用性能的研究与测试”可以参考。

模式4：TimesTen替换大型数据库图片

在这里插入图片描述

此模式和模式3几乎是相同的，区别在于，模式3使用的是TimesTen Cassic，即TimesTen传统模式。而模式4使用的是TimesTen Scaleout，即TimesTen分布式内存数据库。TimesTen Scaleout支持更大的数据量，以及更高的并发访问请求。

和TimesTen Classic一样，TimesTen Scaleout也是关系型数据库。在和某一能源客户的联合测试中，数据迁移到TimesTen后，应用未经修改仍可以正常运行。

关于此模式，可参考Oracle官网的中国移动使用TimesTen Scaleout用于营销推广的案例。

模式5：TimesTen作为实时ODS

在这里插入图片描述

这种模式和模式2有些类似，都充分利用了TimesTen的内存计算和关系型数据库的特点。但此处TimesTen不是缓存，而是作为多数据来源的数据汇聚后的高速计算引擎，和后端数据库的耦合度更低，因此也更灵活，后端不限于Oracle数据库。

模式6：Oracle Database In-Memory实现极速分析图片

在这里插入图片描述

从技术层面看，TimesTen是一个独立开发的产品，而Database In-Memory是Oracle数据库的一部分。Database In-Memory是Oracle融合数据库的重要特征，也是实现Oracle数据库HTAP能力的重要技术。

由于Database In-Memory技术，Oracle被主流研究公司评为Translytical（HTAP的另一种说法）数据平台领导者。Forrester Research在报告“Forrester Wave™：Translytical 数据平台，2019 年第 4 季度”中指出：“与其他供应商不同，Oracle 使用双格式数据库（同一个表的行和列）来提供卓越的 Translytical 性能”，并且“客户喜欢 Oracle 支持多种工作负载的能力，包括 OLTP、物联网、微服务、多模型、数据科学、AI/ML、空间、图形和分析。”

关于Database In-Memory的技术介绍，可参考之前的公众号文章：“加速度：走进Oracle Database In-Memory”。关于案例，可参考之前的公众号文章“海信Oracle Database In-Memory案例分享”，或Oracle官网上的更多案例。

模式7：True Cache 作为Oracle数据库只读缓存

在这里插入图片描述

此模式是模式1的深化。相对于TimesTen，True Cache和Oracle数据库之间的集成度更高，因为True Cache就是无盘的Active Data Guard 备库，只不过数据在内存中。

传统的读缓存模式，用户经常纠结于缓存刷新的频率。如果太频繁，担心对后端数据库造成太大压力；如果间隔太久，又担心数据太陈旧。使用True Cache就完全没有此顾虑，因为数据变化利用ADG的重做日志传输机制自动刷新到True Cache。

由于Oracle数据库支持JSON，因此除了SQL缓存，True Cache也支持Key/Value缓存。开发层面也更简单，传统模式需要维护两个连接，一个到缓存数据库，一个到源数据库。而True Cache也支持应用层面的连接统一管理，例如Java应用可以仅通过设置属性，就可以自动在True Cache（只读）和原始Oracle数据库（需要写时）间进行切换。

关于True Cache的更多信息，请参考Oracle官方网页。在True Cache正式推出后，我们也将发布详细的介绍文章。

结语

以上就是Oracle内存计算典型的应用模式，大体可以分为独立内存数据库（集中式和分布式），内存缓存（只读缓存和读写缓存）两类。从商务模式来看，TimesTen可以作为独立的数据库销售（TimesTen Classic和TimesTen Scaleout），即TimesTen In-Memory Database；当作为Oracle数据库前端的缓存时，TimesTen被视为数据库选件，即TimesTen Application-Tier Database Cache。Database In-Memory只作为数据库选件售卖，True Cache的商业销售模式，则有待23c 本地版正式发布时揭晓。

有了模式以后，最重要的就是确定在何种场景下应该（或不应该）选用哪种模式。以上列举的几种应用模式，TimesTen占比较大，这是由于TimesTen作为独立产品，使用方式比较灵活，是一种偏广度的产品；而Database In-Memory和True Cache依存于Oracle数据库，是一种偏深度的解决方案。具体选用哪种产品和技术方案，取决于实际技术需求，投入，用户现有架构，开发和运维能力和偏好，以及未来的目标架构等因素。如果您有这方面的需求或问题，请联系我们，让我们共同规划出适合您的产品和解决方案。