Найкращий VPS для баз даних: конфігурація під ваше навантаження

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

Некерований VPS означає відповідальність за роботу бази. PostgreSQL, MySQL і MariaDB потребують різних бюджетів пам'яті; відновлення слід проєктувати разом з основним сервером. Початкова конфігурація має залишати запас для копій і обслуговування та пройти типовий тест навантаження.

Оцініть навантаження бази до вибору тарифу

Перед вибором CPU, RAM і диска виміряйте активні дані та індекси, паралельні запити в піку, зростання й вимоги відновлення. Додавайте ресурси за виміряним обмеженням. Врахуйте обслуговування й пік застосунку на спільному сервері; бюджет має витримувати звичайні та завантажені періоди.

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

Сформуйте вимоги за типовим завантаженим періодом:

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

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

Виділені vCPU дають постійний доступ до призначеного CPU, але не цілий фізичний сервер і не гарантію IOPS. Оцінюйте CPU, RAM та поведінку диска окремо. Якщо вимоги перевищують VPS, дослідіть виділене обладнання, а не робіть висновки з назви більшого тарифу.

Доберіть початкову конфігурацію до SQL-навантаження

Використовуйте PostgreSQL 16, MySQL 8.4 з InnoDB або MariaDB 11.4 з InnoDB як альтернативні приклади за сумісністю. Рушії не взаємозамінні й не заявлені як найновіші. Перед тестом запишіть версію виправлення; приклади не задають версію образу провайдера.

Розмістіть малий застосунок і базу разом

Для припущених 3 ГБ даних, 1 ГБ гарячого набору й п'яти активних простих індексованих запитів тестуйте 2 vCPU, 4 ГБ RAM і номінальні 60 ГБ SSD/NVMe. З'єднання локальне, але застосунок і база мають разом укладатися в пік пам'яті.

Припустімо читання/запис 90/10, приріст 1 ГБ щомісяця й відсутність довгих звітів під час копій. Спільний CPU може підійти терпимому staging. Оберіть виділений, якщо тривала конкуренція погіршує відгук; виробниче порівняння нижче використовує лише виділені vCPU.

Запропонований бюджет RAM, усі числа в ГБ:

Впишіть пул InnoDB MySQL/MariaDB у бюджет. Відсоток для виділеної бази, застосований до всього сервера, забере RAM застосунку. У PostgreSQL окремо врахуйте спільні буфери й пам'ять операцій у частці та резерві бази. Виміряйте спільний пік перед прийняттям будь-якого варіанта.

Приклад диска: 5 ГБ ОС/журнали, 3 ГБ дані/індекси, 4 ГБ журнали рушія, 3 ГБ тимчасово й 6 ГБ зростання — разом 21 ГБ. Решта покриває накладні витрати файлової системи й тимчасові роботи, а не виправдовує зберігання копій на основному сервері.

Під'єднуйтеся локальним сокетом або localhost. Тестуйте стійкі фіксації з активними застосунком і копіюванням, включно із синхронізацією (fsync), яка просить ОС записати на постійний носій. Якщо власник приймає RPO 24 години — вікно втрати — і RTO чотири години — ціль відновлення, запропонуйте нічну штатну копію поза вузлом і доведіть час тренуванням. За перевищення RAM, затримки чи відновлення розділіть, збільште або змініть проєкт після діагностики запитів/індексів.

Відокремте транзакційну SQL-базу

За віддаленого застосунку приклад із 12 ГБ SQL і 6 ГБ гарячого набору можна почати тестувати на 2 виділених vCPU, RAM класу 16 ГБ і локальному диску класу 50 ГБ. Припущення: 20 активних індексованих запитів, короткі записи й небагато тривалих обчислень; важчі операції можуть порушити бюджет.

Припустімо читання/запис 90/10 і зростання 1 ГБ щомісяця три місяці. Це еталон таблиці. Одиниці різні: порівняйте фактичну RAM і доступні байти файлової системи до розподілу.

Для PostgreSQL VPS настанови зі спільних буферів PostgreSQL 16 починають із 25% RAM виділеного сервера бази з принаймні 1 ГБ. PostgreSQL використовує й кеш ОС. Пропозиція 16 ГБ: 4 ГБ буфери, 2 ГБ ОС/агенти, 2 ГБ резерв запитів/з'єднань/обслуговування й 8 ГБ файловий кеш/запас.

Резерв — не значення work_mem. Документація пам'яті операцій запиту PostgreSQL пояснює, що окремі сортування й хеші за кількох сеансів можуть кожні виділяти RAM. Хеші використовують і hash_mem_multiplier. Обмежуйте за дозволеною паралельністю; високі значення на операцію можуть перевищити сервер навіть із достатніми буферами.

Для MySQL VPS настанови пулу буферів MySQL 8.4 Oracle зазвичай радять 50–75% RAM з урахуванням ОС та інших часток. Тестуйте 8 ГБ InnoDB, залишаючи решту іншим і пікам.

MariaDB потребує іншого розрахунку. Її настанови з пам'яті починають переважно InnoDB із 60–70% RAM після ОС/служб. За 13 ГБ це 7,8–9,1 ГБ; початкові 8 ГБ підходять. MyISAM або Aria потребують окремого кешу. Бюджети альтернативні, не додавайте їх.

Диск: 12 ГБ дані/індекси + 3 ГБ зростання + 5 ГБ ОС + 4 ГБ журнали + 8 ГБ тимчасово/обслуговування = 32 ГБ. Диск 50 ГБ залишає близько 18 ГБ номінально до накладних витрат. Вимагайте мінімум 15 ГБ виміряного вільного місця; більші журнали або переписування порушать приклад.

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

Закладіть більші робочі набори або постійний запис

Для припущених 100 ГБ даних і 16 ГБ гарячого набору тестуйте 4 виділені vCPU, 32 ГБ RAM і NVMe класу 300 ГБ з окремим застосунком. Приклад допускає 30 активних змішаних запитів і читання/запис 60/40; виміряйте обчислення та диск перед збільшенням.

Припустімо приріст 10 ГБ щомісяця три місяці. PostgreSQL: 8 ГБ буфери, 4 ГБ ОС/запити/обслуговування, 20 ГБ файловий кеш/запас. Для MySQL/MariaDB близько 16 ГБ InnoDB — альтернатива після інших резервів. Параметри PostgreSQL не переносяться.

Диск містить поточну роботу: 100 ГБ дані/індекси + 30 ГБ зростання + 30 ГБ збережені/очікувані журнали + 60 ГБ найбільша тимчасова/сервісна операція + 10 ГБ ОС = 230 ГБ. Лишається близько 70 ГБ номінально. Більше переписування вимагає перерахунку навіть за скромного денного приросту.

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

Міряйте CPU, тиск кешу та фізичний I/O окремо від затримки запису. Включіть тимчасові записи й періоди checkpoint/скидання. NVMe та виділений CPU — опис, не гарантія IOPS. Тестуйте сталі передачі копій і реплікації з близьким приватним шляхом та незалежним сховищем. Швидші журнали змінюють ретенцію й мережу. Додавайте ядра, RAM або диск за обмеженням, не тому, що наступний тариф збільшує все.

Додайте можливості відновлення у виробничій системі

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

Документація безперервного архівування PostgreSQL описує базову копію й безперервний WAL для відновлення на момент часу. Документація відновлення MySQL Oracle використовує повну копію та бінарні журнали. Процедура PITR MariaDB відновлює повні/інкрементні дані до відтворення журналів. Для цих шляхів MySQL/MariaDB слід увімкнути бінарне журналювання.

Приклад: кожна нестиснена повна/базова копія має 12 ГБ. Зберігайте три тижневі бази й безперервні журнали від початку найстарішої. Закладіть до 21 дня по 2 ГБ щодня й запас 20%:

(3 × 12 + 21 × 2) × 1.2 = 93.6 GB

Плануйте мінімум 100 ГБ незалежних копій без припущення стиснення. Пов'язуйте видалення журналів зі строком і успішною заміною копій. Перевіряйте повний ланцюг для кожної обіцяної точки.

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

Коротший простій може вимагати незалежної репліки для повного навантаження. Окремо розрахуйте CPU, RAM і диск; визначте підвищення, ізоляцію старого основного й маршрутизацію. Відрепетируйте. Реплікація не замінює копій; один VPS — не висока доступність. Перегляньте при відновленні понад годину, затримці архіву понад RPO, слабкому standby чи заповненому сховищі.

Коли обирати керований VPS

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

Різниця між обов'язками керованого й некерованого VPS корисна для кожного завдання. Це закупівельний список, не обіцянка однакових послуг. Фізична інфраструктура лишається провайдеру; гостьове ПЗ й база потребують явного відповідального.

Корисне договірне питання: «Якщо під час копії скінчиться диск, хто діагностує, відновить службу й перевірить наступну копію?» Воно відрізняє доступ до підтримки від відповідальності за результат. Запитайте й про невдале оновлення та випадкове видалення.

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

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

Оберіть VPS для навантажень поза SQL

Приклади розділяють пам'ять, документи й пошукові індекси. Наблизьте застосунок і перевірте зв'язок та передачі до копій і використаних реплік.

Посібник адміністрування Redis попереджає, що збереження RDB або переписування AOF з інтенсивним записом може потребувати до подвійної RAM залежно від змінених сторінок. Тому 2 ГБ не можуть зайняти все. Документація збереження відрізняє періодичні знімки RDB від AOF. Обирайте за допустимою втратою й вимірюйте піки RAM/диска під час роботи.

Документація кешу WiredTiger MongoDB описує внутрішній та файловий кеші. Типово береться більше з 50% × (RAM − 1 ГБ) і 0,256 ГБ. Настанови replica set радять три вузли з даними. Арбітр голосує, але не зберігає даних. Виділіть незалежні копії й увімкніть автентифікацію MongoDB до під'єднання застосунку.

Документація параметрів JVM Elastic радить автоматичний heap. Вручну задайте однакові мінімум/максимум і не більш як 50% доступної RAM. Настанови стійкості малих кластерів описують два вузли даних, придатні бути master, і лише голосувальний третій. Налаштуйте репліки та клієнтів на вузли даних; третій додає голос, не копію. Якщо злиття/ретенція вичерпали запас, перерахуйте диск до нових документів.

Порівняйте самостійні тарифи для потрібної конфігурації

Для окремого транзакційного SQL відбирайте мінімум 2 виділені vCPU, RAM класу 16 ГБ і 50 ГБ локально. Мінімум робить тариф кандидатом на тест. Різні комплекти, одиниці й зобов'язання не дають рівності обладнання чи рейтингу швидкості.

Еталон — самостійний Linux у Німеччині або близькій Центральній Європі, мало даних і більше RAM. Близькість не означає однакової затримки. Приватний шлях за підтримки; ціни зберігають стандартну публічну IPv4. Передачу припущено нижче всіх лімітів.

Документація вибору DigitalOcean називає Memory-Optimized для SQL/NoSQL і кешів. Рекомендую комплект для малого диска й великої RAM. Оптимізація пам'яті не обмежує VPS лише SQL. Якщо виміри показують місткість чи постійний попит диска, оцініть Storage-Optimized окремо.

Усі п'ять відповідають мінімуму з різним запасом CPU/диска. Він може підтримати зростання, але не доводить швидкість без тесту. Каталог Hetzner не гарантує наявності для замовлення. Akamai вказує SSD для G7 Dedicated. Vultr Optimized Memory відрізняється від спільного High Frequency Compute.

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

Вартість володіння: обчислення + адреса + незалежне сховище/запити/передача копій + ресурс тестів відновлення + необов'язковий standby. Невідома плата — не нуль. Отримайте поточні ціни відновлення й перевірте тариф, місце та розширення до зобов'язань. Не виводьте річний рахунок множенням округленого місячного еквівалента.

Після вибору сумісного SQL-рушія наші застосунки в один клік скорочують установку. PostgreSQL, MySQL і MariaDB обираються окремо; один вибір не встановить усі три. Виправлення, налаштування й відновлення лишаються вам.

Часто задавані питання