智能运维之数据库容量评估

yangyidba 2020-09-09

3192

1.起因

数据库容量评估

离业务高峰期还有2个多月，老大安排了一个任务：数据库容量评估。

具体内容是：评估一下，需要新采购多少数据库服务器，来应对业务高峰期的业务访问量的上涨。

需要评估的库类型：mysql，tidb，mongodb，sqlserver和redis

时间很紧

任务时间是20天（去掉周末，也就3周），因为新采购服务器最快上架时间是一个半月，所以必须在20天内评估出来需要采购多少服务器。

2.正常方案

历史数据

第一反应是，从数据库的监控历史数据中，分析一下去年数据库服务器性能增长了多少，再根据这个数据，计算一下今年需要多采购多少服务器。

然，数据库监控数据只保留3个月，没有去年的历史数据。。。

正常思路

重新安排方案：

业务高峰期会引起应用对数据库访问量的上涨，数据库访问量的上涨会造成数据库性能压力会上涨。

按照这个思路，分解出以下几个子任务：

-评估出业务应用的访问量上涨幅度
-根据应用的访问量上涨幅度，评估数据库性能压力上涨幅度
-根据数据库性能压力上涨幅度，评估需要扩展多少资源
-最后计算需要新采购多少服务器

但这个方案，执行下来，困难重重。

业务应用的访问量上涨幅度

-如何评估在业务高峰期，业务量会上涨多少？

我司有多个业务部门，每个部门又有特别多的应用和接口。

光数据库实例就一万+了，可以想象前面的应用会有多少。。。

-业务开发无法评估每个应用的访问量上涨幅度。
-大数据组也没有相关的历史数据。

数据库性能压力上涨幅度

-哪些数据库性能压力会上涨呢？

应用和数据库是多对多的关系，每个部门的应用和数据库的架构，是一个非常复杂的关系网，目前没有它们之间的关联关系，所以无法评估应用访问量上涨会造成哪些数据库性能压力上涨。

-数据库性能压力会上涨多少呢？

比如应用上涨30%，数据库性能压力也上涨30%吗？肯定不是的，所以缺乏对应的计算方法。

评估需要扩展多少资源

-数据库性能压力上涨，会消耗多大的硬件资源呢？

比如压力上涨30%，硬件资源也对应的多消耗30%吗？显然也不是的，所以这里也缺乏对应的计算方法。

3.偷懒方案

重新制定方案

分析上面的方案，可以发现，方案无法实现的原因是缺失太多的数据和算法。

那么目前能够进行分析的数据有哪些呢？只有数据库和服务器的性能指标数据。

能不能凭借这些数据，评估出需要扩展的资源情况呢？

偷懒算法

先假设所有的数据库实例需要的资源会上涨100%。

方案就变成：

-计算出每个实例的最大资源使用
-最大资源使用乘以2，减去分配给该实例的资源，得到需要扩展多少资源

偷懒方案

-sqlserver都部署在物理机上

从zabbix监控数据中，可以获得CPUUtil，内存使用率，磁盘IO和网络IO。

-mysql，tidb，mongodb和redis，都部署在docker中

可以获得docker的CPU Util和内存使用率，实例磁盘IO和网络IO。

方案完成

四大资源指标抓取到之后，分析下来，发现除了redis，内存都用的很多，因为数据库实例都是缓存预分配机制。

于是去掉内存，把CPU util，磁盘IO和网络IO都乘以2，再减去分配给服务器或者docker的资源。

搞定了？

如果就这么结束的话，那我就不敢在标题中加智能这俩字。

4.智能方案

偷懒失败

用上面的算法算下来发现，需要新采购数据库服务器的数量为0。

其实很简单，如果当前数据库CPU和IO有问题的话，立马报警就出来了，负责的DBA马上就去解决了，该优化的优化，该扩展资源的扩展资源。

所以当前数据库实例，基本上都是资源使用率远小于一半的状态，就算乘以2，也不需要扩展资源。

峰回路转

需要新采购的服务器数量肯定不能为0，否则到了业务高峰期，真的哪个库炸了，没有资源扩展，那还得了。

而且上面的算法本身就有问题，怎么可能所有的数据库实例性能压力都上涨呢，而且怎么可能正好上涨100%呢。

等等，当然不可能所有的数据库实例性能压力都会上涨，那么会上涨的，只是其中的一小部分。

这一小部分实例有哪些特征呢？

-qps/tps相对较大
-CPU，磁盘IO和网络IO相对较大
-其他的性能指标也相对较大。

总结一下，就是相对于其他实例，这些实例的各种性能指标都较大。

将这一小部分实例过滤出来，再进行容量扩容，就能够得到需要采购多少服务器了。

专家模式

如何判断某个实例各种性能指标都相对较大呢？

用专家模式？比如设定：

CPU>XXX

and 磁盘IO>XXX

and 网络IO>XXX

and free内存>XXX

and qps>XXX

and tps>XXX

。。。

这种算法的问题很明显：

-这些XXX的数据，具体都是多少呢？

根本就没有对应的专家数据。。。

-仅仅这些指标就够了吗？

慢 sql指标要不要？活动连接数指标要不要？Busy_time指标要不要？全表/索引扫描指标要不要？数据库指标那么多，选哪些好？总不能都选吧，几百上千个指标，吓死人了。

-指标之间都是and算法吗？

假设10个指标，7个超标，3个没有超标，那么这个实例要过滤掉吗？

聚类

人工的不行，那来机器的。

这种情况其实属于聚类问题，把所有实例的性能数据，用机器学习划分成好几类。每个类别的数据都有相似的特征，挑出各种性能指标都较大这个类别的实例就可以了。

聚类的定义：将物理或抽象对象的集合分成由类似的对象组成的多个类的过程被称为聚类。

所谓物以类聚人以群分，实例只要有性能指标都较大的特征，就能够用算法聚在一起。

6.智能方案

指标的选择

聚类也是需要指标的，但是按照哪些指标进行聚类呢？

肯定不能用所有的指标，指标太多的话，聚类效果会非常差，而且计算时间，3周还不知道够不够用。。。

人工筛选指标

怎么办？靠人工筛选？

各位在手头的mysql实例上，执行一下show global status，然后从其中抽取4个指标，要求是，只需要看这4个指标，就能够完全了解线上所有mysql实例的性能情况。

然，这怎么选呀，比如选了Innodb_os_log_written，那Innodb_log_waits呢？光知道redo log写了多少，不知道redo log是否出现了等待，怎么敢说了解了性能呢？

这个也想选，那个也想选，选了几十个指标，还不如不选。。。

这对于有选择困难症的人，简直太痛苦了。

降维算法

那用降维算法？

其实降维算法主要是针对分类的，就是说，必须先给数据打好标记，才能进行降维。

而我想做的，就是先降维，再聚类，再打标记。这是个先有鸡还是先有蛋的问题。。。

有没有不用标记的降维算法?有，PCA主成分分析。

但PCA降维有个问题，你不知道它过滤掉了哪些指标。

-比如你把CPU，内存，IO，网络，这4维的指标数据送给PCA降到2维，PCA会吐给你2个维度的数据，但你并不知道这2维的数据代表啥含义。。。

自己动手，丰衣足食

只能自己想办法降维了。

其实把每个指标按照时间做成线图，就会发现，很多指标的趋势是非常相似的。

如下图：

把这些具有相同趋势的指标归成几大类，然后选择其中具有代表性的指标，就可以了。

指标归类

那怎么归类？人工去归类？这都21世纪了，不要动不动就人工的。。。

指标的趋势相似，就说明相关度很高呀，算一下相关系数就可以了。

但不能只算某个实例的某个时间段，不能一叶障目，要采样所有实例的多个时间段。

具体步骤：

-首先获得所有实例多个时间段采样的性能指标数据。
-然后计算相关系数矩阵。
-将相关系数数值很高的划成一类：

比如Bytes_received，Queries， Questions，Table_locks_immediate，Handler_commit等相关度高的指标，在大部分实例和时间段采样中，就能归成一类。

-归类好了之后，再进行类别频繁度计算，计算支持度和置信度。
-对于频繁的分类，在其中选择一个代表性的指标。

7.方案的实现

获得性能指标数据

要获得所有的性能指标，这个虽然麻烦，但是简单，从zabbix，prometheus，运维平台接口，直连库等，都能获得。写个程序定期抓取和存储就可以了。

等都弄完了之后，要把上面的说法要改一下，这个虽然简单，但是麻烦。。。

相关系数矩阵

然后计算相关系数矩阵，python的numpy已经实现好了算法函数。

结果如下图：

上图只展示了20个指标的相关系数矩阵。如果要展示所有的，我担心密集恐惧症的人会受不了。。。

频繁度计算

将强相关的指标归类，然后进行频繁度计算。

频繁项集算法，首先就是大名鼎鼎的Apriori算法。但是这个算法有个劣势，就是慢。。。优化过后还是慢。。。

后来慢的受不了了，就换成了FP-growth算法。效率大增，感觉有希望能在20天内完成目标了（狗头保命）。

频繁度算完之后，就找到了合适的指标，可以开始聚类啦。

五维图

聚类的算法有非常多种，基于划分，层次，密度，网格，模型等，比如常用的有k-means，DBSCAN， GMM等。

Python的sklearn类库，包含了大量的聚类方法。

下图是个五维图，展示了五个指标的聚类结果：

这里解释下如何在三维图里展示五维数据，首先x,y,z能展示3个维度，再加上大小和颜色，就能够展示5个维度了。

8.扩展

上面的做法是对所有实例，采样少量几个时间段进行的总体相关性和频繁度计算。

后续还可以进行更多的扩展：

特征扩展

-针对某个实例，长时间采样，进行大量时间段的计算，这样就能获得该实例的特征。
-针对某个特殊事件的时间段（比如性能高峰时间段，备份时间段）进行采样，对所有实例进行计算，这样就能得到该特殊事件的特征。

分类扩展

有了聚类数据之后，就能够挑选出合适的类别打标记。

有了标记，就能够使用机器学习中的分类，自动识别符合特征的数据库实例（比如性能压力较大的特征）。

具体做法：

-实时获得所有实例的性能指标数据
-使用分类，自动识别出符合特征的数据库实例

磁盘容量预测

先介绍简单的磁盘容量预测，根据历史数据，如何预测磁盘未来的增长情况呢？

采用时间序列分析的方法：

-将历史数据按时间排序成一维时间序列
-将时间序列分解成周期数据，趋势数据和白噪声数据
-对趋势数据进行指数平滑或者ARIMA预测
-将预测出来的数据加上周期数据，形成预测数据

性能（特征）预测

参考磁盘容量预测的方法，进行性能（特征）预测：

-对历史指标数据进行时间序列分析，得到预测数据
-对预测数据进行分类，得到未来可能产生性能（特征）问题的实例

全文完。

数据库

文章转载自yangyidba，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

智能运维之数据库容量评估

评论