Настройка SQL для оптимальной производительности… SSD или HDD?


8

Кто-нибудь знает какие-либо сравнения, которые показывают, как SSD сравнивают с HDD по производительности в среде SQL?

Я пытаюсь понять, какой выигрыш в производительности можно получить, перейдя на SSD.


1
Я уверен, что копия стандарта SQL будет одинаково хорошо работать на твердотельных накопителях и жестких дисках с вращающимся диском. Или, возможно, вас интересует конкретная попытка внедрения стандарта SQL?
Уомбл

Ответы:


14

Если вы выполняете большое количество небольших операций чтения, SSD работают намного быстрее. Вот одно из немногих сравнений о производительности базы данных. Посмотрите на нижний график для краткого ответа.

Для необработанной производительности твердотельные накопители обладают многими преимуществами, главное из которых состоит в том, что время поиска фактически равно 0, что означает, что все небольшие попадания HD в базу данных обрабатываются намного быстрее.

Тем не менее, существуют некоторые проблемы с текущим поколением в отношении времени записи, поскольку после стольких операций записи блок больше не может использоваться. Они могут писать совсем немного, я думаю, что, по словам представителей Intel, они округляют петабайт байтов для своих 32-Гбайт накопителей, прежде чем они начнут достигать опасного уровня программного обеспечения ... со временем это только улучшится.

Чтобы лучше понять, почему они работают намного лучше, прочитайте эту статью Anandtech о твердотельных накопителях . Он разбирается в деталях о дисках, о том, что хорошо, а что нет, а также о том, как они работают. Вверху также есть ссылка на последующие статьи, посвященные последней серии накопителей.


2
С точки зрения износа из-за ограниченных циклов записи, хорошие SSD в наши дни приближаются к безопасности вращения дисков из-за сочетания большей возможности циклов записи отдельных ячеек, «хитростей» слияния при записи для сокращения требуемых циклов записи и выравнивания износа алгоритмы. Даже для приложений с высокой нагрузкой ввода-вывода, таких как очень активная база данных, хороший SSD вряд ли будет перегружен перед обычной заменой, чем вращающийся диск. Просто держите регулярные, регулярно проверяемые резервные копии, как в любом решении для хранения данных.
Дэвид Спиллетт

Я согласен, именно поэтому я называю это проблемой, а не шоу-стопором ... дешевый диск имеет реальную проблему с этим прямо сейчас, и это больше проблема прошивки. В течение 6 месяцев я не думаю, что уровень износа будет даже повышен, он прогрессировал очень хорошо, очень быстро.
Ник Крейвер

1
Хороший ответ. Я хотел бы добавить, что в большинстве случаев журнал должен оставаться на обычном жестком диске, поскольку он последовательно записывается, а жесткие диски дешевы. Просто имейте фактическую базу данных на SSD, поскольку именно там находится произвольный доступ.
Пит

@PeteT - он немного меняется / зависит, помните, что один конкретный журнал является последовательным, да, но на сервере, на котором размещено много баз данных (например, в Stack Exchange, на котором размещается множество сайтов в базе данных), фактическое поведение гораздо ближе к произвольному доступу / записи, чем последовательный, так что это зависит от того, что / сколько вы работаете.
Ник Крейвер

Одна прекрасная вещь состоит в том, что, когда SSD достигает конца срока службы и больше не может быть записан, он все еще доступен для чтения. Этого нельзя сказать о вращающемся диске, который ломается.
Джангофан

4

Вы можете установить свою операционную систему и программное обеспечение SQL на стандартный жесткий диск, а затем добавить SSD для хранения файлов базы данных. Это должно ограничить количество операций записи на SSD-накопитель, а также максимально увеличить объем пространства, доступного для ваших данных на накопителе.


3

Я рекомендую вам прочитать следующую статью « Миграция серверного хранилища на твердотельные накопители»: анализ компромиссов , это довольно приятное чтение.

На мой взгляд, пока недостаточно преимуществ от SDD в области серверов. Может быть, через несколько лет их стоит купить, но на данный момент HDD - лучший выбор.


2

Ответ Ника Крейвера хорош; Я просто хочу добавить две оговорки к твердотельным накопителям, о которых, я думаю, люди должны знать:

а) Проблемы SSD с износом при записи не проходят, они имеют основополагающее значение для используемых флэш-ячеек. Ячейки SLC имеют намного более высокую стойкость записи, чем MLC, поэтому OP следует рассмотреть возможность получения диска SLC поверх MLC. Конечно, SLC также значительно дороже.

б) Текущие накопители кэшируют данные на накопителе перед их записью. Таким образом, существует риск потери данных, если питание отключается во время операции записи. Это то, что вы можете обойти, но кеш есть как для производительности, так и для уменьшения усиления записи.

ИМХО ни один из вышеперечисленных не является нарушителем. Я был бы готов развернуть SSD сегодня, но с некоторыми планами.

  1. Если незначительный риск потери данных неприемлем, то обычные жесткие диски SAS с отключенным кэшированием данных могут быть лучшим выбором.
  2. Я думаю, что вы должны измерить объем данных, записанных на SSD-накопитель в обычный день. Исходя из этого и спецификации износа производителей, рассчитайте ожидаемый срок службы твердотельного накопителя в соответствии со схемой использования. Если ожидаемый срок службы меньше запланированного срока службы серверов, установите приоритетную дату замены SSD. Точно так же как части самолета, замените это прежде, чем это станет вероятным отказом.

Части самолета? Не самая лучшая аналогия, если вы примените ее к шаттлам NASA, которые работают на компьютерах IBM AP101S с колоссальным 1 ГБ ОЗУ и без жесткого диска. Необходимость предсказуемости и надежности превыше всех других соображений.
CJM

1

Что-то иметь в виду.

Если вы работаете с базой данных настолько, что ваши чтения замедляются, и вам нужны твердотельные накопители, вам нужно исправить свои индексы или посмотреть, как увеличить объем оперативной памяти на сервере.

Большинство серверов баз данных после полной настройки не нуждаются в SSD для нормальной работы.


Мои чтения на самом деле не замедляются. Мы пытаемся оптимизировать запрос «первого попадания», где он занимает около 120-130 мсек при первом выполнении запроса и 80 мс после этого. Это время исключает создание планов запросов и чтение соответствующей статистики. Мы видим, что в нашем случае разница во времени тратится на чтение с диска, поэтому я пытаюсь выяснить, как я могу сделать первый удар ближе к 80 мс.
spoon16

Таким образом, даже после первого запуска, это все еще занимает 80 мс? Это в основном чтение данных или много ЦП (агрегация или сортировка)? Тем не менее думаю, что есть много места для «традиционной» оптимизации, прежде чем перейти к экзотическим технологиям хранения.
BradC

Если вам нужно перейти на диск при первом запуске запроса, то SQL почему-то выбивает данные из кэша. Сначала вы можете посмотреть, какова ожидаемая продолжительность жизни вашей страницы. Если он низкий, то больше оперативной памяти в порядке. Каков ваш коэффициент попадания в кеш до, во время и после запроса? Если оно ниже 99,8% или около того, индексация и больше оперативной памяти в порядке. Вы делаете какие-либо сканы? Если это так, то может потребоваться дополнительная индексация.
Мрденни

При нагрузке с интенсивной записью с сквозным кэшированием (то есть данными, физически записанными на диск до возврата вызова), вы должны заметно улучшить производительность записи с SSD, предполагая, что ваше приложение действительно связано с вводом / выводом. Обратите внимание, что это предпочтительная стратегия кэширования для SQL Server, особенно в сетях SAN, и MS требуют, чтобы SAN гарантировали это поведение для получения сертификата для использования с SQL Server.
ConcernedOfTunbridgeWells

1

Прочитайте эту статью (довольно старая - 2009):

Резюме: замените диски SAS 24 x 15 000 об / мин на 6 (да шесть) SSD-дисков и получите на 35% больше производительности. Это было с Intel X25M, которые больше не являются лучшими для SSD.

Для пользователей баз данных это фантастика, так как вы можете иметь меньшие, более быстрые серверы, используя меньше энергии


1

Одна вещь, чтобы рассмотреть, это иметь журнал транзакций на жестком диске и ваш MDF на SSD. Кроме того, срок службы будет сильно зависеть от типа приложения. OLTP может сгореть, хотя и быстро, так как статические данные не должны иметь проблем.


1

Мой собственный опыт был смешан здесь ...

Тестирование на Windows 7 с SQL Server 2008 Express R2. Работает на i7 Desktop с Sandy Bridge и установленной оперативной памятью 12G (мне кажется, DDR3?). Извините, что настольный компьютер, я только после того, как выяснил, сколько записей я могу управлять на платформе i7, прежде чем построить сервер.

Сначала я запустил эти тесты на установленном диске 1,5 ТБ 7200 об / мин, чтобы получить базовые тайминги.

10 тыс. Записей с обновлением процедур, оптимизация таблиц для хранения ранее связанных данных в плоской таблице, добавление индексов до тех пор, пока я не сократил время до нескольких секунд в качестве отправной точки, затем я продублировал записи до 1,2 миллиона и получил время 0: 3: 37 для тех же обновлений. 3 1/2 минуты не плохо для этой не рейдной установки.

Дублирование записей до 2,56 миллионов дало мне время 0:15:57 - почти в 5 раз больше. Скорее всего, это связано с тем, что объем установленной памяти 12G больше не просматривается.

Установив диск SSD и переместив базы данных, время фактически увеличилось до чуть более 20 минут. Я предполагаю, что это потому, что файлы подкачки находятся на жестком диске, и на диске SSD по умолчанию не было ни одного, поскольку он не был установлен в качестве диска ОС (когда я попробовал это, было много голубых экранов).

Добавил файл подкачки к накопителю SSD и перезапустил тест, 0: 5: 52 -m, так что файл подкачки, похоже, сделал свое дело, но я не уверен, что файл подкачки подходит для накопителя SSD по всем вышеуказанным причинам, они сильно написаны и могут привести к чрезмерному износу диска.

Одно предупреждение, я также включил Smartboost на этом диске, и это, возможно, также повлияло на время, будет выполнено без него.

На мой взгляд, в наши дни проще добавлять память, и за такую ​​стоимость гибридный диск с рейдом 0 + 1 может справиться почти без проблем.

edit: отключил файл подкачки на SSD и позволил Smart Boost делать свое дело, время улучшилось с 5:52 до 4:55 минут для 2,56 миллионов записей с серией из 3 обновлений каждая. Я попробую 8G ssd кеш на гибридном диске seagate 750G. тогда, если это не плохо, я попробую их в рейде 0 + 1.

последнее обновление, так как это старая ветка - но я хотел опубликовать результаты, которые я получил, чтобы кто-то мог их найти.

Перемещение базы данных в Seagate 750G Hybrid с 8G кешем SSD Я провел тест несколько раз, чтобы кэш SSD мог учиться. Это дает мне время 5:15 мсек для того же теста, обновляя 2,56 млн записей - это достаточно близко к производительности SSD (4:55 мсек с Intel Smartboost), чтобы я мог оценить стоимость.

При цене примерно в 50 долларов (239 долларов против 189 долларов в настоящее время) гибрид обеспечивает более чем шестикратное хранение и почти такую ​​же производительность без использования какого-либо дополнительного программного обеспечения для оптимизации. В рейде 0 + 1 я рассчитываю значительно улучшить время, и у этого привода есть 5-летняя гарантия, надеясь, что он мне не понадобится.


0

Лично я бы не использовал SSD по причинам, уже упомянутым; они будут постепенно замедляться, прежде чем в конечном итоге потерпят неудачу. Мы еще не знаем, когда это произойдет - текущие оценки - это просто оценки. Помните, когда мы все купили эти «неразрушимые» компакт-диски в начале / середине 80-х? Несколько лет спустя мы считали срок хранения данных на CD такой же глупостью, как и использование дискет.

Если у вас все оборудование, ОС и БД настроены правильно, вам не нужно играть на SSD.

Через несколько лет, когда продукты немного повзрослеют, будет другой сценарий. Но до тех пор ...


0

В статье Microsoft Research речь идет о цене за Гб, а не о приросте производительности. На самом деле он не подходит и не тестирует диски, а использует алгоритм ретроспективного преобразования, основанный на файлах журналов с реальных серверов.

Некоторые вещи, которые приходят на ум с SSD и SQL:

1 / Если вы не добавите правильные индексы, SSD будет более щадящим, поскольку время случайного поиска очень мало.

2 / Расходы значительно ниже по сравнению с тем, когда было проведено это исследование, и для небольших веб-приложений, скажем, для запуска серверной части телефонного приложения, а не корпоративных серверов Exchange, производительность могла бы сэкономить на привлечении консультанта для настройки SQL Server.

3 / Один SSD-накопитель с теневым копированием, безусловно, дешевле, чем набор шпинделей в шкафу RAID, а также контроллер и соединения. Не говоря уже о мощности и обогреве и стойке.

4 / Шпиндели печально известны тем, что они чаще всего умирают на компьютере. SSD не имеет движущихся частей, и час простоя может стоить цену SSD за один раз.

5 / Износ - это проблема, но у них есть способы управления ею (включая рассеивающие блоки), которые возможны, потому что случайно фрагментированные данные не замедляют работу SSD. Кроме того, небольшая база данных на большом диске, вероятно, не изнашивается вовремя, чтобы купить более дешевую новую в будущем.

6 / Существует тенденция к нереляционным базам данных и выполнению объединений на среднем уровне. Это действительно может изменить ситуацию: ввод / вывод в простые неиндексированные таблицы на SSD-дисках в шардах без снижения производительности и с гораздо более простым масштабированием. Также экономия на лицензиях SQL Server для каждого шарда

7 / Это все теоретически. Если бы у кого-нибудь было реальное тестирование производительности на шпинделях, я бы с удовольствием посмотрел.

Люк

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.