關於作者：
王輝，某大型股份制銀行資料庫專家。 擁有多年銀行資料庫開發、運維管理經驗，精通各類資料庫，主要負責國內分布式資料庫的研究、測試、選型和推廣工作，對分布式資料庫有深入的研究和實踐經驗，先後在多個技術峰會上分享國內分布式資料相關課題。
分享劇情梗概
1、使用現狀分析。
第二，它真的需要分發嗎？
3.何時使用分布式。
第四，如何利用好分銷。
5、深度分析：分布式是資料庫方案還是應用方案。
6. 總結。 OLTP業務系統是採用集中式資料庫還是分布式資料庫，是國內資料庫改造中經常被問到的問題，無論是為了技術架構的發展演進，還是為了現有業務的長遠發展提供必要的支撐。 在分布式盛行的背景下，似乎任何架構都需要分布式賦權。 真的是這樣嗎？下面將進行全面的分析和闡述。
1、使用現狀分析。
2024年國內資料庫廠商將超過200家，而傳統的中心化資料庫主要是金倉、大盟，以及PolarDB等新興資料庫，以及GaussDB、KingWow、TDSQL等分布式資料庫，其實這些資料庫大多有集中式和分布式兩種部署模式，也就是你買分布式資料庫的錢也可以用於集中部署， 可以滿足您不同的業務需求。
這裡需要注意的是，一些分布式資料庫供應商使用集中式部署，應用程式仍然需要連線到計算節點。 以下資料節點可以通過計算節點（CN）進行連線，這可能是出於對統一架構的考慮，也可能是因為計算節點在資料庫主備切換時，可以感知到自動切換，對應用透明。 但是，這無意中增加了一層解析，這將導致一定的效能損失。 一些資料庫廠商通過自己的JDBC ODBC驅動或VIP驅動直接連線到資料庫，以避免類似問題。
從技術架構來看，金融行業使用的資料庫仍以中心化為主，分布式資料庫對大中型金融機構形成了有力的補充。 根據《金融行業資料庫**鏈上安全發展報告（2022）》的調查資料，中心化資料庫仍佔整個金融行業的89%，其中銀行佔80%，*和保險業佔90%以上，中心化資料庫在金融科技數位化程序中發揮著重要作用。 金融業分布式資料庫總體佔比達到7%，銀行業已超過17%，*行業和保險業相對較低。 換句話說，在我們的大部分業務中使用集中式資料庫是完全令人滿意的。
第二，它真的需要分發嗎？
由於只有乙個主資料節點，集中式資料庫具有架構簡單、運維方便、相容性好、價效比高等優點。
但也存在無法突破單機硬體限制、無法橫向擴充套件、效能和容量瓶頸等問題。
因此，當集中式資料庫不能滿足我們的效能和容量要求時，分布式為我們提供了很好的技術手段。 當我們要選擇分布式來解決中心化的問題時建議您在考慮之前先問以下問題：
是否可以通過優化集中式資料庫本身來解決問題不要進行重大的架構更改，例如優化引數、SQL 語句和業務邏輯。
是否可以通過增加主機資源分配來解決問題例如，通過增加 CPU 和記憶體大小或使用虛擬機器而不是物理機來解決此問題。
儲存和計算分離是否可以解決問題？如果單台機器的容量不能滿足要求，可以考慮外接儲存，或者採用存算分離的架構，解決單台機器磁碟容量有限的問題。
是否能通過應用層來解決，例如，如果改變業務架構，採用微服務或單元化架構，即在應用層實現資料拆分、分布式事務、水平擴充套件等能力，而資料庫仍是中心化。這種方法對開發者要求高，業務改造成本高，需要綜合考慮。
是否充分了解分布式架構的優缺點您是否做好了分布式資料庫的運維備份準備，是否充分考慮了業務是否必須由分布式資料庫來解決。
3.何時使用分布式。
早期有2000w行的表需要拆分，這主要是針對MySQL資料庫的。 當OLTP表的行數超過2000W時，B+Tree的葉層數通過公式增加到4層，增加IO讀取次數。 但是，隨著硬體的公升級或快取技術的實施，IO的影響基本可以忽略不計。
因此，通常使用TPS或QPS指標來判斷是否需要分布式轉換，例如當單點TPS瓶頸達到4000，或者QPS達到8W，或者資料容量達到2TB時。 一般來說，做橫向擴充套件來解決效能或容量瓶頸是比較合理的，但這裡沒有固定的公式，主要需要根據自己的業務場景進行判斷。 還需要考慮未來業務增長的需求，比如是否能滿足3-5年業務的增長需求，做好高峰**，提前規劃，避免二次轉型。 同時參考上述問題，是否必須由分布式資料庫來解決。
實驗資料1（求拐點）。
硬體資源為基於ARM架構的鯤鵬虛擬機器環境，具體配置為16C64G，中標麒麟V10作業系統和普通SSD盤。
下圖為國內分布式資料庫的測試結果，該資料庫在秒內分布成 4 個分片。
單點索引查詢基本沒有差距，而對於全表掃瞄和雙表關聯（關聯表統一為200w行，均以分片鍵為關聯條件），資料量為500w時有明顯的5倍左右的提公升。
對於500W以下的資料量，您可以根據業務情況自行測試。 當然，在300W或更低的功率下也可能會有拐點，希望大家能在這裡給出更多的測試結果。 實驗資料可能會因多種因素而產生一定的偏差，也請指正，非常希望大家能把你的測試結果放在評論區，我們可以一起驗證分布式和集中式的效能拐點，以便為參考的選擇提供更準確的資料依據。
實驗資料二
下圖顯示了基於sysbench工具的廠商壓力測試結果
可以看出，在中型配置中，當集中式資料庫的資源利用率達到75%時，最大TPS為4595，延遲為5ms，併發為400。 這是乙個參考值，是上面提到的基本 TPS 超過5000時進行拆分的基礎。 當然，如果你的資源足夠大，這個值可以更大。 然而，最準確的判斷需要我們通過真實世界的壓力測試來驗證我們的 TPS 值。
第四，如何利用好分銷。
顧名思義，它是分布式的，多人工作，具有高可用、高擴充套件、高效能、彈性伸縮能力等優點。
由於資料節點數跟資料庫元件這種增長是必然會發生的架構複雜，運維複雜跟成本高同時，大多數分布式資料庫不支援儲存過程和自定義函式等特殊物件。
分布式是一把雙刃劍，我們如何用好它而不受傷是很重要的。
1. 分片鍵的選擇
分片鍵的選擇非常重要，選擇作為分片鍵的字段值應該是離散的，這樣資料才能均勻分布在各個資料節點上。 當單個字段無法滿足離散條件時，可以考慮同時使用多個字段作為分片鍵。 大多數情況下，您可以選擇表的主鍵作為分片鍵。 例如，在“人員資訊”（Personnel Information） 表格中選擇 ID 號作為分布鍵。 大多數分布式資料庫不支援或不建議修改分片鍵。
2、分銷模式的選擇
乙個常見的選擇是雜湊分布相對來說，分布比較均勻，還有範圍、列表等分割槽，當然我們最終需要根據具體的業務場景進行選擇。 此外，一些常用的配置資訊表或與查詢關聯的小表需要定義為全域性表，以保證在乙個資料節點上可以獲取，避免跨節點資料互動。
3.規範SQL語句的編寫
選擇分片鍵作為查詢條件，並將分片鍵作為多表關聯的查詢條件。 如果不使用分片金鑰，就會發生跨節點資料傳輸，一些分布式資料庫會彙總關聯所有資料聚合和計算節點，當資料較大時，計算節點資源會瞬間被填滿，導致資料庫無法向外界提供服務。
4.避免跨節點資料傳輸
如上所述，使用查詢條件作為分片鍵是為了最大程度的避免跨節點傳輸，因為跨節點資料傳輸是基於網路的，而網路與磁碟的傳輸和讀寫效能之間存在較大的差距，因此效能會明顯降低，甚至結果也無法執行。
5. 避免分布式事務
大部分資料庫都是基於2pc的原則，所以我們應該最大程度的避免分布式事務，一般控制在所有事務的10%以內，過多的分布式事務肯定會給我們帶來效能影響，同時也會給業務資料的一致性帶來挑戰。
5、深度分析：分布式是資料庫方案還是應用方案。
分布式資料的實現可以通過資料庫（分布式資料庫）或應用來解決，大多數開發人員，尤其是傳統行業或城商行等金融機構，開發能力不如大型銀行，而且人員規模有限，因此他們希望資料庫做得更多，例如分布式事務的實現和資料拆分， 並盡量對開發人員透明。因此，他們將直接使用分布式資料庫，以單元化架構為例，如下圖所示：
底層分布式資料庫是乙個單元化架構。
但是，一些重要的業務系統或具有一定開發能力的團隊會考慮更多地在應用層實現它們。 他們想要獲得更多的控制權，比如說，如果乙個分布式事務異常，如果是在資料庫層實現的，那麼相應的開發者就是乙個黑匣子，他只能期待資料庫的分布式事務處理能力，他們無法干預。 但是，如果在業務層實現，則可以處理訊息佇列、tcc、saga等資料補償機制獲取的日誌資訊。 因此，他們將在應用層實現分布式，資料庫採用集中的方式，每個資料庫儲存部分業務資料，以單元化架構為例，如下圖所示
底層集中式資料庫是單元化架構。
集中式資料庫和分布式資料庫在分布方式方面的差異總結如下：
百家助力計畫採用集中式資料庫，應用層對應用實現分布式特性的要求較高，但在資料庫層面的轉化較少，因為集中式資料庫的相容性優於分布式資料庫。
使用分布式資料庫，應用程式不需要實現分布式特性，對應用程式是透明的，但分布式資料庫不相容特殊物件，例如儲存過程和函式，甚至不支援它們，這就要求應用程式適應資料庫。
6. 總結。
在一次關於資料庫創新的圓桌論壇上，一位老師說：集中式資料庫就像乙隻羊，溫順且易於管理，而分布式資料庫是一匹野馬不羈難以控制，這讓我想起了宋冬野在歌曲《董小姐》中唱的那首歌，“我愛上了一匹野馬，但家裡沒有草原，這讓我感到絕望。 分布式資料庫的野馬是可以馴服的，它會讓你馳騁在大草原上，否則你會受苦和掙扎。 事實上，大多數開發人員仍然希望資料庫做得更多，開發人員轉換更少，資料庫更透明、更簡單，甚至更智慧型。
最後，我想說的是，我們國產資料庫還有很長的路要走，其實比起新功能的增加，客戶更關心的是基礎功能的提公升。 如果我們能把資料庫的核心儲存引擎和生態做好，那麼關於OLTP資料庫，我們就不深入討論這個話題了。
如果文章中有任何不準確或不專業的地方，請指正，謝謝。
本文為作者原創投稿，並非社群首發，如需**請聯絡***基礎技術研究。
DBAPLUS 社群歡迎技術人員的貢獻editor@dbapluscn