数据库参数智能优化论文的思考

这是学习笔记的第 2084 篇文章

今天在圈子里面有一篇文章很火，

前沿 | VLDB 2019论文解读：大规模数据库智能参数优化的创新与实践

在智能运维方向上算是迈出了坚实的一步，而这篇文章对运维方向的感触很深的一个原因就是优化的切入点很准很实际，而不是以模型先行的偏理论方向的优化。

而换句话来说，我们在感叹这个思路的同时，会不禁冒出来一些想法，我们能不能这么做，这么做对我们的收益大吗。智能运维方向在前期的投入是比较大的，而且本身智能方向的理论门槛较高，从我的理解来说，以一个具体的业务场景做深做透，融入智能方向，会有一些帮助，而以这个作为切入点，逐步延伸，使得前期的成本投入能够尽可能平摊出来，使得这件事情的意义更加明显。我们来算一笔账。

文章末尾这么说道：

经过算法探索和端到端自动Buffer Pool优化流程建设，FY2019集团内全网最终优化 ~10000 个实例，将整体内存使用量从 217T内存缩减到 190T内存，节省 12.44%内存资源(27TB)。

按照计算方式，假设是单机单实例的部署方式，平均一个实例会优化2.7G左右的内存资源，如果把这个成本折算出来，按照内存PC价格16G 700元的架构来算，即为：27000/16*700~1181250元，大概是100多万。对于大多数公司来说成本优化效果达到了百万，那还是很值得去做的。

但是我们换一种思路，一般的互联网公司的数据库规模我们计算为200，那么按照这个思路来进行成果转化，节省内存为：2.7G*200=540G,成本为：540/16*700~23625元,我想你作为一个管理者，基本都会拍掉这个方案，因为投入和结果明显不成正比，按照优化空间加倍，那也大概在5万左右，相比于服务器层面的成本，这个成本其实不高。而这也是很多互联网公司和大厂的差距所在，也是很多运维场景难以落地的一个原因。

那对于我们来说，是不是就不需要做这些了，其实不是。我们不能指望所有的环境都一步到位，你只需要露个脸事情就能搞定。而现实中很多公司是没有工程师文化的，而换一步来说，以技术驱动的公司几乎不存在，包括耳熟能详的大厂都是如此，因为技术不是源头，而需求才是。

我特别赞成那种把一件事情做到极致的方式，很多事情都是触类旁通，我们运维的数据库环境也是如此，如果你能够像呵护你的孩子/宠物一样去管理一台数据库，那么你投入的精力和成本是不低的，但是按照这种思路，我们可以复制已有的经验，来进行后续的工作补充，这样一套环境所在的业务在什么时候是高峰低峰，业务的设计和细节我们都一清二楚，架构和优化的工作自然不在话下。

智能运维带给我们的是更多的补充，是我们通过常规运维难以发现和掌握的信息。比如一个数据库实例的多个属性信息，假设有10个，怎么进行提炼聚合，找到主成分，提取相应的标签信息的时候，面对大量的数据，常规的思路就不起作用了，这就需要进一步的提炼，通过模型来进行梳理改进。

或者你统计一个服务的性能，阈值区间如何设置，是按照60~80%来设置，还是按照70%来设置更好，这些对于很多传统的运维来说，都是靠直觉和经验。

我觉得无论是对于运维和开发工作来说，能够在庞大的数据中发掘出哪些潜在的问题，能够一针见血的指出问题，对我们来说就是一种福报了，给出的建议不一定多，但是足够有效。我们评估一个方案总是希望可靠，可控，一旦形成这种思维的边界，那么我们就可以把这些经验能力快速转化出来，能够反哺去做更有价值的事情，使得这是一个可持续的改进过程。

对于运维的改进来说，智能是大方向，而目前的工作依然可行，只是时间长短的问题。而在实践的过程中，需要的还是平衡，很多事情单纯从技术和业务价值去看，都是不对等的。

我们的现实工作通俗来说，可以分为学院派和工程派，这些年我们看到了很多学院派融入工程派的工作，智能运维就是一个典型，而一旦工程派反向融入学院派，那么这个事情的推动力会更加强大，因为"让听见炮声的人来指挥”杀伤力是最大的。

个人新书 《MySQL DBA工作笔记》