2022年数据库服务器的选型建议 .pdf

《2022年数据库服务器的选型建议 .pdf》由会员分享，可在线阅读，更多相关《2022年数据库服务器的选型建议 .pdf（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、如何规划和选择数据库服务器? 当一个新的业务系统开发完成后，需要在一个区域乃至全国推广此应用软件，如何根据业务规模来选择服务器配置、内外置磁盘大小、以及网络带宽，是一件复杂的事情。一个最真实的评估，是建立一个接近真实业务应用的操作环境，进行各种压力测试，测算出不同的用户数量下，系统的响应时间和吞吐量，并得出当时服务器的各种资源的利用率情况，对硬件资源的完整评估，需要考虑下列三个方面: 服务器性能的评估客户端工作站或前端桌面的评估通讯网卡和网络带宽的评估如果不能建立准确的压力测试环境，需要根据工业界的Benchmark 对服务器进行评估，推算出符合业务规模的服务器配置,同时要考虑在做系统管理时所

2、消耗的资源，如在做备份、恢复、问题诊断、性能分析时、软件维护时都会对资源带来附加的消耗，对重要资源要考虑为将来留下升级和可扩展的余地，下列是一些通用的原则: 处理器 :要考虑高峰时的处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。如果要保持快速的响应能力，应当为CPU 保留 20%至 40%的富余量。内存 :要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。磁盘 :评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备 (如磁带机 )。IO 槽:尽量保留更多的IO 槽，防止将来

3、插更多的PCI 卡。网络 :选择合适的网卡，保证网络不是系统的瓶颈。在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 1 页，共 10 页 - - - - - - - - - 因素等。理想情况下，应考虑下列要素: 交易的复杂性交易率数据读 /写比例并发连接数目并发交易数目数据库最大表的大小性能度量的目标根据各种Benchmark 测试结果和对各种生产系统的检测，下表概括了CPU、磁盘、内存页面、网络和虚存页交换的利

4、用率，可看出一个服务器如果其利用率保持在Good 所标示的范围内时，是一种理想的模式。基于 rPerf 的推算，评估数据库服务器的CPU rPerf(Relative performance) 是从 IBM 公司解析模型得出的商务处理性能估计值。该模型模拟部分系统的操作，如中央处理器、高速缓存和内存，该模型没有模拟磁盘和网络的输入 /输出操作。虽然采用了一般数据库和操作系统的参数，但该模型不能反映出具体的数据库或AIX 版本。除非单独说明，否则rPerf 均在系统推出时估计。IBM pSeries 640-B80 为基准参照系统，其值为本。虽然rPerf 可用于比较商业处理性能，但实际的系统性

5、能可能不同，取决于许多因素，包括系统硬件配置和软件设计与配置。基于 TPC-C 的推算，评估数据库服务器的CPU TPC-C 基准是事务处理委员会建立的一个专门演示在线事务处理性能(OLTP)的性能基准，它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能，这些事务进程于一个可控制的状态下在一个标准的数据库中运行。TPC-C 测试包括 5 个典型的OLTP 事务，它们是: 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 2 页，共 10 页 - - - - - - - - -

6、 新订单:一个用户提交一个新的订单支付:更新用户的账户余额以反映一个支付交付:订单的交付 (通过一个批事务处理实现) 订单状态 :返回用户最新订单的状态库存水平 :监控当前仓库库存TPC-C 的事务处理是在一个9 个表的数据库上实现的事务处理过程包括:更新、插入、删除、终止，以及对主和次级键的访问,每种事务处理90%的响应时间应小于或等于5 秒，其中，库存水平的响应时间可以在20 秒以内。TPC-C 的吞吐量值是终端活动水平的直接结果，如每一个仓库有10 个终端，在每一个终端上上述5 个事务都是可用的，一个远程的终端仿真器被用来在性能测试过程中进行必要的事务混合工作。这个混合代表着一个完整的订

7、单商务处理流程:录入、支付、检验、交付。更专业的是，这个必要的混合被定义为产生一个相等数量的新订单和支付事务，以及在每10 个新订单事务中产生一个交付事务，一个订单状态检验事务和一个库存水平检验事务远程终端仿真器也被用来测量每一个事务的响应时间，以及用来模拟键入时间及思考时间，键入时间是指在终端上录入数据所花费的时间，思考时间是指操作人员在终端读取事务的结果，进行下一个事务请求之前所花费的时间。每一个事物都有一个最小键入时间和最小思考时间。另外，这个响应时间必须在一个给定的极限值之下。TPC-C 基准测试的结果-TPC-C 的吞吐量 (tpmC) ，代表的是系统的最大的持续性能，它被定义为系统

8、每分钟可以处理多少个新订单事务，与此同时，系统还在处理其他四种事务类型 (支付、订单状态、交付、库存水平)。所有 5 个 TPC-C 事务都有某个限定的用户响应时间要求，其中新订单事务的响应时间是5 秒以内。因此如果一个系统的TPC-C 值是名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 3 页，共 10 页 - - - - - - - - - 100tpmC/min ，说明该系统在每分钟处理其他的混合的TPC-C 事务的工作的同时，可以产生 100 个新订单事务。如何使用TPC-C

9、 进行服务器的评估由上可知， TPC-C 测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM 值(Transaction Per Minute，即每分钟处理的交易比数)。TPC-C 虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合; 而且参加TPC 测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。以下计算公式是IBM 公司在金融综合业务系统的实际应用中总结的经验

10、方法论，基本反映了金融业务特点对主机处理能力的需求: 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 标准交易的复杂度，要复杂很多;根据科学的统计结

11、果，每笔交易操作相比较于TPC 标准测试中的每笔交易的复杂度此值可设定为名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 4 页，共 10 页 - - - - - - - - - 1020。C:为主机 CPU 处理余量。 实际应用经验表明，一台主机服务器的CPU 利用率高于80%则表明 CPU 的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。因此，在推算主机性能指标时，必须考虑CPU 的冗余，设定C=75%。F:为系统未来35 年的业务量发展冗余预留。综上所述，

12、为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。举例说明，使用TPC-C 进行数据库服务器评估下面针对XYZ 行的网上银行业务的需求，我们进行数据库服务器的选型分析。由于目前XYZ 行只有17 个分行开通了网上银行业务，据我们估计，按照目前的客户数量，全部分行都开通网上银行业务后，总的客户数量可以达到10 万。考虑 INTERNET 在我国的迅猛发展，客户数量的年增长率按照50%计算，那么，3 年后的客户数量将达到10 万(1+50%)3 34 万。这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天

13、做1.5 笔交易计算 ;个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，因此我们假定个人客户平均每个月做4 次交易 ; 那么，每天的交易量就是: 34 万 50% 1.5+34 万 50%(430) 28 万笔假设网上银行的交易复杂度达到15，那么，每天的数据库操作数达到: 28 万 15=420 万次高法诉讼费缴费: 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 5 页，共 10 页 - - - - - - - - - 由于诉讼费的增长量不大，我们按年递增率5%计算

14、。根据XYZ 总行的统计，全国共37 家分行，缴费量比较大的分行可以达到25000 笔每月，占分行总数的20%;缴费量中等的省可达到 15000 笔每月， 占分行总数的30%;缴费量小的省可达到7000 笔每月， 占分行总数的50%;按一个月20 个工作日计算。这样，三年后每天的交易数量可以达到: (2500020%+15000 30%+700050%)3720(1+5%)3 28740 笔我们假设高法诉讼缴费的交易复杂度达到13，那么每天的数据库操作达到: 28740*13=373620 次整体性能要求: 总的数据库操作次数是:4200000+373620=4573620 假设每天的交易的8

15、0%集中在 4 小时内发生，那么高峰交易时间内每分钟的数据库联机交易次数为 :4573620 80%(460)15250 要为将来陆续加入的应用预留40%的处理能力 ;另外，考虑到 CPU 的繁忙时间低于70% 时，系统的性能较好，我们把这个比例定在65%。所以系统的TPC-C 值应达到 :15250(1 -40%)65%39000 内存容量需求分析首先根据数据库容量算出所需的数据库缓存大小，再估计出操作系统、系统软件等所需内存，合计即是所需的内存容量。网银数据量分析: XYZ 总行网上银行系统的数据库由CIF 信息，交易日志、交易流水三部分组成。其中 :CIF 信息包括企业客户和个人客户信息

16、，企业客户信息平均大小为20K 左右，个人客户信息平均大小为5K 左右 ;每一笔交易都要记交易日志，日志的平均大小为4K 左右 ; 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 6 页，共 10 页 - - - - - - - - - 每一笔转帐交易都要记交易流水，交易流水的大小为2K 左右。这些客户当中，至少有一半是个人客户，另一半是企业客户。企业客户的交易频率比较高，我们按平均每个企业客户每天做1.5 笔交易计算 ;个人客户常用的交易是查询、取款、存款，并且每个月还要交电话费，

17、因此我们假定个人客户平均每个月做4 次交易 ; 那么，每天的交易量就是: 所有的交易日志和交易流水都要保留三个月。由于个人客户的转帐交易非常少，可以忽略不计 ;假定企业客户的转帐交易占总交易量的70%。我们就可以计算网上银行对存储系统容量的要求: CIF 信息容量 =20K(34 万 50%)+5K (34 万 50%)=3.25GB+421MB 4GB 交易日志容量=34 万 50%1.5+34 万 50% (430) 4K303 =2776674K 303 95GB 交易流水容量=(34 万 50%1.5) 70%2K303 30GB XYZ 网上银行总体数据容量要求:=4GB+95GB+

18、30GB=129GB 高法诉讼费数据量分析: 高法的交易数据按要求要保留三年，每笔交易记录的大小为512 字节，总体容量为: (2500020%+15000 30%+700050%)371230.5K8.2GB 因此，数据库的总数据量为: 129GB+8.2GB=137.2GB 数据库系统在缓存容量达到数据库总容量的5%时性能较好，因此，数据库缓存大小为:6.86GB。从而计算出系统内存需求为: 1. AIX 操作系统所占的内存128MB 2. 数据库管理系统所占的内存256MB 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - -

19、名师精心整理 - - - - - - - 第 7 页，共 10 页 - - - - - - - - - 3. 双机热备等系统软件所占的内存128MB 4. 应用程序所占的内存256MB 5. 数据库缓存6.86GB 6. 合理的内存利用率75% 总计10GB 存储容量需求分析除了上述的XYZ 网上银行系统和高法诉讼费缴费系统的存储容量要求之外，还有异步查询下载服务的存储要求。异步查询下载服务每隔1 小时生成一个下载数据包，每个数据包的大小为3MB，需要下载的数据包是上午十点生成的数据包，这个数据包需要保存2 年，其它数据包只要保存3 个月。因此，存储容量为: 233M 303+13M 365*

20、2=6GB+2GB=8GB 为避免存储系统成为系统性能的瓶颈，系统存储系统的使用率应小于40%，建议采用镜像方式存储数据，因此总的存储容量为: (137.2GB+8GB) 40% 2= 766GB 评估数据库服务器的性能，需要理解交易的类型、高峰期的情况、用户数量、在高峰时每个用户的交易数量。假如在高峰时，有三种典型的交易类型:轻的、一般的、重的。需要知道高峰时，每种交易的并发用户数目。假定高峰时间为:10:00-11:00，每个用户的交易数目如下: 轻的交易=120 交易 /用户一般的交易 = 60 交易 /用户重的交易= 15 交易 /用户名师资料总结 - - -精品资料欢迎下载 - -

21、- - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 8 页，共 10 页 - - - - - - - - - 每个交易所使用的CPU 秒评估出交易类型后，需要评估出运行每个交易所消耗的CPU 秒，如果假定B80 服务器每秒中支持10 个交易，则每个交易需要消耗0.1 个 CPU 秒。如果不知道如何评定CPU 秒，则根据应用类型参照下列表。基于 rPerf 的推算，评估数据库服务器的CPU rPerf(Relative performance) 是从 IBM 公司解析模型得出的商务处理性能估计值。该模型模拟部分系统的操作，如中央处理器、高

22、速缓存和内存，该模型没有模拟磁盘和网络的输入 /输出操作。虽然采用了一般数据库和操作系统的参数，但该模型不能反映出具体的数据库或AIX 版本。除非单独说明，否则rPerf 均在系统推出时估计。IBM pSeries 640-B80 为基准参照系统，其值为本。虽然rPerf 可用于比较商业处理性能，但实际的系统性能可能不同，取决于许多因素，包括系统硬件配置和软件设计与配置。评估数据库服务器的性能，需要理解交易的类型、高峰期的情况、用户数量、在高峰时每个用户的交易数量。假如在高峰时，有三种典型的交易类型:轻的、一般的、重的。需要知道高峰时，每种交易的并发用户数目。假定高峰时间为:10:00-11:

23、00，每个用户的交易数目如下: 轻的交易=120 交易 /用户一般的交易 = 60 交易 /用户重的交易= 15 交易 /用户下面举例说明如何计算所需的rPerf 值，假定某公司的情况如下: 业务高峰时间: 10:00-11:00=1Hour=3600 秒交易类型 : 无复杂查询的简单应用名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 9 页，共 10 页 - - - - - - - - - 相对交易类型，用户数目分布:轻的 =2000, 一般 =50, 重的 =5 在高峰时，每个用

24、户的交易数量: 轻的 =120 交易 /用户一般 =60 交易 /用户重的 =15 交易 /用户对于 rPerf=1 的服务器，每个交易响应的CPU 秒轻的 =1 一般 =3 重的 =15 最大的 CPU 利用率 :60% 根据上述公式，可推算出不同交易类型所对应的rPerf 值。轻的交易 :NU*TX*CS/PP=2000*120*1/3600=66.0 一般交易 :NU*TX*CS/PP=50*60*3/3600=2.5 重的交易 :NU*TX*CS/PP=5*15*15/3600=0.3 所需的总的rPerf/MC=(66.0+2.5+0.3)/0.7=98.3 rPerf 名师资料总结 - - -精品资料欢迎下载 - - - - - - - - - - - - - - - - - - 名师精心整理 - - - - - - - 第 10 页，共 10 页 - - - - - - - - -