Лучший VPS для базы данных: конфигурация под вашу нагрузку

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

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

Оцените нагрузку базы до выбора тарифа

До выбора CPU, RAM и диска измерьте активные данные и индексы, одновременные запросы в пике, рост и требования восстановления. Добавляйте ресурсы по измеренному ограничению. Учтите обслуживание и пик приложения на общем сервере; бюджет должен выдерживать обычные и загруженные периоды.

Рабочий набор — данные и индексы, используемые достаточно часто, чтобы выигрывать от RAM. Сохранённый объём включает холодные записи. Открытые соединения — не активные запросы: простаивающие клиенты и одновременные сортировки требуют разных CPU и RAM. Запишите оба показателя, форму запросов и соотношение чтения/записи.

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

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

Документация мониторинга PostgreSQL рекомендует сочетать статистику базы с утилитами ОС. Измеряйте CPU, давление памяти и диск вместе со временем запросов и фиксации. Рост задержки при резервировании требует проверки, даже если сервер без нагрузки выглядит исправным.

Выделенные vCPU дают постоянный доступ к назначенному CPU, но не целый физический сервер и не гарантию IOPS. Оценивайте CPU, память и поведение диска отдельно. Если измеренные требования превышают доступные 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 может подойти терпимой тестовой среде. Выберите выделенный, если длительная конкуренция портит отклик; далее производственные тарифы используют только выделенные vCPU.

Предлагаемый бюджет RAM, все числа в ГБ:

Впишите пул InnoDB MySQL/MariaDB в этот бюджет. Процент для выделенной базы, применённый ко всему серверу, съест память приложения. Для PostgreSQL отдельно учитывайте общие буферы и память операций внутри бюджета и резерва базы. Измерьте суммарный пик перед принятием любого варианта.

Пример диска: 5 ГБ ОС/логи, 3 ГБ данные/индексы, 4 ГБ журналы движка, 3 ГБ временно и 6 ГБ рост — всего 21 ГБ. Остаток покрывает накладные расходы файловой системы и временную работу, а не оправдывает хранение резервов на основном сервере.

Подключайтесь через локальный сокет или localhost. Проверяйте устойчивые фиксации с работающими приложением и резервированием, включая синхронизацию (fsync), которая просит ОС записать данные на постоянный носитель. Если владелец принимает RPO 24 часа — окно потерь — и RTO четыре часа — цель восстановления, предложите ночную штатную копию вне узла и докажите срок тренировкой. При превышении памяти, задержки или восстановления разделите, увеличьте либо пересмотрите проект после диагностики запросов/индексов.

Отделите транзакционную SQL-базу

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

Предположим чтение/запись 90/10 и рост 1 ГБ ежемесячно три месяца. Это эталон таблицы провайдеров. Единицы различаются: сравните реальную память и доступные байты файловой системы до распределения.

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

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

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

MariaDB требует иного расчёта. Её руководство по памяти начинает преимущественно InnoDB с 60–70% RAM после ОС/служб. При доступных 13 ГБ это 7,8–9,1 ГБ; начальные 8 ГБ подходят. MyISAM или Aria требуют отдельного кеша. Это альтернативные бюджеты, не складывайте их.

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

Расположите приложение рядом с базой, с проверенным частным путём при поддержке, аутентификацией, контролем доступа и шифрованием. Проверьте задержку запросов и устойчивой фиксации при checkpoints, сбросах и копиях. Выделите независимое хранилище копий; ниже оно раскрыто. Увеличивайте при насыщении, нехватке места или несоблюдении восстановления после диагностики запросов/индексов.

Заложите большие рабочие наборы или постоянную запись

Для предполагаемых 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, слабом резерве или заполнении хранилища.

Когда выбирать управляемый 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 выбираются отдельно; один выбор не установит все три. Исправления, настройка и восстановление остаются вашей обязанностью.

Часто задаваемые вопросы