Чи має поява SSD якийсь вплив на оптимізацію бази даних?

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

Так, вони змінюють гру. Оптимізація на основі характеристик обертових магнітних дисків (наприклад, час пошуку та затримка обертання ) може не мати значення для накопичувачів SSD. Нещодавній документ ^*, опублікований у FITME 2010, представляє один новий алгоритм оптимізації запитів на основі характеристик SSD.

Однак ці зміни, ймовірно, будуть зміни на низькому рівні (наприклад, в алгоритмах зберігання та пошуку), які можуть ефективно реалізуватися розробниками баз даних. Вони, ймовірно, не вплинуть на користувачів бази даних так сильно.

^* IEEE Xplore - Орієнтована на стовпці оптимізація запитів на зберігання для флеш-бази даних

Продуктивність

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

Довговічність

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

Загальне зниження ціни на зберігання має набагато глибші наслідки.

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

Бази даних SQL набагато менш ефективні. Але тепер, коли диски дешеві, величезні та швидкі, нас ледь не хвилює.

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

Поліпшення продуктивності SSD, ймовірно, втратяться в результаті змін, спричинених використанням баз даних NoSQL, до того, як ми плануємо системи в цілому.

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

SSD мають деякі недоліки щодо записів:

• Мінімальний розмір запису в блоці близько 4-8 КБ.
• Записи можна виконувати лише на основі повної сторінки, яка зазвичай становить 256 КБ.
• На них можна записувати лише порожні блоки.

Типовий сценарій кошмару, який називається посиленням запису , - це коли ви хочете записати один байт у місце розташування на диску, у якому вже є деякі блоки. Для того, щоб записати туди, потрібно спершу скопіювати всю пам'ять у 256 КБ в пам'ять, стерти весь блок, змінити один байт на сторінці, а потім записати всю змінену сторінку 256 КБ. Тож для того, щоб написати єдиний байт, було близько половини мегабайт "трафіку"!

Існує маса оптимізацій для цієї проблеми, реалізованих на рівні SSD, контролера та навіть операційної системи, але, безсумнівно, СУБД можуть отримати користь, адаптувавши ці оптимізації до їх конкретної роботи.

Однак це не те, про що потрібно думати користувачам бази даних (як, наприклад, використання бази даних у їх застосуванні), оскільки це буде сильно залежати від рішень щодо проектування / впровадження на рівні СУБД.

З того, що я збираю з блогу ServerFault , сервери баз даних повинні мати чітке обладнання. Сервер баз даних сайтів обміну стеками працює з SSD (див. Http://blog.serverfault.com/post/our-storage-decision/ ), і я думаю, що оптимізація запитів все ще дуже потрібна. CPU і пам'яті будуть порушені запитами до бази даних, а також введення - висновок.

Однак продуктивність баз даних багато в чому залежить від IO, тож SSD, безумовно, допоможе.

Так, з причин, які всі заявили.

Я слухав подкаст, в якому говорили, що великі шматки RDBMS, такі як Oracle, SQL Server тощо, почнуть "вибиратися", якщо вони зможуть правильно розробити поділ. Визначте, чи є його накопичувач SSD, та оптимізуйте відповідно.

Для кешування та запису даних існує багато додаткового коду, який просто більше не потрібен.

Ще цікавіше - це RAMSAN та його варіанти. В основному жорсткий диск, виготовлений з мікросхем оперативної пам’яті з вбудованим X-годинним ДБЖ та можливістю фонового запису на довгострокове зберігання жорсткого диска.