Який сервер вибрати для зберігання баз даних

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

Розуміння робочого навантаження

Перш ніж дивитися на технічні характеристики, вам потрібно знати, що буде обробляти ваш сервер. Транзакційна база даних (така як MySQL або PostgreSQL, що працює в бекенді електронної комерції) має інші потреби, ніж великомасштабне аналітичне сховище даних (таке як ClickHouse або Snowflake).

Для транзакційних систем абсолютно критичні низька затримка дискового вводу-виводу і швидка реакція ЦП — кожна мілісекунда має значення, коли користувачі чекають результатів пошуку або обробки замовлення. Аналітичні системи часто обробляють величезні пакетні запити, а це означає, що їм потрібні великі кеші ОЗУ, широкий паралелізм і висока пропускна здатність сховища, а не просто низька затримка.

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

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

Міркування щодо процесора

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

PostgreSQL може розпаралелювати деякі запити, але все одно часто виконує багато операцій в одному потоці. Тут може бути помітна різниця між процесорами з більш високою тактовою частотою на ядро. Прикладами можуть служити моделі AMD EPYC «високої частоти» і Intel Xeon Gold з технологією Turbo Boost. З іншого боку, робочі навантаження OLAP або обробка великих даних можуть масштабуватися на десятки потоків. Тому більш економічним рішенням буде вибір процесорів з великою кількістю ядер і трохи меншою тактовою частотою на ядро.

Не нехтуйте розміром кешу. Більш об'ємний кеш L3 підвищить продуктивність при повторюваних запитах або наборах «гарячих» даних, які частково поміщаються в пам'ять. Сучасні процесори також включають спеціальні інструкції, такі як AVX-512, які деякі движки баз даних можуть використовувати для прискорення операцій.

Пам'ять (RAM)

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

Тип оперативної пам'яті також має значення. DDR4 як і раніше залишається поширеним і економічним варіантом, але DDR5 з'являється в нових серверних платформах, забезпечуючи більш високу пропускну здатність і меншу затримку. Оперативна пам'ять з ECC (кодом виправлення помилок) необхідна для серверів баз даних. Тихе пошкодження пам'яті відбувається рідко, але може повністю зруйнувати цілісність даних, тому відмова від ECC не є варіантом.

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

Інші статті на тему адміністрування БД у нашому Блозі:

    - Створення нового користувача та управління привілеями у MySQL

    - Як налаштувати просте резервне копіювання PostgreSQL

    - Додавання нового користувача в PostgreSQL

    - Детальний посібник: як знайти та оптимізувати повільні запити у MySQL

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

Сховище є основним джерелом проблем з продуктивністю серверів баз даних. Обертові жорсткі диски прийнятні тільки для архівного зберігання або зберігання рідко використовуваних даних. Всі активні дані повинні зберігатися на SSD-накопичувачах. Використовуйте SSD-накопичувачі корпоративного класу NVMe з високим показником довговічності і стабільною затримкою.

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

Конфігурації RAID — найкращий спосіб збалансувати швидкість і надмірність. RAID 10 (чергування + дзеркалювання) — найкращий вибір для балансу продуктивності та відмовостійкості. Якщо ви використовуєте RAID 5 або 6, майте на увазі, що, хоча вони економлять місце, час відновлення після збою диска може бути небезпечно довгим для великих дисків.

Ще одним важливим фактором є стійкість до запису. Бази даних часто піддаються інтенсивним навантаженням запису, особливо при регулярній реєстрації транзакцій. Вибирайте SSD з більш високим показником DWPD (Drive Writes Per Day, кількість записів на диск в день), щоб уникнути передчасного виходу дисків з ладу.

Мережа та підключення

Якщо до сервера бази даних віддалено підключаються сервери додатків або користувачі, вирішальне значення мають пропускна здатність мережі та затримка. Для внутрішніх підключень в межах одного центру обробки даних для багатьох робочих навантажень часто достатньо 1 Гбіт/с. Однак для аналітичних запитів з великим обсягом даних або реплікації між серверами варто розглянути мережеві інтерфейси 10 Гбіт/с або навіть 25 Гбіт/с.

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

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

VPS, виділений сервер або хмара

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

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

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

Гібридний підхід полягає в запуску бази даних на потужному виділеному сервері (або високопродуктивному VPS) і використанні хмари для резервного копіювання, реплікації або винесення аналітики.

Висновок

Не існує універсальної відповіді на питання «Який сервер вибрати для зберігання бази даних?». Найкращий вибір залежить від ваших моделей робочих навантажень, очікувань зростання та бюджету. Незалежно від того, що ви оберете — високочастотний VPS, виділений сервер або гібридну конфігурацію — ви повинні зіставити можливості вашого обладнання з фактичним робочим навантаженням бази даних. Це ключ до забезпечення безперебійної та ефективної роботи додатка, що відрізняє його від тих, які стикаються з проблемами продуктивності.