昨天我在高铁上和大家分享了一下Oracle 23C 的功能里的一个不是特别起眼的功能-True Cache，实际上从我第一眼看到True Cache这个名字的时候，就眼前一亮，上一回 Oracle 的组件有这种霸气的名字的是 RAC，Real Application Cluster。Oracle 推出集群解决方案 OPS 后，IBM ，HP很快也推出了自己的 cluster 解决方案，通过HACMP和MC SERVICE GUARD实现数据库的高可用自动切换。现在了解这个技术的朋友都知道，这实际上就是HA技术，不过20多年前的很多用户不大了解情况，认为二者是一码事，所以 Oracle 就把新一代的数据库集群命名为真正的应用集群，从而表现出与其他的一些所谓集群技术的不同。
Cache技术是近些年数据库应用领域方面的一项热门技术。早期的应用系统 中可能存在一些热数据的访问，这些查询十分频繁，给数据库增加了巨大的负担。应用程序通常需要在连接数量和可缓存数据量方面具有巨大的可扩展性，因此当Redis等内存KV数据库出现的时候，应用系统十分强烈的 拥抱了这种新技术。我们经常用到的方法是将缓存放在数据库前面， 这些缓存存在的原理是应用程序通常不需要查看最新数据，而是准实时数据，或者是某些数据相对来说是静态的。 例如，航空售票网站或者电商网站上，通常可以给浏览机票信息的用户显示一秒钟前的航班数据。只有提交订单时才需要去验证实时库存。那么近实时缓冲在这种应用场景可以有效的卸载主库负载，并通过内存缓冲来提高访问性能。不过这种缓冲还需要一个略微复杂的更新机制，从而确保数据总是处于有效范围。目前使用最广泛的缓冲数据库是内存数据库REDIS。
缓冲的目的无外乎两个，一个是提高访问性能，因此缓冲一般都使用内存；另外一个是卸载负载（offload），将针对主数据的访问卸载到缓冲中，从而减轻高负载的主数据的负担。
Oracle True Cache 使用内存缓冲的数据来满足查询。与 Oracle Active Data Guard 类似，True Cache 是主数据库的功能齐全的只读复制，但它大多是无磁盘的。在这种应用框架中，无需维护一套额外的内存数据库，应用程序通过 Oracle JDBC 驱动程序手动或半自动将查询发送到 True Cache。True Cache 实例使用它为它处理的数据库应用程序服务缓存的数据来处理查询，发生缓存未命中时，True Cache 实例从主数据库实例获取块。当 True Cache 实例首次启动时，除了在缓存未命中时获取块外，它还通过预读机制拉取数据所在的CHUNK的数据从而实现数据的快速预热。被缓存的数据块会通过主数据库的REDO APPLY自动更新，这种APPLY延迟通常小于一秒，可以满足绝大多数应用的需要。 这类似于 Oracle Data Guard 配置中的Real Apply模式。 主数据库重做块由主数据库实例上的 LGWR 进程以异步方式持续发送到 True Cache ，从而在确保主库性能的同时尽可能降低对主库应用的影响。昨天我粗粗地看True Cache的介绍的时候存在理解的错误，认为True Cache是同步的。当时我还在疑惑Oracle是采用了何种新技术，做到在开放平台的硬件上而不是一体机环境下实现同步应用的。
另外我昨天觉得True Cache技术与Oracle的MySQL Heatwave有异曲同工之妙，现在看来还是有些偏差的。与MySQL Heatwave相比，True Cache是一种轻量级解决方案。主要目的是实现应用缓冲，而Heatwave最主要的目的还是在MySQL上实现HTAP的能力，主要支撑重度的分析应用。Heatwave要对内存列数据进行持久化存储，而True Cache本身不需要硬盘持久化数据。
数据库产品的发展是为应用需求服务的，Oracle 23C在这个方向上走得很远。Oracle在数据库应用领域的一些技术创新是不是能够给我们的国产数据库一些启示呢？让数据库做得更多，还是让应用做得更多，这两个技术路线都拥有无数的拥趸。不过从数据库厂商的角度来看，多做一些简化应用开发的事情，是不是会让 自己的产品更具竞争力呢？在创新的实用性方面，我一向是相信Oracle的，我们的国产数据库厂商在暂时无法全面超越的时候，学习借鉴也是相当不错的。
