数据库性能基准的五个问题[2]

当然在这些厂商之间的花费是不同的但是因为没有人会按照报价购买产品所以按照这个因素进行比较TPCC是很困难的

如何确定一个服务器所能支持的最大并发OLTP用户数?

这始终是一个很难回答得问题因为人们经常想听到Dell 能处理多少的并发用户量事实上即使是同一系列的服务器有相同的内存容量但是也会由于CPU的数量CPU的时钟频率CPU的内核数高速缓沖存储器的大小等因素导致能力的差异比较服务器是很困难的除非你有看起来几乎一样配置的机器但是你也需要比较相同的网络和磁盘IO等情况假设你那样做问题变成你如何分析这样的基准结果并准确确定那台服务器的最大并发用户负载图表显示了TPCC基准的结果只在一台服务器上确定拐点（即用户负载开始对响应时间有负面影响）

图

如果你的最终用户要求响应时间（最常见的指标）少于秒那么在个并发用户这个点你应该停下来图显示这个服务器可支持多达个用户并发直到响应时间达到无法接受的急骤上升的点 在这种情况下TPS比率开始趋于平缓或减少这个例子中碰巧这两个点同时出现但是并不总是如此明显;这是因为有时两个拐点并不一定排列的这么整齐当拿不准时建议通常关注TPCC或OLTP类型事务的响应时间

如何确定一个服务器所能支持的最大数据仓库大小?

这又是一个很难回答的问题因为大多数人想听到是处理X千兆字节的数据需要一台Dell 上文中提到比较服务器是不容易的事情除非你拥有的主机几乎有一样的配置以及一样的网络和磁盘I/O环境磁盘I/O在这里是特别重要的因为TPCH结果大部分是由磁盘数量来决定的如果能比较服务器那么问题就变为如何从基准结果中确定那台指定服务器的最大数据仓库的大小在图表中显示了基于几个强大的Oracle RAC服务器配置的TPCH基准的测试结果这些服务器访问分布在多个SAN和超过个磁盘上的GB数据

图

在TPCH中值得注意的是应该同时关注整体运行时和间平均响应时间TPCH的询问是非常复杂的通常要花数个小时或好几天才能完成

根据图表最好的硬件配置大运行小时平均响应时间约小时然而通过几次运行时间很长的测试实际的响应时间的变化是很倾斜的因此如果你的用户对于高度复杂的决策支持查询能接受运行时间在个小时的个节点的集群将可以满足要求如果不能接受的话那么需要购买更多磁盘而不是增加更多的服务器对于千兆容量的数据仓库使用到个磁盘可以达到最佳的效果这种情况并不少见

[] []