溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
今天就跟大家聊聊有關Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。
摘要：我們將對 RocksDB、Heap 和 Gemini 在相同場景下進行壓測，并對其資源消耗進行對比。測試的 Flink 內核版本為 1.10.0。
測試場景
CheckpointInterval:10分鐘CheckpointingMode: EXACTLY_ONCECheckpointTimeout:3分鐘
setCompressionType：LZ4_COMPRESSIONsetTargetFileSizeBase：128 * 1024 * 1024setMinWriteBufferNumberToMerge：3setMaxWriteBufferNumber：4setWriteBufferSize：1GsetBlockCacheSize：10GsetBlockSize：4 * 1024setFilter：BloomFilter(10, false)
使用 MemoryStateBackend 需要增加非常多的 Heap 空間用于存儲窗口內的狀態數據（樣本），相對于把數據放到磁盤的優點是處理性能非常好，但缺點很明顯：由于 Java 對象在內存的存儲效率不高，GB 級別的內存只能存儲百兆級別的真實物理數據，所以會有很大的內存開銷，且 JVM 大堆 GC 停機時間相對較高，影響作業整體穩定，另外遇到熱點事件會有 OOM 風險。
使用 RocksDB 則需要較少的 Heap 空間即可，加大 Native 區域用于讀緩存，結合 RocksDB 的高效磁盤讀寫策略仍然有很好的性能表現。
state.backend=org.apache.flink.runtime.state.gemini.GeminiStateBackendFactory
// 指定Gemini存儲時的本地目錄kubernetes.taskmanager.replace-with-subdirs.conf-keys= state.backend.gemini.local.dirstate.backend.gemini.local.dir=/mnt/disk3/state,/mnt/disk5/state// 指定Gemini的page壓縮格式（page是Gemini存儲的最小物理單元）state.backend.gemini.compression.in.page=Lz4// 指定Gemini允許使用的內存占比state.backend.gemini.heap.rate=0.7// 指定Gemini的單個存儲文件大小state.backend.gemini.log.structure.file.size=134217728// 指定Gemini的工作線程數state.backend.gemini.region.thread.num=8
機器配置
作業使用資源對應參數
內存相關參數
對比結果
Note：全量的樣本拼接負載使用 16 臺機器無法完全服務，因此我們通過對數據進行不同比例的抽樣來進行壓測。當出現反壓時，我們認為作業已經達到性能瓶頸。
由以上對比可以看出，在數據、作業處理邏輯、硬件配置等都相同的前提下，使用 Gemini 成功處理的數據量是 RocksDB 的 2.4 倍（17280 vs 7200 條/s）。同時通過硬件資源消耗的對比可知，RocksDB 更快達到磁盤 IO 瓶頸，而 Gemini 則具備更高的內存和 CPU 利用率。
看完上述內容，你們對Flink使用RocksDB 和Gemini 的性能對比實驗分析是怎樣的有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
