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

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

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

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

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

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

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

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

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

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

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 окажется лучшим двигателем для работы.

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

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

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

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

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

Сделай это.

Вы упомянули, что у вас большая нагрузка на чтение, поэтому вы уже избежали большой проблемы с использованием 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 ТБ я бы сказал, что твердотельные накопители - явная победа.

Я определенно согласен с тем, что наибольшая отдача от прибыли заключается в увеличении размера 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