Для підвищення продуктивності SQL, чому б просто не поставити багато оперативної пам’яті, а не мати швидші жорсткі диски?

Люди постійно говорять мені, що для покращення продуктивності сервера SQL купуйте найшвидші жорсткі диски, можливі з RAID 5 тощо.

Тож я думав, замість того, щоб витратити всі гроші на RAID 5 і супер-пупер швидкі жорсткі диски (що, до речі, не дешево), чому б просто не отримати тонни оперативної пам’яті? Ми знаємо, що сервер SQL завантажує базу даних в пам'ять. Пам'ять швидше, ніж будь-які жорсткі диски.

Чому б на сервері не заповнити 100 Гб оперативної пам’яті? Тоді просто використовуйте звичайний жорсткий диск SCSI з RAID 1. Хіба це не буде набагато дешевше і швидше?

Ваш аналіз чудово - до певної міри - тим, що він абсолютно зробить все швидше. Однак вам доведеться пояснити ще кілька проблем:

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

2. Ефективність запису для вашої бази даних все ще буде обмежена дисками, так що ви можете дотримуватися обіцянки, що дані фактично зберігалися.

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

(Окрім того, люди, які говорять вам про те, щоб використовувати RAID-5 для роботи бази даних, напевно, не великі люди, щоб слухати цю тему, оскільки це майже ніколи не найкращий вибір - це хороша продуктивність читання, але погана продуктивність запису, і пише майже завжди є виробничим обмеженням - оскільки ви можете кинути оперативну пам’ять у кешування, щоб вирішити більшість проблем, пов'язаних з читанням.)

Коротка версія: врахуйте розмір робочого набору. Довга версія: Наскільки великі ваші дані? Якщо це може вписатися в пам'яті сучасного сервера, так, ви абсолютно праві. На жаль, найбільший Xeon зараз може адресувати 2 Тб оперативної пам’яті, і це вже не такий великий набір даних. Якщо ви не можете придбати машину, достатньо велику, щоб розмістити весь робочий набір в оперативній пам’яті, ви змушені вирішувати проблеми з мозком, а не з гаманцем.

Якщо ви хочете швидкості:

• Збільшити оперативну пам’ять, щоб принаймні часто використовувані індекси могли повністю вміститися в оперативній пам’яті (наприклад, у системі, над якою я працюю, 32 ГБ оперативної пам’яті достатньо для бази даних 350 ГБ, тому що індекси - це те, що вам потрібно в оперативній пам’яті, а не необроблені дані)
• Використовуйте RAID10 з будь-якими дисками (швидші диски краще)
• Уникайте RAID5
• Розділіть mdf, ldf та temp БД на дискретні набори шпинделів (наприклад: tempdb на власному наборі RAID1, ldf на власному наборі шпинделів RAID1 або RAID10, mdf на набір RAID 10 з принаймні 4 дисками)

Виконайте ці кроки, і SQL Server пролетить.

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

ОЗУ - це новий диск, диск - нова стрічка.

В http://www.tbray.org/ongoing/When/200x/2006/05/24/On-Grids . Зауважимо, це було шість років тому. Так, у нас є системи баз даних, які намагаються (і намагаються) зберегти весь набір даних в оперативній пам'яті і скоріше поділити їх на декілька машин, ніж використовувати диск, оскільки диск у будь-якому разі збільшується повільніше. Вам потрібно виписати набір даних на диск, але, як у вищезгаданому девізі, це більше схоже на завдання заднього резервного копіювання, ніж операції в Інтернеті. Міцність досягається за допомогою додавання лише журналів із цими базами даних (я думаю, MongoDB та Redis, але є тонни більше).

Це питання схоже на основне, що призвело до багатьох досліджень та розробок у архітектурі баз даних за останні 5-10 років. Тепер, коли можливо зберігати всю базу даних в оперативній пам’яті для багатьох випадків використання, базу даних потрібно розробити навколо роботи в оперативній пам’яті, а не просто застосування старих успадкованих архітектур до пам’яті на основі оперативної пам’яті.

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

Для подальшого ознайомлення з цією темою я рекомендую науковий документ «Кінець архітектурної епохи» (час для повного переписування) . Читати це не складно.

Незрозуміло, чи стосувалося це питання спеціально щодо SQL Server. Оригінальний плакат повинен це прояснити.

Даніель Пітман написав:

Якщо у вас є невеликий набір даних або вам не потрібно зберігати їх на диску, нічого поганого з вашою ідеєю немає. Такі інструменти, як VoltDB, працюють над тим, щоб зменшити накладні витрати, які були зроблені в старих припущеннях> в реалізаціях RDBMS, які обмежують чисту продуктивність в пам'яті.

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

Якщо ви зможете отримати сервер з достатньою кількістю оперативної пам’яті, принаймні, гарячою частиною вашого набору даних, ви будете добре. Крім того, RAID 1 і 5 - це не найшвидший спосіб упорядкувати свої дані - RAID 0 швидше, але, значить, доведеться враховувати більш високі шанси несправності файлової системи, яка стирає вашу базу даних - це не приємно. . Ви можете RAID 1 або RAID 5 у своєму масиві RAID 0 за умови, що у вас є достатня кількість накопичувачів та контролерів.

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

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

Це випадок "залежить від того, що ти робиш". Можливо, "правильною" порадою є взагалі уникати SQL та використовувати memcache / redis / тощо!

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

Однак продуктивність диска часто є вузьким місцем на серверах SQL і складніше, ніж інші речі, такі як ОЗУ, щоб оновити пізніше (якщо у вас є сервер, який не повністю заповнений DIMM).

Було багато коментарів про те, що RAID5 повільний, але я б сказав, що це не завжди так, тому будьте обережні, перш ніж робити чіткі заяви. Дійсно сервери високого класу зі швидкими картами RAID та безліччю BBWC іноді в RAID5 (або RAID50 з> 4 дисками) йдуть набагато швидше, ніж у RAID10 ...

Протягом багатьох років я особисто відчував повільні масиви RAID5, але після порівняльної оцінки DL360 G5 з 4 дисками 146G SAS у ~ 2009 році нам довелося двічі перевірити наші тести. Дійсно, масив пройшов швидше з RAID5, ніж RAID10 майже в кожному тесті. BBWC і швидкі розрахунки паритету дозволили серверу можна використовувати 4 диски набагато ефективніше як масив RAID5, ніж RAID10. Деякі тести показали на 50% кращу пропускну здатність з RAID5, а майже жоден не був повільнішим. Тести, які були повільнішими, були лише на 5-10%.

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

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

1. БД матимуть конфігурацію для кешування запитів та місця, де існує цей кеш, пам'яті чи жорсткого диска.
2. RAID 5 не завжди найшвидший, але RAID 0 (JBOD) - смуга і швидкий, оскільки RAID 5 - також смуга, ідея майже однакова.
3. RAID 1 не покращить вашу швидкість, це лише дзеркало.
4. Продуктивність SQL заснована на індексації, і це перше, що потрібно перевірити. Дуже важливий у реляційних базах даних.
5. Не індексуйте все, переоцінка може також знизити швидкість, оскільки ваша індексація перевантажена.
6. Іноді при SQL Joins база даних стає повільнішою. Використання програмування для циклу набору мінімальних індексованих результатів покращує швидкість.
7. Віртуальні сервери - це кошмар швидкості, якщо ви не платите долари.

Просто покладіть гроші на знання (безкоштовно), перш ніж розвантажувати готівку. 1. Вивчіть конфігурації вашої бази даних та перегляньте поточну конфігурацію для оптимізації. 2. Подивіться на оператори програмування та sql, тестовий блок з простими сценаріями, що імітують залучені операції, можливо, це навіть не те, що, на вашу думку, є проблемою. Якщо прості сценарії займають час за допомогою SQL Joins, розділіть його і зробіть те саме, що і програмований цикл, щоб зробити те саме. Ось ця пам'ять може допомогти 3. Подивіться план хостингу та сервер. Використовуйте ps aux в консолі Linux і подивіться, чи щось всмоктує вашу пам'ять і процесор.

Абсолютний жорсткий диск підвищує швидкість, але це не залежить від вас у віртуальному серверному просторі. Пам'ять не покращує швидкість, якщо ви не налаштовуєте для неї послуги, періодично. У цьому допомагає смугастий RAID (0,5), RPM та синхронне читання / запис із швидкою шиною. Основний процесор з хорошим кешем l1, l2, l3 допоможе обробити вузьке місце. чи можу я почути це для Xeon!

Загалом ви повинні пам’ятати про розмір та масштабованість. Хоча вам може здатися, що ви починаєте з невеликих потреб у сховищі, ваші дані будуть рости дуже швидко та експоненціально. БД найкраще використовувати атомні дані, це дані, розбиті на найменший можливий розмір. Через невеликий розмір він швидше подорожує всередині сховища даних. Потім ви також враховуєте структуру БД. Надалі ви можете зв’язатися із зовнішніми базами даних, тому структура також має вирішальне значення. У цьому випадку мало б мало значення для вашого запиту, якщо половина даних знаходиться поза вашим даним даних. Коли дані запитуються, справа не в тому, щоб зберігати збережені дані в ОЗУ; швидше, запит повинен бути швидким у доступі та поверненні даних.

• Ви дійсно не завжди використовуєте RAID 5 для даних. Це залежить від даних та його важливості, окрім того, що раніше згадувалося про резервні копії. RAID 1 можна використовувати і є.
• Вам потрібно буде оновити всі сервери в межах вашого діапазону запитів, щоб підвищити швидкість. Оскільки велика частина даних знаходиться поза вашим контролем, вона збирається вузьким місцем десь поза вашим даним даних. (У випадку, якщо ви оновите свій власний)