異數OS 織夢師-水桶(三)-- RAM共享儲存方案
.
異數OS 織夢師-水桶(三)– RAM共享儲存方案
本文來自異數OS社群
github: https://github.com/yds086/HereticOS
異數OS社群QQ群: 652455784
異數OS-織夢師(訊息中介軟體 RPC技術)群: 476260389
織夢師-水桶 RAM共享儲存簡介
織夢師-水桶 是使用異數OS IPC技術設計實現的一種共享介質層儲存方案,得益於IPC的簡單易用,因此水桶的設計過程是非常輕鬆容易的,也因此也更加方便使用者定製擴充套件,由於異數OS IPC效能的突破,他也因此提供了其他系統無法提供的一些激動特性與能力。
與眾不同的特性
- 簡單的框架,簡單的實現,使用IPC技術,不需要重量級的定義功能和通訊協議,整個實現加測試僅500行程式碼。
- 網路共享儲存特性 傳統的介質儲存方案,只能訪問者獨佔使用,不能分散式擴充效能與容量,因此在使用中受到了極大的能力限制,原因有兩點,一是儲存介質被硬體結構控制一般不能直接支援網路訪問,二是介質儲存只提供讀寫訪問能力,對於多個讀寫者而言,不能彼此同步cache,造成多訪問者環境出現不可預知的資料故障,因此一般介質儲存之上需要複雜的檔案系統(分散式)來對介質做獨佔訪問,比如iscsi技術雖然解決了介質的網路訪問問題,但卻無法解決多訪問者系統的cache同步,一致性等問題,因此iscsi並不能獨立提供儲存方案,還需要宿主作業系統的檔案系統做支援,才能為應用提供共享的儲存能力,織夢師-水桶則通過IPC技術解決了上述傳統介質儲存中問題,水桶可以使用TCP網路RPC來實現擴充套件遠端訪問的能力
- 方便定製 由於是軟體介質儲存方案,因此並不需要符合一些硬體規範的通訊協議,比如scsi,nvme等,使用者可以根據自己需求改變功能設計,增加寫入日誌,定製訪問事件,甚至將介質儲存改變為物件儲存,也是很容易完成的。
- 方便的定製擴充nosql能力,提高nosql的一些實際業務效率,降低需求對newsql技術的依賴,長久以來nosql在提高和擴充系統容量效能,降低系統設計複雜性方面成效卓著,但nosql由於缺乏事務能力,資料結構能力固定,導致一些上層業務邏輯設計無法直接在nosql之上落地,織夢師-水桶由於使用rpc技術實現,在介質層有望提供事務定製,業務服務定製能力,將事務以及業務下沉到介質儲存層有利於真正解決一些資料業務的效率問題,比如將sql的select操作下沉到儲存層後,將大大降低對nosql的網路io需求,提升系統tps能力,因此從根本上使得nosql技術可以快速定製落地滿足複雜專案業務需求,從而降低對newsql的需求依賴(newsql並不能高效的適應加速所有業務場景,本身對網路IO的效能以及延遲依賴較大)。
- 更靈活高效的介質訪問方案 傳統的介質訪問技術由於考慮到linux windows等傳統作業系統的實際能力限制,所以使用了更大的塊儲存單位,主流的硬碟 SSD都使用4096位元組的塊讀寫單位,以便於在linux windows約束下,更有利的發揮硬體頻寬,但這卻沒有解決實際需求問題,反而帶來更多效能障礙,織夢師-水桶則提供小到16位元組的塊訪問單位,在同樣頻寬和記憶體開銷下,相比4096位元組的塊,16位元組在隨機讀寫效能上,理論上則可達到4096位元組的256倍,同時上層cache(redis)在快取小資料時(16位元組)同樣的記憶體開銷則可快取256倍的資料項,或者在快取同樣資料項的網路頻寬需求降低64倍,由於可變讀寫長度的優勢,因此在做物件儲存時對頻寬以及記憶體的利用則變的毫無冗餘。
- 10倍以上隨機讀寫效能 在SSD成為主流儲存方案後,一些基於linux windows作業系統開發的網路分散式cache方案甚至因此磁碟io效能的不適應而被淘汰,原因是SSD在儲存容量以及隨機讀寫效能以及資料安全可用性上都優於網路cache產品,但現在情況不同了,異數OS由於網路IO瓶頸解除,使用異數OS開發的cache在隨機讀寫效能上達到SSD 10倍以上,並且由於共享儲存特性,則可以很容易做到分散式容量和效能的擴充。
織夢師-水桶 方案說明
1.WriteNotifyClient 啟動後在DiskIPCServer註冊關注的塊寫入事件IPC,DiskIPCServer收到註冊請求後啟動一個對應的WriteNotifyPushThread,WriteNotifyPushThread等待一個寫入事件event.
2.ReadWriteClient通過DiskIPCServer提供的DiskIPC服務讀寫RAM盤,DiskIPCServer在Write IPC中檢查write操作,如果有關注的塊寫入事件,則觸發相關event, 相關聯的WriteNotifyPushThread因此活躍並通過IPC推送event到WriteNotifyClient。
demo實現以及測試程式碼在git目錄的test目錄下,有興趣的可以觀摩下。
織夢師-水桶測試成績
測試專案中元件通訊分為LPC RPC兩種,讀測試主要是64執行緒64位元組序列讀和隨機讀,寫測試以及WriteNotify的成績暫時不提供,原因是WriteNotify回和持久化策略以及上層檔案系統事件響應能力有關係,LPC是單核環境下,本地服務執行緒間通訊,RPC是異數OS TCP協議棧實現的跨網路通訊,環境是dpdk 82599 10G網絡卡環境,所有測試成績均是指每核效能。
LPC本地64位元組序列讀
LPC本地64位元組隨機讀
RPC TCP遠端64位元組序列讀
RPC TCP遠端64位元組隨機讀
相關儲存產品效能對比
資料來自網路,環境目標不同,選取目標產品最大效能值,成績僅供參考。
引用的其他產品測試成績
Intel 900P
https://www.chiphell.com/thread-1788441-1-1.html
https://baijiahao.baidu.com/s?id=1588310894168427063&wfr=spider&for=pc
redis
https://blog.csdn.net/zlfprogram/article/details/74338685
測試特性 | LPC 64位元組1執行緒序列讀 | LPC 64位元組1執行緒隨機讀 | RPC 64位元組64執行緒序列讀 | RPC 64位元組64執行緒隨機讀 | Intel 900P SSD 4K DQ1隨機讀 | Redis 非批量讀 | Redis 批量讀 | 阿里 PolarDB RDMA |
---|---|---|---|---|---|---|---|---|
IOPS | 13M | 6.4M | 4.1M | 3.5M | 55W(實際被作業系統約束在10W) | 8W | 50W | 20W |
平均延遲 | 呼叫效能/連結數量 | 呼叫效能/連結數量 | 呼叫效能/連結數量 | 呼叫效能/連結數量 | 10ms+呼叫效能/連結數量 | 10ms+呼叫效能/連結數量 | 10ms+呼叫效能/連結數量 | 10ms+呼叫效能/連結數量 |
最小延遲 | <1us | <1us | 10us | 10us | 1-10ms | 1-10ms | 1-10ms | 1-10ms |