谈数据库容量和性能测算
原来我们谈到过IT系统建设的业务模型TPMC估算，这里主要针对数据库服务器谈数据库容量和性能估算，该篇文章内容部分来自IBM网站一篇数据库容量性能规划的文章，地址现状不详。
数据库容量估算
总体来说数据库容量核心分析对象还是数据库表，配合数据库表的包括了视图，索引，日志等相关附属信息。这些信息汇总后考虑3-5年的数据库容量增长情况给出数据库最终容量估算情况。
分析数据库表容量前，首先还是得分析单表单行的数据库容量，而要分析这个又必须清楚各种数据库和各种数据类型占用的字节情况。拿oracle数据库来说：
char类型是多少字节就多少字节，而varchar类型可变长可以按2/3长度折算。number类型可变长度最多占用22字节，平均按10字节估算足够。date类型占用7字节。
在粗略估计一张表每条记录占用多少空间时，可以参考上述的规则，查询数据字典也是一种途径。
SELECT * FROM USER_TAB_COLUMNS WHERE TABLE_NAME='';
在查询结果中，有一列叫DATA_LENGTH，记录了占用最大字节数。下面为单表占物理空间参考
select sum(bytes) from dba_segments where segment_name=‘PERSON’
有了以上假设，可以看到如果有一个客户表30个字段，全部是varchar(100)，那么就是一条客户记录2k,如果客户信息为10万条数据，即单表195M数据。考虑3年每年30%的客户数量增长，则需要的总容量为195*1.3*1.3*1.3=428M
进一步参考： http://topic.csdn.net/t/20031204/21/2528768.html，该文给出了索引大小的具体估算方法。根据经验值，索引数据容量至少为表容量的1/3，个人建议至少按1/2来估计索引的容量值，保证后续有增加索引足够的冗余。
由于ORACLE数据类型的多样，数据模型的复杂，空间估算也代表了相当大的工作量。 通常的空间估算包括了对TABLE，INDEX，CLUSTER，ROLLBACK SEGMENT，TEMPORARY SEGMENT以及REDO LOG方面等的计算。其余暂时不做分析和学习。
数据库容量估算例子-IBM参考案例
XYZ总行网上银行系统的数据库由CIF信息，交易日志、交易流水三部分组成。
其中：CIF信息包括企业客户和个人客户信息，企业客户信息平均大小为20K左右，个人客户信息平均大小为5K左右；每一笔交易都要记交易日志，日志的平均大小为4K左右；每一笔转帐交易都要记交易流水，交易流水的大小为2K左右。
这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算；个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4
次交易；那么，每天的交易量就是：
所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少，可以忽略不计；假定企业客户的转帐交易占总交易量的70%。我们就可以计算网上银行对存储系统容量的要求：
CIF信息容量=20K×（34万×50%）+5K×（34万×50%）=3.25GB+421MB ≈4GB
交易日志容量=[34万×50%×1.5+34万×50%×(4÷30)] ×4K×30×3 =277667×4K×30×3 ≈95GB
交易流水容量=（34万×50%×1.5）×70%×2K×30×3 ≈30GB
XYZ网上银行总体数据容量要求：=4GB+95GB+30GB=129GB
高法诉讼费数据量分析：
高法的交易数据按要求要保留三年，每笔交易记录的大小为512字节，总体容量为：（25000×20%+15000×30%+7000×50%）×37×12×3×0.5K≈8.2GB
因此，数据库的总数据量为： 129GB+8.2GB=137.2GB
数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为：6.86GB。
从而计算出系统内存需求为：
1. AIX操作系统所占的内存 128MB
2. 数据库管理系统所占的内存 256MB
3. 双机热备等系统软件所占的内存128MB
4. 应用程序所占的内存 256MB
5. 数据库缓存 6.86GB
6. 合理的内存利用率 75%
总计 10GB
存储容量需求分析
除了上述的XYZ网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。
异步查询下载服务每隔1小时生成一个下载数据包，每个数据包的大小为3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2年，其它数据包只要保存3个月。因此，存储容量为：
23×3M×30×3＋1×3M×365*2=6GB+2GB=8GB
为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为：(137.2GB+8GB)÷40% ×2= 766GB
数据库性能估算--参考IBM资料
对于传统的TPMC业务模型测算可以看到的是该测算模型既包括了应用服务器也包括了数据库服务器，那么两者之间应该是如何去分配比例？这是一个问题。其次该文可以看到的是可以单独去估算数据库的TPM和TPC值。则首先要搞清楚的是一笔交易本身涉及到多少次数据库事务操作，每笔交易的复杂度是多少？最难的点还是在这里。这里又是一个经验数据。
其次估算考虑两个问题，一个是数据库CPU利用率应该在70%左右为最好，太低了硬件估算过于偏大做无必要投入，太大了CPU负荷太高影响系统高可靠性。第二个问题仍然是3-5年的硬件的可扩展性，3-5年业务并发的增长量情况究竟如何。
最后我们估算的时候一定是要考虑峰值的时候的场景，找到业务交易峰值的天和峰值的时段数据。
TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM值（Transaction Per Minute，即每分钟处理的交易比数）。
TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合；而且参加TPC测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。
以下计算公式是IBM公司在金融综合业务系统的实际应用中总结的经验方法论，基本反映了金融业务特点对主机处理能力的需求：
TPM=TASK x 80% x S x F / (T x C)
其中：
TASK：为每日业务统计峰值交易量
T：为每日峰值交易时间，假设每日80%交易量集中在每天的4小时，即240分钟内完成：T=240。
S：为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的金融业务交易的复杂程度与TPC-C标准测试中的交易存在较大的差异，须设定一个合理的对应值。以普通储蓄业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多；根据科学的统计结果，每笔交易操作相比较于TPC标准测试中的每笔交易的复杂度此值可设定为10~20。
C：为主机CPU处理余量。实际应用经验表明，一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。因此，在推算主机性能指标时，必须考虑CPU的冗余，设定C=75%。
F：为系统未来3~5年的业务量发展冗余预留。
综上所述，为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。
数据库性能估算案例--参考IBM资料
下面针对XYZ行的网上银行业务的需求，我们进行数据库服务器的选型分析。
由于目前XYZ行只有17个分行开通了网上银行业务，据我们估计，按照目前的客户数量，全部分行都开通网上银行业务后，总的客户数量可以达到10万。考虑INTERNET在我国的迅猛发展，客户数量的年增长率按照50%计算，那么，3年后的客户数量将达到10万×（1+50%）3≈34万。这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算；个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易；
那么，每天的交易量就是：34万×50%×1.5+34万×50%×(4÷30) ≈28万笔
假设网上银行的交易复杂度达到15，那么，每天的数据库操作数达到：28万×15=420万次
高法诉讼费缴费：
由于诉讼费的增长量不大，我们按年递增率5%计算。根据XYZ总行的统计，全国共37家分行，缴费量比较大的分行可以达到25000笔每月，占分行总数的20%；缴费量中等的省可达到15000笔每月，占分行总数的30%；缴费量小的省可达到7000笔每月，占分行总数的50%；按一个月20个工作日计算。
这样，三年后每天的交易数量可以达到：（25000×20%+15000×30%+7000×50%）×37÷20×（1+5%）3≈28740笔。我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到：28740*13=373620次
总的数据库操作次数是：4200000+373620=4573620
假设每天的交易的80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为：4573620×80%÷（4×60）≈15250
要为将来陆续加入的应用预留40%的处理能力；另外，考虑到CPU的繁忙时间低于70%时，系统的性能较好，我们把这个比例定在65%。所以系统的TPC-C值应达到：15250÷（1－40%）÷65%≈39000
内存容量需求分析：首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。
青春就应该这样绽放 游戏测试：三国时期谁是你最好的兄弟！！ 你不得不信的星座秘密
数据库容量估算
总体来说数据库容量核心分析对象还是数据库表，配合数据库表的包括了视图，索引，日志等相关附属信息。这些信息汇总后考虑3-5年的数据库容量增长情况给出数据库最终容量估算情况。
分析数据库表容量前，首先还是得分析单表单行的数据库容量，而要分析这个又必须清楚各种数据库和各种数据类型占用的字节情况。拿oracle数据库来说：
char类型是多少字节就多少字节，而varchar类型可变长可以按2/3长度折算。number类型可变长度最多占用22字节，平均按10字节估算足够。date类型占用7字节。
在粗略估计一张表每条记录占用多少空间时，可以参考上述的规则，查询数据字典也是一种途径。
SELECT * FROM USER_TAB_COLUMNS WHERE TABLE_NAME='';
在查询结果中，有一列叫DATA_LENGTH，记录了占用最大字节数。下面为单表占物理空间参考
select sum(bytes) from dba_segments where segment_name=‘PERSON’
有了以上假设，可以看到如果有一个客户表30个字段，全部是varchar(100)，那么就是一条客户记录2k,如果客户信息为10万条数据，即单表195M数据。考虑3年每年30%的客户数量增长，则需要的总容量为195*1.3*1.3*1.3=428M
进一步参考： http://topic.csdn.net/t/20031204/21/2528768.html，该文给出了索引大小的具体估算方法。根据经验值，索引数据容量至少为表容量的1/3，个人建议至少按1/2来估计索引的容量值，保证后续有增加索引足够的冗余。
由于ORACLE数据类型的多样，数据模型的复杂，空间估算也代表了相当大的工作量。 通常的空间估算包括了对TABLE，INDEX，CLUSTER，ROLLBACK SEGMENT，TEMPORARY SEGMENT以及REDO LOG方面等的计算。其余暂时不做分析和学习。
数据库容量估算例子-IBM参考案例
XYZ总行网上银行系统的数据库由CIF信息，交易日志、交易流水三部分组成。
其中：CIF信息包括企业客户和个人客户信息，企业客户信息平均大小为20K左右，个人客户信息平均大小为5K左右；每一笔交易都要记交易日志，日志的平均大小为4K左右；每一笔转帐交易都要记交易流水，交易流水的大小为2K左右。
这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算；个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4
次交易；那么，每天的交易量就是：
所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少，可以忽略不计；假定企业客户的转帐交易占总交易量的70%。我们就可以计算网上银行对存储系统容量的要求：
CIF信息容量=20K×（34万×50%）+5K×（34万×50%）=3.25GB+421MB ≈4GB
交易日志容量=[34万×50%×1.5+34万×50%×(4÷30)] ×4K×30×3 =277667×4K×30×3 ≈95GB
交易流水容量=（34万×50%×1.5）×70%×2K×30×3 ≈30GB
XYZ网上银行总体数据容量要求：=4GB+95GB+30GB=129GB
高法诉讼费数据量分析：
高法的交易数据按要求要保留三年，每笔交易记录的大小为512字节，总体容量为：（25000×20%+15000×30%+7000×50%）×37×12×3×0.5K≈8.2GB
因此，数据库的总数据量为： 129GB+8.2GB=137.2GB
数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为：6.86GB。
从而计算出系统内存需求为：
1. AIX操作系统所占的内存 128MB
2. 数据库管理系统所占的内存 256MB
3. 双机热备等系统软件所占的内存128MB
4. 应用程序所占的内存 256MB
5. 数据库缓存 6.86GB
6. 合理的内存利用率 75%
总计 10GB
存储容量需求分析
除了上述的XYZ网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。
异步查询下载服务每隔1小时生成一个下载数据包，每个数据包的大小为3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2年，其它数据包只要保存3个月。因此，存储容量为：
23×3M×30×3＋1×3M×365*2=6GB+2GB=8GB
为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为：(137.2GB+8GB)÷40% ×2= 766GB
数据库性能估算--参考IBM资料
对于传统的TPMC业务模型测算可以看到的是该测算模型既包括了应用服务器也包括了数据库服务器，那么两者之间应该是如何去分配比例？这是一个问题。其次该文可以看到的是可以单独去估算数据库的TPM和TPC值。则首先要搞清楚的是一笔交易本身涉及到多少次数据库事务操作，每笔交易的复杂度是多少？最难的点还是在这里。这里又是一个经验数据。
其次估算考虑两个问题，一个是数据库CPU利用率应该在70%左右为最好，太低了硬件估算过于偏大做无必要投入，太大了CPU负荷太高影响系统高可靠性。第二个问题仍然是3-5年的硬件的可扩展性，3-5年业务并发的增长量情况究竟如何。
最后我们估算的时候一定是要考虑峰值的时候的场景，找到业务交易峰值的天和峰值的时段数据。
TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM值（Transaction Per Minute，即每分钟处理的交易比数）。
TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合；而且参加TPC测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。
以下计算公式是IBM公司在金融综合业务系统的实际应用中总结的经验方法论，基本反映了金融业务特点对主机处理能力的需求：
TPM=TASK x 80% x S x F / (T x C)
其中：
TASK：为每日业务统计峰值交易量
T：为每日峰值交易时间，假设每日80%交易量集中在每天的4小时，即240分钟内完成：T=240。
S：为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的金融业务交易的复杂程度与TPC-C标准测试中的交易存在较大的差异，须设定一个合理的对应值。以普通储蓄业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多；根据科学的统计结果，每笔交易操作相比较于TPC标准测试中的每笔交易的复杂度此值可设定为10~20。
C：为主机CPU处理余量。实际应用经验表明，一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。因此，在推算主机性能指标时，必须考虑CPU的冗余，设定C=75%。
F：为系统未来3~5年的业务量发展冗余预留。
综上所述，为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。
数据库性能估算案例--参考IBM资料
下面针对XYZ行的网上银行业务的需求，我们进行数据库服务器的选型分析。
由于目前XYZ行只有17个分行开通了网上银行业务，据我们估计，按照目前的客户数量，全部分行都开通网上银行业务后，总的客户数量可以达到10万。考虑INTERNET在我国的迅猛发展，客户数量的年增长率按照50%计算，那么，3年后的客户数量将达到10万×（1+50%）3≈34万。这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5笔交易计算；个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4次交易；
那么，每天的交易量就是：34万×50%×1.5+34万×50%×(4÷30) ≈28万笔
假设网上银行的交易复杂度达到15，那么，每天的数据库操作数达到：28万×15=420万次
高法诉讼费缴费：
由于诉讼费的增长量不大，我们按年递增率5%计算。根据XYZ总行的统计，全国共37家分行，缴费量比较大的分行可以达到25000笔每月，占分行总数的20%；缴费量中等的省可达到15000笔每月，占分行总数的30%；缴费量小的省可达到7000笔每月，占分行总数的50%；按一个月20个工作日计算。
这样，三年后每天的交易数量可以达到：（25000×20%+15000×30%+7000×50%）×37÷20×（1+5%）3≈28740笔。我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到：28740*13=373620次
总的数据库操作次数是：4200000+373620=4573620
假设每天的交易的80%集中在4小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为：4573620×80%÷（4×60）≈15250
要为将来陆续加入的应用预留40%的处理能力；另外，考虑到CPU的繁忙时间低于70%时，系统的性能较好，我们把这个比例定在65%。所以系统的TPC-C值应达到：15250÷（1－40%）÷65%≈39000
内存容量需求分析：首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。
青春就应该这样绽放 游戏测试：三国时期谁是你最好的兄弟！！ 你不得不信的星座秘密