SSD vs 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.

Примітка: Якщо у вашій базі даних використовується MyISAM (ви можете перевірити це show table status;), подумайте про зміну на InnoDB. MyISAM key_buffer_cacheзберігає лише індексні блоки, де як пул InnoDB Buffer зберігає цілі блоки даних. У більшості випадків InnoDB виявиться кращим двигуном для роботи.

Я не думаю, що це така гарна ідея!
Моя порада
збільшить розмір буферного пулу InnoDB - найкращий спосіб прискорити MySQL. Якщо ви можете додати більше оперативної пам’яті, зробіть це. Це збереже більшість ваших гарячих даних у пам’яті, тому уявіть! Диск проти пам'яті!
Ідеальний сценарій - мати пам’яті розмір
SSD вашої бази даних - це чудово, але це буде дорого! і це добре лише для читання інтенсивних робіт.

Перевірте це посилання для приємної статті про це від Вадима Ткаченка

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

Обгрунтування:

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

Зроби це.

Ви згадали, що у вас є велике навантаження для читання, тому ви вже уникли великої проблеми із використанням SSD на базах даних: wearout. Ніяке письмо означає, що немає зносу, значить, ти золотий.

Як згадувалося edvinas.me, ваш IOPS на SSD-дистрибуцію набирає швидкість, ніж зі спінінг-дисками. Для бази даних IOPS в значній мірі перекладає запити в секунду. Ігноруючи кеш оперативної пам'яті, ви будете обслуговувати приблизно 100 разів більше запитів з SSD, ніж з диска 7200RPM.

TRIM не матиме великої різниці, оскільки це велике навантаження для читання, і це здається, що ви все одно плануєте заповнити диск. Не стрес від цього.

Я не впевнений, звідки взялася річ у розмірі 1500 доларів. Перевіряючи свого місцевого (австралійського) постачальника, я можу отримати 960 Гб SSD надійного заробляння за 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 окремо і міняю його в собі, але я не знаю, чи це допустиме у вашому оточенні.)

Ви, ймовірно, також отримаєте менше оперативної пам’яті, але не знаючи точного навантаження, важко судити про те, чи зможете ви безпечно знизити оперативну пам’ять, не пошкодивши продуктивність.

Якщо ви все ще не впевнені, ви можете отримати великі накопичувачі 10k RPM, але вони в кінцевому підсумку коштують майже стільки ж, скільки і SSD, але при цьому будуть значно повільнішими.

Якщо вам потрібно масштабувати значно більше 1 ТБ, то SSD-диски починають надто дорого коштувати, але на 1 ТБ я б сказав, що SSD - це явна вигода.

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

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

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

2558 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,7MB, bw = 10236KB / s, iops = 2558, runt = 307293msec write: io = 1024,4MB, bw = 3413,5KB / s, iops = 853, runt = 307293msec cpu: usr = 2,73%, sys = 8,72%, ctx = 904875, majf = 0, minf = 25

23 456 IOPS - Rackspace Performance 2 SSD-сервер

тест: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 прочитати: io = 3071,7MB, bw = 93708KB / s, iops = 23426, runt = 33566msec write: io = 1024,4MB, bw = 31249KB / s, iops = 7812, runt = 33566msec CPU: usr = 5,73%, sys = 35,83%, ctx = 181568, majf = 0, minf = 23

35 484 IOPS - 2-х дзеркальний EDGE Boost 480 ГБ на 2,5 "MLC ( http://www.edgememory.com )

тест: (g = 0): rw = randrw, bs = 4K-4K / 4K-4K / 4K-4K, ioengine = libaio, iodepth = 64 прочитати: io = 3068.4MB, bw = 141934KB / s, iops = 35483, runt = 22137msec write: io = 1027.7MB, bw = 47537KB / s, iops = 11884, runt = 22137msec CPU: usr = 11,68%, sys = 69,89%, ctx = 24379, majf = 0, minf = 20

Тож зрозуміло, що високоякісний SSD сьогодні є дивовижними виконавцями. Два дзеркальних SSD легко перевершують 16-ти дисковий корпус SAN, і це лише переконливе твердження.

Якщо вас цікавлять усі деталі, решту записів можна знайти в моєму блозі:

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