配置SQL以获得最佳性能…SSD还是HDD?


8

有谁知道在SQL环境中SSD可以与HDD进行比较的比较吗?

我试图了解通过迁移到SSD可以获得哪种类型的性能优势。


1
我敢肯定,SQL标准的副本在SSD上的性能将与旋转HDD一样好。也许您对SQL标准的特定尝试实现感兴趣?
womble

Answers:


14

如果您要进行大量的小型读取,则SSD的速度快得多。 这是有关数据库性能的一些比较比较之一。 请看底部的图形以获取简短答案。

对于原始性能,SSD提供了许多优势,主要优势是查找时间实际上为0,这意味着数据库处理的所有小型HD命中要快得多。

但是,当前一代对写入寿命存在一些担忧,因为在进行了如此多次写入之后,一个块不再可用。他们可以写很多东西,我相信intel会说他们的32GB驱动器大约达到PB字节,然后才开始达到危险的软件级别……随着时间的流逝,这种情况只会越来越好。

为了更好地了解为什么它们的性能要好得多,请阅读Anandtech的SSD文章。他详细介绍了驱动器,什么是好驱动器,什么不是驱动器以及驱动器工作原理的来龙去脉。顶部还有指向后续文章的链接,该文章涵盖了最新的驱动器系列。


2
就由于有限的写入周期而导致的磨损而言,由于各个单元具有更大的写入周期能力,合并合并的“技巧”以减少所需的写入块周期以及磨损平衡,如今,好的SSD已经接近旋转磁盘的安全性。算法。即使对于高IO负载的应用程序(例如非常活跃的数据库)来说,在常规更换之前也要比旋转磁盘更容易获得良好的SSD。像任何存储解决方案一样,只需保持定期,经过定期测试的备份即可。
David Spillett

我同意,这就是为什么我称其为关注点而不是止步不前的原因……便宜的磁盘目前确实有此问题,而更多的是固件问题。在6个月内,我认为磨损程度甚至不会再提高,而且进展非常快。
尼克·克拉弗

1
好答案。补充一点,我认为在大多数情况下,日志应该保留在普通硬盘上,因为它是顺序写入的,而且硬盘价格便宜。只需将实际数据库放在SSD上即可,因为这是随机访问的地方。
PeteT 2011年

@PeteT-它有所不同/取决于,请记住,一个特定的日志是连续的,但是在托管许多数据库的服务器(例如Stack Exchange在一个数据库中托管许多站点的服务器)上,实际行为比随机访问/写入要近得多顺序的,所以这取决于您正在运行多少。
尼克·克拉弗

一个美丽的事情是,当SSD达到使用寿命并且无法再写入时,它仍然可以读取。您不能说旋转的磁盘坏了。
djangofan 2011年

4

您可以在标准硬盘驱动器上安装操作系统和SQL软件,然后添加SSD以仅保存数据库文件。这将限制SSD驱动器的写入次数,并使磁盘上的数据可用空间最大化。



2

尼克·克雷弗(Nick Craver)的回答很好。我只想向SSD添加两个警告,我认为人们应该意识到:

a)SSD的写磨损问题不会消失,它们是所用闪存单元的基础SLC单元具有比MLC高得多的写耐久性,因此OP应该考虑通过MLC获得SLC驱动器。当然,SLC也要昂贵得多。

b)当前驱动器在将数据写出之前在驱动器上缓存数据。因此,如果在写操作期间断电,则存在数据丢失风险。您可以解决该问题,但是缓存既可以提高性能,又可以减少写放大。

恕我直言,以上都不是破坏交易的人。我今天准备将SSD部署到生产中,但首先要进行一些计划。

  1. 如果微小的数据丢失风险是不可接受的,那么关闭数据缓存的常规SAS硬盘可能是更好的选择。
  2. 我认为您应该测量在正常情况下写入SSD驱动器的数据量。根据此信息和制造商的磨损规格,根据您的使用方式计算SSD的预期寿命。如果预期寿命低于服务器计划寿命,请为SSD设置抢占式替换日期。就像飞机零件一样,在可能发生故障之前将其换掉。

飞机零件?如果将其扩展到NASA航天飞机上,那不是最好的类比,NASA航天飞机在具有高达1GB RAM和无HDD的IBM AP101S计算机上运行。对可预测性和可靠性的需求高于所有其他考虑因素。
CJM

1

要记住的事情。

如果您访问数据库的速度足以使读取速度变慢并且需要SSD,则需要修复索引或考虑向服务器添加更多RAM。

多数数据库服务器一旦进行了充分调优,就不需要SSD即可正常运行。


我的阅读实际上并没有放缓。我们正在尝试优化“首次匹配”查询,该查询第一次执行大约需要120-130ms,之后大约需要80ms。这些时间不包括创建查询计划和读取相关统计信息。我们可以看到,在我们的案例中,时间上的差异是花在从磁盘读取上,因此尝试探索如何使第一次命中时间更接近80ms。

因此,即使在第一次运行后,仍需要80毫秒?那主要是数据读取还是大量的CPU(聚合或排序)?在使用外来存储技术之前,仍然认为“传统”优化还有很大的空间。
BradC

如果必须在第一次运行查询时转到磁盘,则SQL由于某种原因会将数据踢出缓存。您可能首先想看看您的页面预期寿命是多少。如果它很低,则需要更多的RAM。查询之前,查询期间和查询之后的缓存命中率是多少?如果它低于99.8%左右,则索引和更多的RAM按顺序进行。您要进行任何扫描吗?如果是这样,则可能需要更多索引。
mrdenny

在具有直写式缓存的繁重写工作负载(即,在调用返回之前将数据物理提交到磁盘)上,假设您的应用程序确实受I / O约束,则应该从SSD获得明显更好的写性能。请注意,这是SQL Server首选的缓存策略,尤其是在SAN上,并且MS要求SAN保证这种行为才能获得与SQL Server一起使用的认证。
ConcernedOfTunbridgeWells 2010年

1

阅读这篇文章(相当古老-2009年):

简介:用6个(是6个)SSD替换24 x 15k RPM SAS驱动器,但性能仍提高35%。这就是Intel X25M,它们不再是SSD的佼佼者。

对于数据库人员来说,这是很棒的事情,因为您可以使用更少的功率拥有更小的更快的服务器。


1

要考虑的一件事是将事务记录记录在HDD上,将MDF记录在SSD上。寿命也会在很大程度上取决于应用程序类型。OLTP可能会很快烧毁,而在此情况下,合理的静态数据应该没有问题。


1

我自己的经历在这里是混杂的...

使用SQL Server 2008 Express R2在Windows 7上进行测试。在装有Sandy Bridge和12G RAM的i7桌面上运行(我认为是DDR3)。对不起,安装程序是台式机,在构建服务器之前,我刚知道在i7平台上可以管理多少记录。

我首先在已安装的1.5TB 7200rpm驱动器上进行了这些测试,以获得基本时间。

具有更新过程的10k条记录,优化表以将以前相关的数据存储在平面表中,添加索引,直到我将计时降低到几秒钟为起点,然后我将记录重复到120万并获得了计时的更新时间为0:3:37。3 1/2分钟对于这种非突袭设置来说并不坏。

将记录翻倍至256万,使我获得了0:15:57的时间-几乎增长了5倍。可能主要是由于分页通过了已安装的12G内存。

安装了SSD驱动器并移动了数据库,时间实际上增加到20多分钟。我假设这是因为页面文件是每个硬盘驱动器,并且默认情况下,SSD驱动器上没有页面文件,因为它没有作为操作系统驱动器安装(当我尝试这样做时,蓝屏屏风)。

向SSD驱动器添加了一个页面文件,然后重新测试0:5:52 -m,因此该页面文件似乎已经完成了窍门,但由于上述所有原因,我不确定该页面文件是否适合SSD驱动器,它们会严重影响驱动器,并可能增加驱动器的不适当磨损。

需要说明的是,我还在该驱动器上启用了Smartboost,并且可能也会影响定时,如果没有它,它将重新运行。

我的最佳感觉是,这几天添加内存比较容易,并且出于成本考虑,混合磁盘的0 + 1突袭几乎可以解决所有问题。

编辑:禁用SSD上的页面文件,并让它进行智能增强功能,将256万条记录的时间从5:52分钟改进为4:55分钟,每个记录进行了3次更新。接下来,请尝试在Seagate 750G混合驱动器上尝试8G ssd缓存。然后,如果那还不错,我会在突袭0 + 1中尝试它们。

关于此的最新更新,因为这是一个旧线程-但我想将得到的结果放在那里,以便有人可以找到它们。

将数据库移动到具有8G SSD缓存的Seagate 750G Hybrid上,我进行了几次测试,以便SSD缓存可以学习。它为我提供了5:15 m:s的定时测试时间,更新了256万条记录-足以接近SSD性能(使用Intel Smartboost时为4:55 m:s),让我考虑成本。

混合动力的价格高出约50美元(现在为239美元,而现在为189美元),提供了6倍以上的存储量和几乎相同的性能,而无需运行任何其他软件进行优化。在突袭0 + 1中,我希望计时得到大大改善,并且该驱动器具有5年保修,这里希望我不再需要它。


0

就个人而言,出于上述原因,我不会使用SSD。他们将逐渐减速,直到最终失败。我们尚不十分清楚何时会发生这种情况-当前的估算值仅仅是估算值。还记得我们在80年代初/中期购买了那些“坚不可摧”的CD吗?几年后,我们认为长期在CD上存储数据与使用软盘一样愚蠢。

如果您已正确配置了硬件,操作系统和数据库,则无需在SSD上赌博。

几年后,当产品稍微成熟时,情况将有所不同。但是直到那时...


0

Microsoft Research文章关注的是每Gb成本,而不是性能增益。它实际上并不能安装和测试驱动器,而是使用基于来自实际服务器的日志文件的回播算法。

SSD和SQL会引起一些注意:

1 /如果您忽略添加正确的索引,则由于随机寻道时间太短,SSD的容忍度会高得多。

2 /与进行这项研究的时间和小型Web应用程序(例如运行电话应用程序的后端而不是企业Exchange服务器的后端)相比,成本要低得多,这种性能可以节省雇用顾问来调整SQL Server的费用。

3 /具有卷影副本的单个SSD驱动器肯定比RAID机柜中的一堆主轴,控制器和连接要便宜。更不用说电源,加热和机架空间。

4 /主轴是最常死在计算机上的零件,因此臭名昭著。SSD没有活动部件,一个小时的停机时间可能会一次性使SSD价格下降。

5 /磨损是一个问题,但是他们有办法进行管理(涉及散射块),这是可能的,因为随机碎片化的数据不会降低SSD的速度。而且,将来大容量磁盘上的小型数据库可能不会及时磨损以购买价格便宜的新数据库。

6 /非关系数据库和在中间层进行联接的趋势。这可能会真正改变事情:将I / O转换为分片上SSD驱动器上的简单未索引表,而不会降低性能,并且具有更简单的扩展方案。还可以节省每个分片的SQL Server许可证。

7 /这都是理论上的。如果有人对主轴进行了真实的性能测试,我很乐意看到。

路加

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.