网易MySQL数据库工程师微专业学习笔记（七）

一、性能容量评估

对于一个系统的性能容量评估，第一步需要对具体的业务场景进行分析，然后根据对业务的分析评估出数据库服务器所需要的性能指标，最后根据这些性能指标来确定实际需要的服务器的配置。此外，根据评估出的性能指标可以了解到这个系统对于服务器的哪些硬件有特殊的需求和依赖，从而可以预测出后期会导致数据库性能瓶颈的服务器资源并且梳理出一个服务器硬件扩容来优化数据库性能的大体脉络。

数据库服务器的硬件性能指标和普通的PC机的硬件指标基本上是一致的，主要有五个方面，分别是磁盘IO性能、内存容量、CPU、网络吞吐量和磁盘容量。其中CPU一般关注的是CPU支持的最大线程数，每秒计算数不是非常关心，此外内存一般关注的是内存的容量，而内存的刷新频率则不是非常关系，这两点和普通的PC不太一样。

在分析业务场景时主要需要分析以下几点。

1. OLTP和OLAP

OLTP的全称是On-Line Transaction Processing（联机事务处理），是指面向广大用户，并发高，事务操作较短的系统。目前互联网上的大部分应用都属于OLTP。OLTP类型的系统主要看重服务器的CPU并发性能和内存。如果系统的写操作比较多或者服务器内存不够的话还会依赖磁盘的IO速度。

OLAP的全称是On-Line Analytical Processing（联机分析处理），一般是面向内部人员，执行大规模复杂查询。OLAP类型的系统一般看重磁盘的IO性能，在做一些排序操作时如果内存足够大那么能提高数据的排序速度。

在分析业务时首先要分析当前的项目时OLTP类型的还是OLAP类型的，当然有些项目中可能两个类型同时存在，例如大型电商系统，其中用户访问的时OLTP，而后台的业务分析人员用的时OLAP，那么可能就需要使用分布式数据库了，当然一般小项目是不需要的，因为数据量一般不会非常大。

2. 并发请求数

并发请求数是一个用来衡量线上业务繁忙程度的指标，具体而言就是业务高峰时数据库的每秒并发访问数。因为性能容量评估是在项目上线前进行的，因此只能对并发请求数进行预估。预估的方法一般有两个，第一，根据上线后的web服务器数量以及连接池的配置来判断，例如有10个web服务器，每个服务器的连接池大小是100，那么并发的峰值就是1000；第二，和业务分析人员讨论分析一下该项目初上线的用户规模和用户增长速度，然后结合具体的业务特点预测一下并发请求数，例如一个卖彩票的网站，每天成交量是500万，那么可以估计出系统每天的订单数在100万以上，这样可以知道这是一个高并发的网站。而如果有一个电器网站，每天的成交量也是500万，那么可能这个系统每天的订单数就是1000多，因为家电都比较贵，因此这个网站的并发数并不高。

并发请求数主要依赖的服务器资源是CPU，如果CPU支持的并发数不高，那么就无法支持高并发的项目。

3. 读写比例

读写比例就是线上项目中select操作和update/delete/insert操作的比例，该指标是用于描述项目将如何使用数据库的一个指标。读写比例的分析还是需要结合业务的实际场景来分析，如果是读多的场景则对数据库服务器的内存要求比较高，而如果是写多的场景则对数据库服务器的磁盘IO的要求比较高。此外对于insert操作还要分析一下，insert操作是由一般用户小批量的不停的插入的，还是由管理人员大批量的一次性的导入的，这个也会对硬件产生不同的要求。

4. 数据总量

这个很好理解，因为我们服务器当前的磁盘空间总是有一个上限值的，不可能无限制的扩张。所以我们需要尽可能的准确的预估数据总量。预估的方法还是分析业务需求，首先了解每天会有多少的写入操作，每个操作写入多少行数据，每行数据多大，这样就可以指导每天数据的增长量，然后在乘上硬件更新周期就可以预告出数据总量，这些都需要和应用开发和业务人员进行沟通来获取。此外服务器配置时的磁盘空间不能正好和预估量相等，需要有余量，例如预估的数据总量是500GB，那么服务器最好准备1TB的磁盘空间，因为数据的增长可能大于我们的预估，此外线上的一些服务器运维操作也会产生一些磁盘空间的消耗。

5. 冷数据和热数据

热数据是指线上一定周期内将被反复访问的数据，冷数据是指线上保存这的最近不会被用户访问到的数据。举个例子，像京东和淘宝的我的订单中默认都只显示三个月内的订单，如果要看其他的订单需要选择特定的连接，而且一般是一年份来区分的，如查看2016年的订单。之所以这样做就是因为用户的订单数量太大，一个服务器上是放不下的，并且统一查询时间开销很大，而且用户往往只会关心最近的订单，而很久以前的订单用户很少会去查看。因此他们将三个月内的订单作为热数据保存在线上的主库中，而其他的则根据年份放在指定的从库当中。之所以要估算热数据，原因是我们要尽量将热数据中的数据都放入内存中，这样才能最大程度的加速我们的系统。热数据的估算方法还是要结合业务情况，分析线上活跃用户量，以及每个活跃用户产生的数据量，然后相乘得出热数据量。例如，一个线上系统，日常活跃用户有1万人，这些人每个产生的相关数据的数据量大概是1MB，那么热数据量就是10G左右，服务器的内存就要在10G至上，当然也要留有余量，因为操作系统、mysql服务都要占用内存的。

6. 线上数据分层存储

和冷热数据的原理相同，数据被访问的次数是可以分级的，而数据库服务器的数据查询数据也是分层的，内存中的数据查询最快，历史数据数据库中的数据的访问速度较慢，因此我们应该根据数据的访问频度将数据分层存储。将数据访问频度最高的热数据存储进内存，而还可能被访问的较早前的数据存储在线上数据库服务器中，最后基本不会被访问到的历史数据可以存入历史数据的专用数据库中。还是以订单信息为例，如果不进行分级存储，大型电商的那些大量的订单数据是很难存储在一台服务器的磁盘上的，所以需要根据订单的产生时间对数据进行分级存储，如下图所示。

进行分级存储时需要注意，只有数据访问的时效性强的数据比较适合进行数据分级存储，其他的数据不一定适用，因此在进行分级存储的时候还是需要结合具体业务进行分析。

7. 服务器资源选型

之前说过，数据库服务器选型的方法和普通的PC基本相同，主要就是CPU、内存、磁盘IO、磁盘容量，还有网络吞吐量，一般的可选方案如下图所示。

这里在磁盘IO中网易工程师说SAS的IO性能是高于SATA的，但是以我实际用下的感受是SAS速度高于SATA2.0，但是慢于SATA3.0

二、具体案例

课上网易的老师举了两个网易的实际项目中进行性能容量评估的案例，下面记录一下。

1. 网易云音乐曲库数据库服务器评估。

首先了解一下改数据库的业务情况。这个数据库是用于存储网易云音乐中的所有歌曲信息的数据库，歌曲信息包括歌曲名称、作者、歌曲长度等。但是要注意虽然老师没有说，但是歌曲的实际的音频文件应该是没有存储在改数据库中的，因为这种情况一般是采用cdn技术来实现的。此外改库中的数据是面向所有线上用户的。

根据上面的业务信息，首先可以确定这个系统是一个OLTP线上数据库。下面一个个的指标进行分析，第一个是并发数，按网易老师的说法他们当时和应用负责人都无法很好的估计项目上线后的用户总数，因此他们当时直接根据应用申请的服务器数量来预估并发数。当时的应用负责人一共申请了50台应用服务器，每台服务器的最大连接数是100，那么峰值时可能有5000qps，因此这是一个并发请求比较高的项目，对CPU的要求较高。第二部分析数据的读写比例，根据业务分析，这个项目中的普通的线上用户是是能查询改数据库中的歌曲信息的，而无法向数据库中添加新的歌曲信息。歌曲信息的添加是又后台管理员进行批量添加的。因此改系统主要都是读取操作，写入操作是非常少的，因此网易数据库工程师预估了一个差距非常大的读写比例，100：1。第三步预估数据总量，这个非常好估算，只要对部分歌曲进行一下采样，预估一下每个歌曲信息的平均大小，这里预估下来是8K，而歌曲总数为5000万，那么磁盘需求就是400G左右。而数据的增长趋势上来看，歌曲创作是比较慢的，因此数据的增长肯定也是慢的。第四步分析冷热数据，这个需要进行一下线上调研。根据网易的调研结果，在5000万的歌曲中只有40%的歌曲可能被访问，而只有10%的歌曲可能被经常的访问。因此热数据只有40G。第五步分析是否可以进行数据的分级存储，这里因为用户没有数据的产生，而歌曲信息是无法分级存储再历史库中的，因为哪怕是用户可能永远不会访问的歌曲他的访问方法也应该是和热门歌曲相同的，所以不能将冷门歌曲存储在历史数据的数据库中。至此就可以分析出该项目对于服务器的性能要求了。该项目对于内存的要求一般，需要40G以上的内存（存储热门歌曲需要）；磁盘空间需求一般，需要大于400G的磁盘空间（根据数据总量估算出）；磁盘IO需求一般（因为写操作不多，热门数据的读取只经过内存）；网络流量的要求也是一般的，因为根据并发量，假设每秒钟有2500首歌曲信息被返回，每个歌曲信息的数据大小为8K，则每秒的网络流量大概为20000K即20MB/s。对于CPU的要求很高（因为上面分析的并发有5000qps）。最后根据上面的分析网易的数据库工程师给出了如下图所示的服务器配置。

2. 网易理财销售数据库服务器评估

首先还是分析一下业务背景， 网易理财销售主要就是记录用户在平台上购买的理财产品的订单数据，和一般的电商是类似的。因此可以确定这个系统也是一个OLTP的系统。然后继续一步步的分析，首先分析并发情况。该业务平时的数据并发量不大，因为普通的网上理财产品的利率往往也不是很高，所有不会有很多人买。但是当有一些限量的秒杀的高利率产品推出时往往会在瞬间产生大量的订单。为了保证系统的正常运行和用户体验服务器的硬件配置需要能够满足秒杀时的并发量。然后网易的工程师根据以往的一个产品对并发量进行了预估，之前有一个秒杀产品，限量30000份，上线后十几秒内被买完，就以15秒被秒杀完来算，那么平均就是每秒卖出2000份，也就是说并发的峰值大概是2000tps，所以并发量是很高的，因此对CPU的要求比较高。然后分析读写比例，同样是分析秒杀情况下的读写比例，可以看出秒杀时有大量的订单产生，也就是有大量的写操作，因此对服务器的IO要求特别高。此外因为秒杀时的访问量特别大，所以对于网络的吞吐量邀请也很高。接下来分析数据总量，这个可以根据年成交量来估算，业务人员估计年成交量在百万元级别，但是因为理财产品本身单价就很高，因此虽然年成交量挺大的，但是数据总量不大。最终网易的数据库工程师分析数据量在200G左右。在下一步分析冷热数据，热数据主要是在秒杀期间新产生的数据，最好能让新产生的数据都保存在数据库的脏数据页中，这样比每次都刷新到磁盘要快的多（注意即便所有新数据都可以存在内存中，也不代表写数据的性能和磁盘IO无关，因为为了保证事务的持久性数据库需要在磁盘上写redo日志等信息，这些信息的写入速度是依赖于磁盘IO的）。最后分析是否可以分级存储，这里产生的理财产品的订单显然和普通的产品订单一样是随着时间而访问可能性递减的，因此将半年的订单存在线上数据库中，而其他的存在历史数据库中。最后根据上面的分析网易的数据库工程师给出了如下图所示的服务器配置。

三、性能测试

项目上线前一般都要做性能测试，其原因有四点，第一，开发人员对线上产品往往缺乏心理预估，不清楚当前服务器能支撑的负载、吞吐等；第二，有时候需要用性能测试来模拟线上的实际情况来重现异常；第三，帮助规划未来业务增长（这个是为什么我也不清楚，知道的朋友麻烦留意告诉我，感谢！）；第四，可以测试在不同软硬件配置下服务器的运行情况。

性能测试有三类，第一类是设备层测试，设备层测试就是用一些程序不停的向磁盘写数据，来查看磁盘的性能、坏块率、CPU并发性、服务器寿命等；第二类是业务层测试，就是由专门的测试人员对每个功能模块进行测试，查看是否满足之前定义的业务需求；第三，数据库测试，测试数据库在服务器上的运行情况。对于数据库工程师最后一个数据库测试是需要关心的，而另外两个一般与数据库工程师无关。

对于mysql的数据库测试而已主要目的有三个。第一，测试不同的mysql分支版本间的性能差异，例如官方mysql和mariaDB等不同的mysql分支版本间对于不同的服务器不同的业务性能上是会有差异的；第二，测试不同mysql版本间的差异，即使是相同的mysql分支版本，但是还是有着不同的版本，例如官方的mysql就有5.5、5.6、5.7、8.0等众多的版本，因此要对不同版本的mysql测试性能；第三，测试不同mysql参数配置下的性能，这个是最复杂也是最重要的一个测试，因为mysql中有大量的可配置参数，例如缓存大小、redo log页大小、数据刷新机制等，这些参数的设置会直接影响数据库的运行效率，因此需要通过测试找到一个比较合理的参数设置。

mysql的测试主要分为两类，第一类是CPU测试，这类测试中数据量一般不大，因为只有当数据都在内存中时才能测试出CPU性能的上限；第二类是IO测试，这类是最主要的测试，因为数据库的速度往往是由IO速度决定的，这里就需要大量的数据，让IO上限能够被测试出来。此外，无论时IO测试还是CPU测试，在测试中都有四种测试方法，分别时写入测试、更新测试、纯度测试和混合测试，分别代表测试时只写入数据、只更新数据、只读取数据和三种操作都有的混合操作（可能操作数量的比例会不同）。

对于mysql的性能测试常用的工具一般有三个，sysbench、tpcc-mysql、mysqlslap，mysqlslap虽然是mysql官方推出的测试工具，但是在业内一般比较常用的是前两者。而在测试中需要关注一下几个测试出的数据指标。

1. 服务吞吐量（TPS、QPS）

TPS值得是每秒钟执行的事务总量，QPS指的是每秒钟执行的请求量。例如，有一个事务，其中需要执行的请求数是10，服务器每秒钟执行的事务总量是100，那么服务器的吞吐量就是100TPS和1000QPS。

2. 服务响应时间

3. 服务并发性

关于sysbench和tpcc-mysql的安装和使用由于我再ubuntu下一直没有试验成功就暂时不写了，等我有时间试验成功了再在单独的博文中记录。