什麼是 True Cache？

昨天我在高鐵上和大家分享了一下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的，我們的國產資料庫廠商在暫時無法全面超越的時候，學習借鑑也是相當不錯的。