柏睿實時云數倉之「性能優化篇」· 實戰分享

柏睿實時云數倉性能優化篇來也！本文分享實戰經驗。前情可前往歷史文章回顧～

RapidsDB在云端的整體優化，可以概括為計算、存柏睿分布式內存數據庫儲、網絡三個方面，我們在這里分別做一些介紹。

再次強調我們優化的整體思路：雖然云計算號稱“按需付費”，但如果不精打細算，使用成本反而會增加很多。因此我們在優化柏睿實時云數倉的主要思路是：在成本可控的情況下，通過優化相關的云資源，提升柏睿分布式內存數據庫的性能。

一、計算如何優化？

在第二篇“根據CPU選云主機”中已介紹過如何選擇CPU和云主機類型，對于“團隊作戰”的RapidsDB集群，單純提升CPU 一點點頻率效果不會很明顯。

將數據庫集群規模擴大，將任務分配到更多的數據庫節點，這才是提升性能的最直接而有效的方法。由于是團隊作戰，所以要求所有數據庫節點CPU和內存配置是統一的，以方便統一調度管理。

CPU與內存的配置比率，我們在“選擇內存容量”中已介紹過，推薦1：4或1：8。但在數據庫中還是需要一些優化設置的。

RapidsDB是一個高度可擴展的分布式系統，運行在Linux 系統中。在每個數據庫節點，通過本節點的數據分區技術，實現多任務并行操作。例如在一個8vCPU的數據庫云主機節點，數據的分區數據量為8。

最后再對操作系統做一些常規的優化，如打開文件數量等。由于一些云廠商會調整優化Linux內核，因此不建議調整云主機的內核。

下圖是不同規模的實時云數倉集群，在TPC-H 500G的測試數據量性能報表，能看到整體計算性能隨著節點數量的增加而提升。

二、存儲如何優化？

在“選擇云硬盤”中已介紹過如何選擇硬盤，對于“團隊作戰”的RapidsDB集群，單純提升云主機一點點IO能力，性能提升效果不會很明顯。

將數據庫的存儲設置為獨立磁盤，避免與其他程序同時讀寫同一磁盤，這將會大幅度提升數據庫的存儲能力。

如果在云中運行的RapidsDB所在的業務有很頻繁的磁盤性能要求，可以通過在云主機中增加多塊云硬盤，組成RAID 0，實現更高的讀寫性能。對于為什么不做RAID 5，可以參考柏睿實時云數倉的安全文章。

下圖是不同規模的實時云數倉集群，從華為云存儲加載數據的時間，能看到隨著節點數量的增加，文件加載性能也有提升。

三、網絡如何優化？

在“選擇網絡能力”中已介紹過如何選擇網絡，很多人認為云主機在內網通訊的速度會很快，但在實際測試過程中，我們還發現一個隱含的小問題：

云廠商在不同物理位置有區域，在每個區域中又有不同的可用區。比如華為云在北京四區有4個可用區。

雖然在北京四這個區域中，每個可用區之間的網絡通信都是內網，但跨可用區網絡通信時，網絡延時會增加。下面是通過ping不同可用區之間的延時比較：

PING本可用區云主機延時

PING其他可用區云主機延時

從上面PING的測試數據能看到，跨可用區的網絡訪問對于柏睿云數倉這種分布式數據庫來說，還是有網絡影響的。如果需要高性能，還是將所有數據庫節點部署在同一可用區，如果出于數據安全考慮，可以參考原柏睿實時云數倉的安全文章，使用數據多副本并將數據庫節點部署在不同可用區。

最后，雖然在云計算環境中不建議調整網絡幀大小，但可以對一些常規網絡參數調整，如調整重試次數、FIN完成時間等。

下圖是不同規模的實時云數倉集群，網絡流量性能報表，能看到隨著節點數量的增加，網絡性能也有提升。

四、成本如何優化？

由于是團隊作戰，所以要求所有數據庫節點配置是統一的，以方便統一調度管理。

隨著集群規模的擴大，使用成本也會擴大。基于RapidsDB的實時云數倉，使用云原生微服務架構，支持在線彈性增加、刪除數據庫節點，用戶在處理大型任務時彈性增加數據庫集群規模，在不需要高性能計算時可以減少數據庫集群規模，以實現云成本的優化。

守正出奇

最后，引用馮侖的自著《野蠻生長》中對“守正出奇”的修改：

“守正出奇”，“正”正路、正道，“奇”出人意料，“守正出奇”正道而行。突破思維、出奇制勝。就是用百分之七十的時間去想“正確”的優化方向，用百分之三十的時間研究運行環境與業務需求的變通。既不墨守成規，又有創新。

轉自：太平洋財富網

　　【版權及免責聲明】凡本網所屬版權作品，轉載時須獲得授權并注明來源“中國產業經濟信息網”，違者本網將保留追究其相關法律責任的權力。凡轉載文章及企業宣傳資訊，僅代表作者個人觀點，不代表本網觀點和立場。版權事宜請聯系：010-65363056。

延伸閱讀