- 2月6號釘釘上了中央電視台，釘釘CTO接受采訪
4 、DB容量預估及性能分析
業務上往往通過集群的CPU情況即可大概分析出系統的水位，但是對DB而言不僅是CPU，IO，網絡，SQL，鎖等等，任何一個組件的瓶頸往往都會成爲最終容量的瓶頸。不同的業務模型，往往瓶頸都不一樣，即使都是查詢量較大的業務，有些可能是cpu的瓶頸，有些可能是內存命中率不夠導致的瓶頸，有些則是索引設計不合理導致的瓶頸。更複雜的部分在于，有些瓶頸往往不是線性的，可能壓力提升2倍還沒什麽問題，硬件能力都還有富余，但是提升到3倍就直接挂了。在這種場景下我們如何比較准確的評估DB的容量呢？
以往我們都是通過經驗並和業務方一起進行全鏈路壓測進行DB容量（集群能支撐多少讀寫）的預估，這種方式有以下幾個問題：
- 壓測數據集和數據庫總量相比往往比較小，DB命中率基本100%，這對于分析有IO的業務模型存在較大誤差
- 成本較大，需要打通上下遊整個鏈路，較多的同學參與
- 即使全鏈路壓測，真正壓到DB端的往往也只是核心的幾個接口，無法100%覆蓋線上所有的接口，而很多慢SQL往往都來自這些易忽略的接口
解決這個痛點問題的方法大家其實很容易想到–只要把線上的業務流量全部采集下來回放一遍即可，但實現起來是非常複雜的。我們真正需要的其實是針對DB的一種通用的單鏈路壓測能力，並不依賴上遊業務，DB層可以自己進行流量的生成，放大或縮小，甚至將事務比例更改後再次壓測的能力。
從2019年開始，在DBA和達摩院數據庫實驗室科學家們共同的努力下，我們開發了ClouDBench實現了上述的需求，並在此次的戰役中幫助DBA進行容量的評估。
先展示下效果：
