谈数据库容量和性能测算

标签: 随笔文章 | 发表时间:2012-08-14 16:31 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi
原来我们谈到过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

内存容量需求分析:首先根据数据库容量算出所需的数据库缓存大小,再估计出操作系统、系统软件等所需内存,合计即是所需的内存容量。


  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [数据库 容量 性能] 推荐:

谈数据库容量和性能测算

- - 人月神话的BLOG
原来我们谈到过IT系统建设的业务模型TPMC估算,这里主要针对数据库服务器谈数据库容量和性能估算,该篇文章内容部分来自IBM网站一篇数据库容量性能规划的文章,地址现状不详. 总体来说数据库容量核心分析对象还是数据库表,配合数据库表的包括了视图,索引,日志等相关附属信息. 这些信息汇总后考虑3-5年的数据库容量增长情况给出数据库最终容量估算情况.

DB2数据库性能优化介绍

- - CSDN博客数据库推荐文章
作者:chszs,转载需注明. 博客主页: http://blog.csdn.net/chszs. 前段时间,我从CSDN得到了这本书《DB2数据库性能调整和优化(第2版)》,这是一本介绍DB2数据库性能调优的书籍,此书覆盖了DB2数据库性能调优所需的全部知识和工具,而且还提供了大量的性能调优的实际案例,颇有一种“一书在手,DB2尽在掌握”的豪情.

浅谈MySQL 数据库性能优化

- - BlogJava-qileilove
数据库是 IO 密集型的程序,和其他数据库一样,主要功能就是数据的持久化以及数据的管理. 本文侧重通过优化MySQL 数据库缓存参数如查询缓存,表缓存,. 日志缓存,索引缓存,innodb缓存,插入缓存,以及连接参数等方式来对MySQL数据库进行优化.   这里先引用一句话,从内存中读取一个数据的时间消耗是微秒级别,而从普通硬盘上读取一个数据是在毫秒级别,二者相差3个数量级.

数据库连接池性能比对

- - 企业架构 - ITeye博客
对现有的数据库连接池做调研对比,综合性能,可靠性,稳定性,扩展性等因素选出推荐出最优的数据库连接池 . NOTE: 本文所有测试均是mysql库.    1:性能方面 hikariCP>druid>tomcat-jdbc>dbcp>c3p0. hikariCP的高性能得益于最大限度的避免锁竞争.    2:druid功能最为全面,sql拦截等功能,统计数据较为全面,具有良好的扩展性.

基于SSD的数据库性能优化

- Sungelina - Hello DBA
NOR和NAND都是闪存技术的一种,NOR是Intel公司开发的,它有点类似于内存,允许通过地址直接访问任何一个内存单元,缺点是:密度低(容量小),写入和擦除的速度很慢. NAND是东芝公司开发的,它密度高(容量大),写入和擦除的速度都很快,但是必须通过特定的IO接口经过地址转换之后才可以访问,有些类似于磁盘.

MySQL 数据库性能优化之表结构

- tangfl - Sky.Jian 朝阳的天空
接着上一篇 MySQL 数据库性能优化之缓存参数优化 ,这是 MySQL数据库性能优化专题 系列的第二篇文章:MySQL 数据库性能优化之表结构. 很多人都将 数据库设计范式 作为数据库表结构设计“圣经”,认为只要按照这个范式需求设计,就能让设计出来的表结构足够优化,既能保证性能优异同时还能满足扩展性要求.

MySQL 数据库性能优化之缓存参数优化

- flychen50 - Sky.Jian 朝阳的天空
在平时被问及最多的问题就是关于 MySQL 数据库性能优化方面的问题,所以最近打算写一个MySQL数据库性能优化方面的系列文章,希望对初中级 MySQL DBA 以及其他对 MySQL 性能优化感兴趣的朋友们有所帮助. 这是 MySQL数据库性能优化专题 系列的第一篇文章:MySQL 数据库性能优化之缓存参数优化.

MySQL数据库性能优化之存储引擎选择

- - Sky.Jian 朝阳的天空
MySQL 数据库性能优化之SQL优化,这是  MySQL数据库性能优化专题 系列的第五篇文章:. MySQL数据库性能优化之存储引擎选择. 离上一篇文章已经有很长时间没有更新这个MySQL数据库性能优化专题了,时间太紧加上人之惰性,今天这里将之前就规划好的关于存储引擎选择方面的内容更新出来,希望对大家有所帮助吧.

高性能key-value数据库nessDB介绍

- - NoSQLFan
nessDB是一个小巧、高性能、可嵌入式的key/value存储引擎,使用标准C开发,支持Linux, *BSD, OS X and Solaris等系统,无第三方库依赖. 本文来自nessDB作者@ BohuTANG 的投稿分享,推荐给大家. 同时nessDB还提供一个服务端,支持Redis的 PING, SET, MSET, GET, MGET, DEL, EXISTS, INFO, SHUTDOWN 命令,您可以使用任何一款Redis客户端来连接和操作nessDB.

MySQL数据库性能优化之硬件瓶颈分析

- - Sky.Jian 朝阳的天空
接着上一篇 MySQL数据库性能优化之存储引擎选择,这是 MySQL数据库性能优化专题 系列的第六篇文章: MySQL数据库性能优化之硬件优化. 在过往与很多人的交流过程中发现,在谈到基于硬件来进行数据库性能瓶颈分析的时候,常被大家误解为简单的使用更为强劲的主机或者存储来替换现有的设备. 个人觉得这其中可能存在一个非常大的误区.