海量關係型數據的存儲訴求
越來越多的企業在企業遷移上雲時開始使用MySQL數據庫業務存儲數據，其中不乏包括從Oracle轉型到MySQL的業務，這些業務往往對數據庫的要求極高，包括且不僅包括：
- 數據庫穩定性
- 數據庫高可用
- 數據庫併發承載能力
- 大量關係型數據的存儲能力
- ……
這裡我並不想討論以上1~3點，而是著重說一下：4.大量關係型數據的存儲能力
網上一直流傳MySQL不建議存海量數據，但是我相信，更多人沒有思考過為什麼會有這樣的建議，而是默默接受了，在海量數據的場景，選擇了分佈式數據庫。
其實，單表超過1億，MySQL也可以正常存儲，並出色的完成查詢，我們的生產環境是驗證過的（表1.8億，列很少，結構非常穩定，沒有DDL）,但單個MySQL確實不推薦存儲海量數據，建議單表500W-1000W
個人理解的主要原因為：
- 1.數據量大，在進行DDL時，幾乎是毀滅級別的，雖然現在online DDL在逐漸完善，但仍有沒辦法進行online的操作，開銷很大，由於業務需求，為表增加列，往往是不可避免的，雖然可以用預留字段的方式一定程度上規避這個問題，但不可能為每張表都預留字段，預留字段也不可能無限多
- 2.隨著數據量的增長，索引的效率會越來越低（如insert的場景，insert當然和索引有關係，之後再單獨寫一篇文章吧），這個問題即使在Oracle上也是尤其明顯的；
- 3.備份恢復難，幾千萬甚至上億的表，備份與恢復的時間都會非常長，在出現異常需要恢復時業務恢復時間變得不可控。
越來越多的用戶意識到了這個問題，開始去使用分佈式關係型數據庫，目前仍然被討論的比較多的是開源代表MyCAT，以及阿里雲DRDS。
關於阿里雲DRDS
有幸在2016年，深度參與了使用阿里雲DRDS的上雲項目，理解了DRDS的組成架構，由於業務上的需要，做過包括功能、擴展性、最大性能等測試，在高可用的場景中，將DRDS的node節點、管控節點，均進行過進程級kill、主機級poweroff等，測試下來，DRDS運行非常穩定。
目前我們生產環境通過DRDS的橫向擴展能力，最大的單個DRDS實例已經存儲了百億級數據，峰值QPS達到10W。
生產業務峰值達到10W QPS
對比DRDS與開源分佈式數據庫解決方案：
- 從產品活力的角度來說，DRDS在2018-2019今年的今天版本迭代10餘次，再去看其他分佈式數據庫解決方案，基本上已經停更。
- 從產品成熟度與易用度的角度來說，DRDS擁有全面化的操作、在線實時生效、完善的擴縮容解決方案，其他開源方案基本上是配置文件、手工操作的原始狀態。
- 從產品支持的角度來說，DRDS有強大、專業、穩定的開發與維護團隊，開源方案在使用前，要投入大量人員“吃透”這個產品，否則出現問題，幾乎無法解決。
數據是企業的核心價值，數據庫可以說是企業的命脈，在選擇數據庫上，要慎之又慎。
下次介紹一下DRDS的架構，以及在使用DRDS時，受到了分庫鍵的限制，如何解決多維數據查詢的問題。
仔細思考，你一定會有所收穫。
歡迎關注：雲架構那些事兒，專注實用性雲架構分享與IT技術分享。
