Планування ємності диска та оперативної пам’яті
Планування ємності диска та пам'яті для сервера баз даних - це чорне мистецтво. Більше - краще. Швидше - краще.
Як загальні рекомендації я пропоную наступне:
- Ви хочете більше дискового простору, ніж вам БУДЕ ВСЕ .
Отримайте найкращу оцінку того, скільки дискового простору вам знадобиться протягом наступних 3-5 років, а потім подвойте його.
- Вам потрібно буде достатньо оперативної пам’яті, щоб зберігати в пам’яті індекси вашої бази даних, обробляти ваш найбільший запит хоча б два рази, і ще залишається достатньо місця для здорового кешу диска ОС.
Розмір індексу залежить від вашої бази даних, а все інше сильно залежить від вашого набору даних та запиту / структури бази даних. Я запропоную "Принаймні в 2 рази розмір вашої найбільшої таблиці" як пропозицію, але зауважте, що ця пропозиція розбивається на дійсно великі операції зберігання даних, де найбільша таблиця може становити десятки або сотні гігабайт.
У кожного постачальника баз даних є кілька інструкцій щодо налаштування продуктивності вашого диска / пам'яті / ядра ОС - Проведіть деякий час з цією документацією до розгортання. Це допоможе.
Аналіз робочого навантаження та планування потенціалу
Припустимо, що ви ще не розгорнули ...
Багато систем баз даних постачаються за допомогою інструментів Benchmarking Tools - наприклад,
PostgreSQL постачається за допомогою
pgBench .
Ці інструменти повинні стати вашою першою зупинкою в роботі баз даних бенчмаркінгу. Якщо це можливо, слід запустити їх на всіх нових серверах баз даних, щоб відчути, як багато може працювати сервер баз даних.
Озброївшись тепер сировинним орієнтиром, який ABSOLUTELY MEANINGLESSрозглянемо більш реалістичний підхід до тестування: Завантажте схему бази даних і напишіть програму, яка заповнює її фіктивними даними, а потім запустіть запити вашої програми проти цих даних.
Цей орієнтир містить три важливі речі: 1. Сервер бази даних (апаратне забезпечення) 2. Сервер бази даних (програмне забезпечення) 3. Дизайн вашої бази даних та спосіб її взаємодії з (1) та (2) вище.
Зауважте, що для цього потрібно набагато більше зусиль, ніж прості заздалегідь складені орієнтири, такі як pgBench: Вам потрібно написати якийсь код, щоб виконати заселення, і вам може знадобитися написати якийсь код, щоб виконати запити та час виконання звіту.
Цей вид тестування також істотніше точний: оскільки ви працюєте зі своєю схемою та запитами, ви можете побачити, як вони будуть працювати, і це пропонує вам можливість профайлювати та вдосконалити вашу базу даних / запити.
Результати цих орієнтирів - це ідеалізований вигляд вашої бази даних. Для надійності припустіть, що ви досягнете лише 50-70% цієї продуктивності у виробничому середовищі (решта - це подушка, яка дозволить вам впоратися з несподіваним зростанням, збоями обладнання, зміною навантаження тощо).
Це дуже пізно! Це у виробництві!
Після того, як ваші системи на виробництві, насправді занадто пізно для "орієнтування" - Ви можете коротко ввімкнути журнал запитів / хронологію запитів і побачити, скільки часу потрібно виконувати, і ви можете запускати деякі "стрес-тести" запити проти великих наборів даних під час вимкнення годин. Ви також можете переглянути використання процесора, оперативної пам’яті та вводу / виводу (пропускна здатність диска), щоб отримати уявлення про те, наскільки сильно завантажений він.
На жаль, всі ці речі зроблять це уявлення про те, що робить система, і розпливчасту концепцію того, наскільки вона близька до насичення.
Це приводить нас до ...
Постійний моніторинг
Усі орієнтири у світі не допоможуть вам, якщо ваша система раптом побачить нові / різні схеми використання.
Для кращого або гіршого розгортання бази даних не є статичними: ваші розробники змінитимуть ситуацію, ваш набір даних зростатиме (вони ніколи не скорочуватимуться), а ваші користувачі якось створюватимуть божевільні комбінації подій, яких ви ніколи не прогнозували при тестуванні.
Для правильного планування потужностей для вашої бази даних вам потрібно буде впровадити певний моніторинг продуктивності, щоб повідомити вас про те, коли продуктивність бази даних вже не відповідає вашим очікуванням. У цей момент ви можете розглянути коригувальні дії (нове обладнання, схема БД або зміни запитів для оптимізації використання ресурсів тощо).
Примітка. Це дуже високий рівень та загальне керівництво щодо розміру апаратних засобів вашої бази даних та з'ясування того, скільки зловживань це може спричинити. Якщо ви все ще не впевнені в тому, як визначити, чи відповідає конкретна система вашим потребам, вам слід поговорити з експертом із бази даних.
Також є сайт Stack Exchange, спеціально призначений для управління базами даних: dba.stackexchange.com . Шукайте в архіві запитань або перегляньте теги, характерні для вашої системи баз даних, щоб отримати подальші поради щодо настройки продуктивності.