数据库性能基准的5个问题

简介 数据库已经是绝大多数IT应用的核心，各种数据库看上去很大不同，多层体系结构以及SOA的发展，使得应用逻辑的实现前移。数据库的性能，与其功能相比较，变得越来越重要了。因此，性能是衡量数据库的非常重要的方面，我们这里将讨论数据库性能基准的五个

简介

数据库已经是绝大多数IT应用的核心，各种数据库看上去很大不同，多层体系结构以及SOA的发展，使得应用逻辑的实现前移。数据库的性能，与其功能相比较，变得越来越重要了。因此，性能是衡量数据库的非常重要的方面，我们这里将讨论数据库性能基准的五个常见问题。

1.Windows和Linux，哪个操作系统的性能基准结果更好？

这是一个有争议的很难回答的问题。虽然大部分可能认为Linux可能更快一些，但是Windows server平台在过去的几年中已经快速成熟了。下面是图表1,它是在相同的硬件环境下执行得到的在线TPC-C基准结果的图表，使用了32位和64位的Windows 2003 Server Release 2 和 CentOS 4 Update 3 (一个免费Redhat的企业版本)。

你可以看到，技术上看来是不分胜负的。因此,你可以按自己意愿选择，或者考虑到培训成本，可以选择拥有较多系统管理员的那个操作系统。

图1

2. 32位还是64位，哪种更好?这会影响操作系统的选择吗?

64位Unix 服务器已经有很多年了,但64位的Windows操作系统才刚刚变成现实。(Windows NT可运行在DEC Alpha上,但一直没有真正进入主流。)很长一段时间，AMD的Athlon-64和Opteron处理器一直很出色。直到2006年中Intel的二代双核CPU的出现，它的表现相当让人惊讶！现在我们可以用更好的价格购买这些硬件。我们将能耗和房间制冷都计算到TCO中。

与32位相比，64位真的有明显差异吗?根据图表1,回答是否定的。但那是因为64位提供的主要优势在于增加了可寻址内存。图表2将再次显示TPC-C基准执行的结果，但系统和数据库可以分配的内存的总数量增加了。

图2

我们有了这些很清楚的结果。这些数据显示,如果你的服务器有2GB或少一些的内存,在32位和64位的处理下没有明显的差别。但当你的服务器的内存增加到超过2GB以后,64位的优势就会显示出来.尽管诸如Oracle数据库有32位联接选项来欺骗数据库，使之可以访问稍多的内存(知名的巨大内存模型)，这仅仅只能有一点效果。特大内存对系统和数据库来说，可以不断实现性能的改进。

一般情况下，服务器的内存大于4GB时，建议使用64位。不过值得注意的是，有时某些类型的硬件（例如驱动器，iSCS）和更新的数据库选项(例如，ASM,OCFS)在32位的Linux上工作得更好。

3.哪个数据库拥有最好的性能基准：Oracle 10g，SQL Server 2005 还是MySQL 5.0?

这也是一个有争议的问题。说到它，仅仅是把经常提到最多的三个数据库拿来讨论。（这里并不是有意忽略DB2－UDB，PostgreSQL或所有的其他数据库）。我们知道数据库厂商一般是不欢迎公布性能基准数据的，特别是在它们之间的比较情况。尽管如此，我们来讨论这个常见的问题。图表3显示了在MySQL,SQL Server和Oracle数据库上执行的TPC－C基准的结果。

图3

碰巧的是我们不必冒任何厂商愤怒的风险，因为性能结果显示，它们的技术不分胜负。同样，你可以按照你的意愿选择数据库，或者是哪个数据库管理员多就选择哪一个。

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

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

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

图4

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

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

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

图5

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

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

图5