- 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进行容量的评估。
先展示下效果：
