SSD против HDD для баз данных

42

Я пытаюсь приобрести новый сервер для запуска MySQL Server. Этот новый сервер будет рабом моей основной машины. Тем не менее, этот сервер будет предназначен только для отчетов «Много чтений и сложных запросов».

Сейчас я планирую инвестировать в твердотельные жесткие диски, но мне было интересно, стоит ли это того. Разница между SSD и жестким диском SATA 7200 составляет около 1500 долларов, а на SSD меньше места. Если я буду инвестировать в SSD, скорость будет заметна?

Я могу купить 4 (500 ГБ SATA 7200) за 1500 долларов дешевле, чем купить 2 (500 ГБ SSD)

Не могли бы вы помочь мне принять решение, чтобы узнать, стоит ли это обновление или нет?

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

Этот сервер будет иметь 32 ГБ оперативной памяти и будет работать под управлением Ubuntu 12.04

Майк
источник
Насколько велика ваша база данных в гигабайтах? Какой из приведенных ниже ответов является наиболее правильным, действительно зависит от понимания того, сколько данных имеется.
Натан Джолли
1
Если вы в конечном итоге используете SSD, вы можете подождать до апреля Ubuntu 14.04 или включить TRIM вручную 12.04. Смотрите эту статью для получения дополнительной информации.
OSE
5
Serial ATA (SATA) - это интерфейс. Есть SATA SSD и жесткие диски (HDD), которые не используют SATA.
Деннис
Покупка чего-то, что не приносит вам денег, вряд ли является инвестицией ...
inf3rno

Ответы:

25

Да, с большим количеством чтений и отчетов SSD будет иметь огромное значение. От 7200 об / мин можно ожидать не более ~ 100 IOPS, в то время как самый дешевый SSD может быть как минимум в 5 раз быстрее. С хорошим SSD вы можете получить до 20000 IOPS или даже больше.

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

nmad
источник
4
Как бы вы определили хороший SSD?
Майк
Все дело в производительности и тестах. Что бы я сделал, это Google для бенчмарков или обзоров модели SSD, которую вы покупаете. Кроме этого en.wikipedia.org/wiki/IOPS#Examples дает очень общий обзор.
nmad
20

Здесь нужно учесть три фактора:

  1. Размер вашей базы данных
  2. Объем памяти у вас на сервере
  3. Ваша конфигурация my.cnf, в частности innodb_buffer_pool_size

Если доступная память> размер базы данных , ваш сервер, вероятно, сможет хранить все ваши данные в памяти, и, следовательно, SSD может быть пустой тратой денег. Буфер InnoDB не имеет ничего общего с query_cacheопциями.

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

Как правило, базы данных хранят наиболее часто используемые данные в памяти - если 80% ваших данных используются редко или никогда не используются, вам потребуется всего лишь 20% вашей базы данных в памяти для поддержания производительности.

Точный объем памяти, который вам нужен, не будет сразу очевиден, но если ваша база данных не превышает 200 ГБ, я бы настоятельно рекомендовал воспользоваться советом Up_One и тратить дополнительные деньги на память вместо SSD.

NB. Если ваша база данных использует MyISAM (вы можете проверить это с помощью show table status;), подумайте об изменении InnoDB. MyISAM key_buffer_cacheхранит только индексные блоки, где InnoDB Buffer Pool хранит целые блоки данных. В большинстве случаев InnoDB окажется лучшим двигателем для работы.

Натан Джолли
источник
Как я могу поместить базу данных в память? сервер является ведомым, поэтому он будет постоянно выполнять запись на него, но он также будет иметь большую нагрузку на чтение из-за отчетов
Mike
Если ваши таблицы InnoDB, и если ваш буферный пул InnoDB достаточно большой, MySQL автоматически будет управлять кэшированием вашей базы данных в памяти и будет пытаться постоянно хранить наиболее часто используемые данные в памяти. Документация MySQL предоставляет довольно хороший обзор того, как это работает .
Натан Джолли
@NathanJolly, даже если вся база данных находится в памяти, при сохранении данных все равно будет выполняться чтение и запись на жесткий диск + существуют ограничения для различных серверов. Например, версия SQL Server Express ограничена использованием только 1 ГБ памяти, поэтому она не может разместить большую базу данных в памяти в первом месте.
Джекофалл
@Jackofall, хотя это абсолютно верно, в этом вопросе указана база данных MySQL с большим объемом чтения. Любой запрос только для чтения, который можно обслуживать из памяти, а не достигать диска - даже быстрого диска - это хорошая новость.
Натан Джолли
6

Я не думаю, что это хорошая идея!
Мой совет
увеличить размер вашего буферного пула InnoDB - лучший способ ускорить MySQL. Если вы можете добавить больше оперативной памяти, сделайте это. Это поместит большинство ваших горячих данных в память, так что представьте! Диск против Памяти!
Идеальный сценарий - иметь размер вашей памяти
SSD базы данных - это здорово, но это будет дорого! и это хорошо только для чтения интенсивных работ.

Проверьте эту ссылку для хорошей статьи по этому вопросу от Вадима Ткаченко

Up_One
источник
1
Статья, на которую вы ссылаетесь, уже почти 4 года, цены на твердотельные накопители по сравнению с этим моментом более чем вдвое ниже, а производительность также значительно выросла. Память размер базы данных? Как насчет базы данных 500Gb? Это не только объем оперативной памяти, но и сервер, который вам нужно купить, который имеет так много доступных банков памяти.
Ярослав
Что касается размера БД! Да, вы никак не можете это сделать. Но, как я уже сказал, это был бы идеальный сценарий!
Up_One
6

В качестве альтернативы: вы можете использовать как большой жесткий диск (в идеале RAID1 с тремя дисками) для хранения данных, так и меньший SSD для хранения индексов.

Обоснование:

  • индексы довольно малы, поэтому вы можете использовать меньший SSD
  • общие запросы в любом случае должны в основном попадать в индексы
  • RAID1 дает вам отказоустойчивость
  • RAID1 дает вам балансировку нагрузки для случайного чтения
  • три диска оставляет отказоустойчивость, если диск выходит из строя
  • индексы могут быть восстановлены в случае сбоя SSD
Саймон Рихтер
источник
5

Сделай это.

Вы упомянули, что у вас большая нагрузка на чтение, поэтому вы уже избежали большой проблемы с использованием SSD в базах данных: износ. Нет пишет, значит нет износа, так что ты золотой.

Как упомянул edvinas.me, ваш IOPS на порядок быстрее с SSD, чем с вращающимися дисками. Для базы данных IOPS в значительной степени переводит в запросы в секунду. Игнорируя кэш-память ОЗУ, вы будете обслуживать примерно в 100 раз больше запросов с SSD, чем с диска 7200 об / мин.

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

Я не уверен, откуда взялось $ 1500. Проверяя моего местного (австралийского) поставщика, я могу получить твердотельный накопитель 960 ГБ с хорошей репутацией за 750 долларов США ( http://www.auspcmarket.com.au/960gb-crucial-m500-sata-6gbps-2-5-7mm-with- 9-5mm-adapter-ssd-read-500mb-s-write-400mb-s / ). Вращающиеся диски более или менее бесплатны, но 750 долларов по-прежнему намного приятнее, чем 1500 долларов.

(Ой, подождите - вы, вероятно, заказываете у известного поставщика, так что они заряжают вас через нос для SSD? Я всегда покупаю SSD отдельно и меняю его в себе, но я не знаю, так ли это допустимо в вашей среде.)

Скорее всего, вам тоже будет меньше оперативной памяти, но, не зная точной рабочей нагрузки, трудно судить, можно ли безопасно уменьшить объем оперативной памяти без ущерба для производительности.

Если вы все еще не уверены, вы можете получить большие диски со скоростью вращения 10 000 об / мин, но в любом случае они будут стоить почти столько же, сколько SSD, и при этом будут работать намного медленнее.

Если вам нужно масштабировать намного больше 1 ТБ, тогда твердотельные накопители начинают становиться слишком дорогими, но на 1 ТБ я бы сказал, что твердотельные накопители - явная победа.

Йен Хаусон
источник
3

Я определенно согласен с тем, что наибольшая отдача от прибыли заключается в увеличении размера innodb_db_bufferpool, но, к сожалению, это полностью зависит от размера вашего набора данных и частоты обращения к различным дисковым блокам. Я поддерживаю несколько баз данных, которые имеют довольно большой размер в 200 ГБ +, поэтому встраивать все в ОЗУ на самом деле не вариант, и по этой причине мы недавно переключились на хранение на основе SSD. Я провел довольно большое исследование с точки зрения использования IOPS для MySQL на различных RAID-массивах, к которым у меня есть доступ. Вот результаты:

1253 IOPS - 4 x SCSI 15k (3,5 ") диска

тест: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64, чтение: io = 3071,7 МБ, bw = 5012,8 КБ / с, iops = 1253 , runt = 627475 мс, запись: io = 1024,4 МБ, bw = 1671,7 КБ / с, iops = 417, runt = 627475 мс, процессор: usr = 0,63%, sys = 3,11%, ctx = 985926, majf = 0, minf = 22

2,558 IOPS - 8 x 10K об / мин 900 ГБ SAS (2,5 ") диск

тест: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64, чтение: io = 3071,7 МБ, bw = 10236 КБ / с, iops = 2558, runt = 307293 мс, запись: io = 1024,4 МБ, bw = 3413,5 КБ / с, iops = 853, runt = 307293 мс, процессор: usr = 2,73%, sys = 8,72%, ctx = 904875, majf = 0, minf = 25

23 456 операций ввода-вывода в секунду - SSD-сервер Rackspace Performance 2

тест: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64, чтение: io = 3071,7 МБ, bw = 93708 КБ / с, iops = 23426, runt = 33566 мс, запись: io = 1024,4 МБ, bw = 31249 КБ / с, iops = 7812, runt = 33566 мс, процессор: usr = 5,73%, sys = 35,83%, ctx = 181568, majf = 0, minf = 23

35 484 операций ввода-вывода в секунду - 2 x зеркальных 2,5-дюймовых MLC-процессора EDGE Boost 480 Гб ( http://www.edgememory.com )

тест: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64, чтение: io = 3068,4 МБ, bw = 141934 КБ / с, iops = 35483, runt = 22137 мс, запись: io = 1027,7 МБ, bw = 47537 КБ / с, iops = 11884, runt = 22137 мс, процессор: usr = 11,68%, sys = 69,89%, ctx = 24379, majf = 0, minf = 20

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

Если вас интересуют подробности, остальная часть написания находится в моем блоге:

http://www.juhavehnia.com/2015/05/using-ssds-to-improve-mysql-performance.html

Юха Вехния
источник