JanusGraph — 快取（janusgraph caching）

• 2019 年 10 月 4 日
• 筆記

13.1 Caching

JanusGraph採用多層數據快取來促進快速圖形遍歷。這裡按照從JanusGraph事務中訪問它們的順序列出了快取層。快取越接近事務，快取訪問越快，記憶體佔用和維護開銷就越高。

13.2 Transaction-Level 快取

在一個打開的事務中，JanusGraph維護著兩個快取：

• Vertex 快取：快取訪問的頂點及其鄰接列表（或其子集），以便後續訪問在同一事務中明顯更快。因此，該快取加速了迭代遍歷。
• Index 快取：快取索引查詢的結果，以便後續索引調用可以從記憶體中提供，而不是調用索引後端，並且（通常）等待一次或多次網路往返。

這兩者的大小由 transaction cache size決定。事務快取大小可以通過快取配置 cache.tx-cache-size配置。通過事務構建器graph.buildTransaction()打開事務並使用setVertexCacheSize(int)方法，可以根據每個事務打開一個事務。

13.2.1 Vertex 快取

頂點快取包含頂點及其在特定事務中檢索的鄰接列表的子集。此高速快取中維護的最大頂點數等於事務高速快取大小。如果事務工作負載是迭代遍歷，則頂點快取將顯著加快速度。如果在事務中不再訪問相同的頂點，則事務級快取將沒有區別。

請注意，堆上頂點快取的大小不僅取決於它可以容納的頂點數量，還取決於它們的鄰接列表的大小。換句話說，具有大鄰接列表（即許多入射邊緣）的頂點將比具有較小列表的頂點消耗更多空間。

此外，請注意，修改後的頂點固定在快取中，這意味著它們無法被驅逐，因為這將導致失去其更改。因此，包含大量修改的事務最終可能會使用大於配置的頂點快取。

13.2.2 Index快取

索引快取包含在此事務的上下文中執行的索引查詢的結果。隨後的相同索引調用將從此快取提供，因此明顯更便宜。如果同一個索引調用在同一個事務中永遠不會發生兩次，則索引快取沒有區別。

索引高速快取中的每個條目的權重等於，2 + result set size並且高速快取的總權重不會超過事務高速快取大小的一半。

13.3 Database Level 快取

資料庫級高速快取在多個事務中並且在單個事務的持續時間之外保留鄰接列表（或其子集）。資料庫級快取由資料庫中的所有事務共享。它比事務級別快取更節省空間，但訪問速度也稍慢。與事務級別快取相比，資料庫級快取在關閉事務後不會立即過期。因此，資料庫級快取顯著加快了跨越事務的讀取繁重工作負載的圖形遍歷。

第15章，配置參考列出了與JanusGraph的資料庫級快取有關的所有配置選項。此頁面解釋了它們的用法。

最重要的是，默認情況下，在當前版本的JanusGraph中禁用資料庫級快取。要啟用它，請設置cache.db-cache=true。

13.3.1 快取到期時間

性能和查詢行為最重要的設置是通過配置的快取過期時間cache.db-cache-time。快取將保存圖形元素最多幾毫秒。如果元素到期，則在下次訪問時將從存儲後端重新讀取數據。

如果只有一個JanusGraph實例訪問存儲後端，或者此實例是唯一修改圖形的實例，則快取過期可以設置為0，從而禁用快取過期。這允許快取無限期地保存元素（除非它們由於空間限制或更新而被逐出），這提供了最佳的快取性能。由於沒有其他JanusGraph實例正在修改圖形，因此不存在保持過時數據的危險。

如果有多個JanusGraph實例訪問存儲後端，則應將時間設置為修改圖形的另一個 JanusGraph實例與查看數據的JanusGraph實例之間允許的最長時間。如果所有JanusGraph實例都應立即看到任何更改，則應在分散式設置中禁用資料庫級快取。但是，對於大多數應用程式來說，特定的JanusGraph實例可以通過一些延遲看到遠程修改。最大允許延遲越大，快取性能越好。請注意，無論配置的快取過期時間如何，給定的JanusGraph實例將始終立即看到自己對圖形的修改。

13.3.2 快取大小

配置選項cache.db-cache-size控制允許JanusGraph的資料庫級快取消耗多少堆空間。快取越大，它就越有效。但是，較大的高速快取大小可能導致GC過多和性能不佳。

高速快取大小可以配置為運行JanusGraph的JVM可用的總堆空間的百分比（表示為0到1之間的小數）或絕對位元組數。

請注意，快取大小是指快取專用的堆空間量。JanusGraph的其他數據結構和每個打開的事務都將佔用額外的堆空間。如果其他軟體層在同一JVM中運行，那麼這些軟體層也可能佔用大量的堆空間（例如Gremlin Server，嵌入式Cassandra等）。保守堆記憶體估計。配置太大的快取可能導致記憶體不足異常和過多的GC。

13.3.3 清理等待時間

當本地修改頂點（例如添加邊）時，所有頂點的相關資料庫級快取條目都被標記為已過期並最終被逐出。這將導致JanusGraph在下次訪問時從存儲後端刷新頂點數據並重新填充快取。

但是，當存儲後端最終一致時，觸發驅逐的修改可能尚不可見。通過配置cache.db-cache-clean-wait，快取將在使用從存儲後端檢索的條目重新填充快取之前至少等待這麼多毫秒。

如果JanusGraph在本地運行或針對存儲後端運行，以確保立即可見修改，則此值可以設置為0。

13.4 Storage Backend 快取

每個存儲後端都維護自己的數據快取層。這些快取受益於壓縮，數據緊湊性，協調過期，並且通常在堆外維護，這意味著可以使用大型快取而不會遇到垃圾收集問題。雖然這些快取可能比資料庫級快取大得多，但它們訪問速度也較慢。

如果轉載此博文，請附上本文鏈接https://blog.csdn.net/csdn___lyy，謝謝合作~ 如果感覺這篇文章對您有所幫助，請點擊一下「喜歡」或者「關注」部落客，您的喜歡和關注將是我前進的最大動力！=.=