Чи може масовий імпорт даних MySQL на SSD пошкодити його?

Мені потрібно імпортувати досить багато даних (~ 100 млн. Рядків, ~ 100 разів) у базу даних MySQL. Наразі він зберігається на моєму жорсткому диску, і вузьким місцем мого імпорту, здається, є швидкість запису на жорсткий диск.

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

Це насправді не є однозначною відповіддю на це.

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

З цього часу накопичувачі стали більшими, дешевшими, надійнішими, призначеними для більшого читання / запису, а операційні системи стали розумнішими.

SSD-диски в SQL не тільки поширені, але й часто заохочуються. Не соромтеся ознайомитися з сестринським сайтом DBA .

Думаю зробити це, якщо припустити, що SQL-сервер побудований належним чином із зайвими дисками. Якщо ні, то в будь-якому разі очікуйте невдачі.

Читання добре, і SSD-файли можуть зчитувати з них без будь-яких згубних ефектів.

Писання - інша справа. Очищення трохи впливає на цілісність біта і після багатьох послідовних записів біт перестане приймати нові записи взагалі. Однак його все ще можна прочитати.

Дозвольте сказати, що обмеження на записи нових приводів підприємств величезні. Візьміть новий 845DC Pro від Samsung. Це добре для 10 приводів запису на день протягом 5 років гарантії. Я думаю, це зробить удвічі більше цього числа. Щоб перерахувати це, це 14 600 ТБ, написані за 5 років на моделі 800 ГБ.
Або 2920 ТБ на рік,
або 8 ТБ на день, протягом п’яти років .

Покажіть мені жорсткий диск з гарантією, яка охоплює таку велику користь. Я навіть не впевнений, що ви можете записати 8 ТБ на жорсткий диск за день: - (середня пропускна здатність 50 Мб / с * 60 (секунди) * 60 (хвилин) * 24 (години) = 4,320 000 МБ / день = 4,32 ТБ / день) Виявляється, ви не можете (на середньому приводі).

Поки ви використовуєте подібний диск, заснований на V-NAND (або однаково довговічний SLC), а не той, який базується на TLC або поганому MLC-спалаху, у вас все буде добре. І все одно, RAID 10 та резервні копії - ваш друг із причини. І принаймні, якщо межа запису на SSD все-таки стає проблемою, ви все одно можете читати дані, що зберігаються у несправних бітах.

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

Запис на SSD не обов’язково поганий. Це погано написання та перезапис одного блоку. Значить, якщо ви пишете файл, видаліть його, потім запишіть його знову або вносите невеликі зміни у файл знову і знову. Це спричиняє знос SSD-дисків. Бази даних, безумовно, впишуться в цю категорію.

Однак згідно з цією статтею , петабайти даних були записані на SSD та все ще функціонують. Можливо, це пов'язано з досягненнями вирівнювання зносу :

Носіть спроби вирівнювання, щоб подолати ці обмеження, упорядкувавши дані так, щоб стирання та перезаписи розподілялися рівномірно по носіям. Таким чином, жоден блок стирання передчасно не виходить із-за високої концентрації циклів запису.

У вашій конкретній ситуації я б мав, щоб бази даних проживали на SSD для швидкості, але створювали резервні копії щодня. Ви також можете розглянути можливість отримання двох SSD в масиві RAID 1 . Ймовірність виходу з ладу двох SSD одночасно низька.

Примітка: RAID-масиви НЕ резервні копії !!!! Незалежно від того, використовуєте ви масив RAID чи ні, майте резервну копію. Незалежно від того, використовуєте ви SSD чи ні, майте резервну копію.

Припустимо, що ваш імпорт не передбачає жодних оновлень та жодних видалень. Так ви робите всі вставки. Це має бути лише запис нових даних у журнал транзакцій.

Це означає, що як дані додаються, вони завжди записуються в новий сектор. Можливо, є кілька буферів / свопів, які повторюються / записуються кілька разів, але ігноруючи це, всі ці вставки теоретично призведе до не більше одного запису в секторі . Залежно від того, як реалізовано MySQL та який тип масової вставки ви виконуєте, ви можете генерувати другий набір записів пізніше, коли журнал транзакцій інтегрований у основний файл даних (я перейду до розуміння різних двигунів БД , і якщо припустимо, що MySQL дещо схожий за тим, як очищаються журнали транзакцій).

Справа в тому, що ви не "збиваєте" SSD. Тобто ви не робите великої кількості модифікацій / ходів / видалень / тощо. що потенційно може переписуватись в одних і тих же секторах багато разів. Таким чином, ви по суті збираєтесь лише генерувати дуже малу кількість записів у секторі, і саме це дійсно має значення.

Якщо припустити, що ви повністю не заповнюєте SSD, повинно бути достатньо вільного місця для гарячих точок (наприклад, буферів / замінників), які вимикаються, щоб мінімізувати знос завдяки алгоритмам вирівнювання зносу.

(Індекси можуть бути іншою справою. Оскільки кластеризовані індекси у багатьох БД включають багато модифікацій під час вставки даних. Зазвичай, роблячи великі інерти в середовищі сховища даних, ви вимикаєте індекси під час масового імпорту та оновлюєте їх після.)

Це не питання.

Перш за все, SSD значно покращилися за останні роки. Перезабезпечення та вирівнювання зносу (і в невеликій кількості, команда TRIM, хоча у вашому випадку не застосовується) зробили їх цілком придатними як важкі диски загального призначення. Я не використовую нічого, крім SSD на своєму ПК для розробки (що регулярно робить багато компіляцій), навіть не підходячи ніде поблизу циклу стирання.

Далі, це твердження:

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

відверто неправильно. Так буває навпаки, часті невеликі записи , якщо щось таке, можуть пошкодити SSD.

На відміну від традиційних жорстких дисків, SSD-накопичувачі (а точніше спалах на базі NAND всередині) фізично організовані у великі блоки, які логічно містять кілька секторів. Типовий розмір блоку - 512 кБ, тоді як сектори (що є одиницею, яку використовує файлова система) традиційно становлять 1 кБ (можливі різні значення, два десятиліття тому 512B було загальним).
Три речі можна зробити за допомогою 512kB-блоку. З нього можна прочитати, частину цього або все можна запрограмувати (= записати на), а все це можна стерти. Стирання є проблематичним, оскільки існує обмежена кількість циклів стирання, і ви можете видалити лише повний блок.

Тому великі записи дуже зручні для SSD, тоді як маленькі - не.

У випадку невеликих записів контролер повинен прочитати блок, змінити копію, видалити інший блок і запрограмувати його. Без кешування у найгіршому можливому випадку вам потрібно буде стерти 512 000 блоків, щоб записати 512 кілобайт. У кращому можливому випадку (велике безперервне записування) потрібно зробити рівно 1 стерти.

Імпорт у базу даних MySQL сильно відрізняється від виконання багатьох окремих запитів вставки. Двигун здатний згортати багато записів (і даних, і індексів) разом і не потребує синхронізації між кожною парою вставок. Це означає набагато більш сприятливий для SSD шаблон запису.

SSD не подобається. Якщо ви будете тримати максимальну швидкість запису протягом 5-10 років (24 години на день, 7 днів на тиждень), то у вас може виникнути пошкоджений SSD.

Ofc. Через 5 років більшість серверів досягли свого економічного кінця.

Відмова від відповідальності:
Не намагайтеся цього робити з самим першим поколінням SSD. Ті, де менш надійні.

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

В середньому, скільки байтів у кожному рядку?

Якщо ви можете сказати мені, що є 10 стовпців, кожен стовпець - varchar (100), а кодування - UTF-8, то я можу здогадуватися в гіршому випадку, що у вас є 4 000 байт, варті даних у рядку, і додайте ще кілька байт для метадані так дозволяють сказати 4200 байт?

Ваш SQL тортур обчислює 4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytesдані, записані на диск

42 000 000 000 000/1000 = 42 000 000 000 Кб

42 000 000 000/1000 = 42 000 000 МБ

42 000 000/1000 = 42 000 ГБ

42 000/1000 = 42 ТБ

За цього теоретичного найгіршого сценарію ви запишете 42 ТБ на диск

Згідно з цією статтею , наданою @KronoS, ви повинні мати ще близько 25 раундів вашого SQL-катувань.

Як говорив афіш цього запису на SSD , те, що справді шкідливо, - це знову і знову записувати невеликі шматки даних.

• біти зберігаються в {1,2,3} -бітових клітинках. Вони мають обмежений термін експлуатації.
• комірки групуються на [2-16] КБ сторінок (найменша одиниця для запису)
• сторінки згруповані в (128-256 сторінок) блоки (найменша стерта одиниця)
• щоб сторінка була перезаписана, її --- і весь її блок --- потрібно стерти спочатку

Ось чому рекомендується

• ніколи не пишіть менше сторінки одразу,
• буфер малих записів, і
• окремі запити для читання та запису
• "Велике однопотокове записування краще, ніж багато малих одночасних записів"

Отже, дійсно велика сума відразу здається набагато кращою.