柏睿實時云數倉性能優化篇來也!分為三章。本文為第一章，歡迎閱讀。本文作者：柏睿數據產品研發總監陳海富
柏睿實時云數倉為BI分析業務提供強勁的計算發動機——數據庫服務。如何優化云數倉性能?由于其運行在云計算平臺中，與傳統物理機優化方法有很大不同。傳統物理機運行環境中的數據庫優化方法，主要有：
1)CPUNUMA優化大法：物理服務器有多顆物理CPU，由于每顆CPU負責獨立的內存控制器，當跨CPU訪問內存空間時，會出現很大的延遲。但在云環境中的云主機，沒有NUMA造成的跨內存控制器問題。
2)網絡巨型幀：巨型幀是指將以太網協議中的幀長大于1522字節的以太網幀，通過將每幀能夠多傳輸內容，來增加網絡傳輸效率。但在云環境中，網絡設備主要由虛擬化實現，不建議調整太網幀大小。
換網絡協議：物理環境中網絡傳輸慢，可以換成IB網(InfiniBand network)。但在云環境中，這幾乎是不可能的。
3)換性能更高的硬件：物理環境中的硬盤、CPU都可以換成性能更高的硬件。例如機械硬盤速度太慢，固態硬盤速度提速還不夠強，將傲騰內存當做硬盤速度才能飛快。但在云環境中，可能不會有你想換的硬件型號。而且云計算的計費方式是“按需付費”，即按使用量來付費，當需要更高的磁盤IO性能，就需要購買更大的空間，由此性能調優還要考慮成本。
當然在云計算環境中，是可以直接租用裸金屬服務器來部署應用程序，但需要考慮云中物理服務器配置固定，而且成本會比較高。下圖是截至2022年4月17日，華為云裸金屬服務器的價格。
所以我們在此分享一些柏睿實時云數倉在純云環境中的優化經驗，希望能給大家提供一些性能優化啟發。
一、先謀后行
數據庫性能優化需要考慮自身軟件所依賴的計算、存儲、網絡等多個資源，是綜合性問題，需要全盤思考，再多方處理。
雖然云計算號稱“按需付費”，但如果不精打細算，使用成本反而會增加很多。因此我們在優化柏睿實時云數倉的主要思路是：在成本可控的情況下，通過優化相關的云資源，提升柏睿分布式內存數據庫的性能。
二、知己知彼
優化數據庫整體性能，需要先了解優化的數據庫業務架構，才能做出更好的調優方法。
柏睿實時云數倉使用自研的分布式全內存數據庫RapidsDB，屬于OLAP分析型數據庫。與傳統的OLTP交易型數據庫從業務到架構是有很大區別的。
下表是OLAP與OLTP的一些簡單比較，從比較中能看出OLAP主要以讀為主，而OLTP主要是寫入為主。
三、一夫當關or團隊作戰
OLAP與OLTP數據庫由于關注的業務不同，所以軟件在工作方式和優化方法會有一些不同。
OLTP業務主要業務場景是交易記錄的準確性，因此需要寫入具有唯一性，所以傳統針對OLTP數據庫的優化方法將負責寫入的“一夫”節點性能大幅提升，如使用更快的CPU，增加更多的內存，使用將內存當做磁盤用的傲騰存儲，使用IB網絡(InfiniBand network)等。
但個體設備的配置提升，會遇到天花板。于是近年來有人提出將數據庫進行分庫分表，增加寫入節點的數量而提升寫入能力。通過將數據復制到多個只讀節點，提升數據讀的能力。
比如對于一個記錄用戶名數據庫，按姓名拼音的第一個字母拆成26個數據庫，這樣就可以將原來只能由一個庫來寫，變成分別由26個庫來寫入，從而提升寫入能力。但每個分開的庫還是只能有一個寫入，還是有種“一夫當關，萬夫莫開”的意思。
柏睿自研的分布式全內存數據庫RapidsDB基于MPP并行計算架構，集群的性能隨著節點規模的增加而增加。
MPP架構示例圖
下圖是RapidsDB在同一個業務場景下，不同規模的集群性能比較。能夠看到隨著數據庫節點的增加，整體性能有明顯提升。
由此可見，RapidsDB的技術架構類似于“團體作戰”風格，所有的數據庫節點都能同時協同戰斗，因此提升的性能不是由個體決定的。
例如在一個具有5個數據庫節點的RapidsDB集群里，用戶要導入1000T的數據文件任務，是由5個數據庫節點將1000T任務分散同時完成。如果性能不夠，再加數據庫節點就可以實現性能提升了。
以上分析，僅從技術架構而言，并不能完全說明哪種技術是最好。只有適合業務，才是最好的技術。
