Когда сайт или приложение начинает расти, рано или поздно появляется идея вынести базу данных на отдельный сервер. Звучит логично: приложение работает на одном VPS, MySQL или PostgreSQL — на другом, ресурсы разделены, архитектура выглядит серьезнее. Но отдельный сервер для базы данных нужен далеко не каждому проекту.
Небольшой сайт, интернет-магазин или веб-приложение вполне могут годами работать с базой на том же сервере, где находится backend. Более того, такая схема часто оказывается быстрее, дешевле и проще в обслуживании.
Отдельная инфраструктура становится полезной тогда, когда для нее появляется конкретная причина: СУБД начинает конкурировать с приложением за оперативную память и процессор, база заметно выросла, требуется независимое масштабирование, более сложное резервирование или управляемая база данных как отдельный сервис.
При этом выбор сервера для MySQL или PostgreSQL отличается от выбора обычного веб-хостинга. Здесь особенно важны оперативная память, скорость и задержки дисковой подсистемы, количество соединений, резервные копии и сетевое расположение относительно приложения.
Разберемся, где лучше хранить базу данных, когда подойдет обычный виртуальный хостинг, зачем выделять отдельный VPS, чем DBaaS отличается от самостоятельно установленной СУБД и почему медленный запрос нельзя надежно вылечить покупкой более дорогого сервера.
Нужен ли базе данных отдельный хостинг
В большинстве небольших проектов — нет.
Возьмем обычный сайт на WordPress. На виртуальном хостинге находятся PHP-файлы сайта, а провайдер предоставляет MySQL или совместимую СУБД. Пользователю даже не приходится задумываться, на какой физической машине работает база.
Сайт обращается к ней через параметры подключения, а управлением инфраструктурой занимается хостер.
Похожая схема возможна и на VPS.
На одной виртуальной машине работают Nginx или Apache, PHP или backend приложения и MySQL/PostgreSQL.
Для небольшого проекта это совершенно нормальная архитектура.
У нее есть очевидные преимущества. Не нужно оплачивать второй сервер. Между приложением и базой минимальная сетевая задержка. Резервирование и мониторинг проще. Меньше компонентов, которые могут выйти из строя.
Поэтому правило «база обязательно должна быть на отдельном сервере» неверно.
Разделение инфраструктуры само по себе не делает проект быстрее.
Иногда происходит даже обратное: после переноса базы появляется дополнительная сетевая задержка, а эксплуатация становится сложнее.
Выносить СУБД стоит тогда, когда преимущества разделения начинают перевешивать эту сложность.
Виртуальный хостинг с MySQL подходит огромному количеству сайтов
Для большинства обычных сайтов самый простой вариант — использовать базу данных, которую предоставляет хостинг.
Пользователь создает базу в панели управления, получает имя, логин и пароль, после чего указывает эти данные при установке CMS или приложения.
Самостоятельно устанавливать MySQL и администрировать сервер не требуется.
Это один из главных плюсов виртуального хостинга.
Хостер следит за серверным программным обеспечением, а клиент работает со своей базой в рамках предоставленных возможностей.
Для WordPress, небольших интернет-магазинов, форумов, блогов и множества других проектов этого достаточно.
Но shared-хостинг имеет ограничения.
Пользователь не управляет всей конфигурацией СУБД. Нельзя произвольно изменить любой системный параметр или установить необходимое расширение PostgreSQL, если провайдер его не предоставляет.
Могут ограничиваться размер базы, количество одновременных соединений и ресурсы аккаунта.
Для обычного сайта это редко становится проблемой.
Для специализированного приложения требования могут оказаться значительно выше.
Поэтому при выборе виртуального хостинга нужно проверять не только наличие слова «MySQL» в тарифе, но и соответствие возможностей площадки требованиям конкретного проекта.
Когда базе данных нужен собственный VPS
На VPS владелец получает значительно больше контроля.
Можно самостоятельно установить MySQL, MariaDB, PostgreSQL или другую СУБД, выбрать версию, настроить конфигурацию, пользователей, сетевой доступ и резервирование.
Но собственный VPS для базы нужен не потому, что он «профессиональнее».
Он решает конкретные задачи.
Представим веб-приложение, где backend и PostgreSQL работают на одном сервере.
По мере роста база начинает активно использовать оперативную память. В то же время приложение тоже требует RAM. В периоды высокой нагрузки компоненты начинают конкурировать за ресурсы.
Один из вариантов — просто увеличить VPS.
И очень часто это лучший первый шаг.
Но если база продолжает расти, ее можно перенести на отдельную машину.
Тогда backend получает собственные ресурсы, а СУБД — собственные.
Их можно масштабировать независимо.
Например, приложению требуется больше процессорных ресурсов, а базе — больше оперативной памяти и быстрый диск.
На двух серверах конфигурации можно подобрать под разные задачи.
Отдельный VPS также полезен, когда с одной базой работают несколько приложений или требуется более гибкая серверная настройка.
Но вместе со свободой появляется ответственность.
СУБД нужно обновлять, защищать, контролировать и резервировать. Если собственного опыта администрирования нет, стоит рассмотреть управляемый сервер или DBaaS.
Сначала попробуйте увеличить существующий сервер
Иногда проект начинает упираться в ресурсы, и разработчик сразу решает разделить backend и базу.
Это не всегда необходимо.
Если на VPS мало оперативной памяти, переход на более мощную конфигурацию может решить проблему значительно проще.
Один сервер легче обслуживать, чем два.
Не появляется отдельное сетевое соединение между приложением и СУБД, не нужно дополнительно защищать его и следить еще за одной виртуальной машиной.
Разделение становится оправданным, когда вертикальное масштабирование перестает быть удобным или появляются другие требования к архитектуре.
MySQL или PostgreSQL не определяют хостинг сами по себе
Вопрос «какой сервер лучше для MySQL» нельзя решить только названием СУБД.
То же относится к PostgreSQL.
Обе системы способны работать как на небольшой виртуальной машине, так и на значительно более серьезной инфраструктуре.
Требования определяются базой и характером работы с ней.
База небольшого корпоративного приложения на несколько сотен мегабайт и база крупного интернет-сервиса объемом в сотни гигабайт — совершенно разные задачи, даже если в обоих случаях используется PostgreSQL.
Важны количество запросов, сложность выборок, частота записи, количество одновременных соединений, объем активно используемых данных и требования к доступности.
Поэтому универсальная таблица вида «до 10 ГБ — 2 ГБ RAM, до 50 ГБ — 4 ГБ RAM» будет слишком грубой.
Размер базы важен, но далеко не только он определяет потребность в ресурсах.
Оперативная память для базы часто важнее количества процессорных ядер
СУБД активно используют память для кеширования данных и служебных операций.
Чем больше нужной информации удается обслуживать без постоянного обращения к диску, тем лучше может быть производительность.
Это не означает, что нужно покупать максимальный объем RAM.
Но для активно используемой базы слишком маленький объем памяти способен стать заметным ограничением.
Процессор тоже важен.
Сложные запросы, сортировки, агрегации и большое количество одновременных операций требуют CPU.
Однако ситуация, когда владелец добавляет еще четыре ядра, а база продолжает тормозить, вполне реальна.
Причина может находиться совсем в другом месте: медленный диск, нехватка памяти, блокировки или неэффективные запросы.
Поэтому сервер базы данных лучше подбирать по результатам измерений, а не по одному показателю.
Почему SSD и NVMe особенно важны для базы данных
СУБД постоянно работает с дисковой подсистемой.
Данные читаются и записываются, обновляются индексы, ведутся журналы транзакций, выполняются временные операции.
Поэтому скорость накопителя влияет на производительность базы сильнее, чем на простой статический сайт.
Современные SSD значительно быстрее старых жестких дисков при случайном доступе к данным.
NVMe способен обеспечить еще более высокую производительность и меньшие задержки.
Но одна надпись «NVMe» в характеристиках тарифа не гарантирует одинаковую скорость у разных хостеров.
Имеет значение реальная дисковая подсистема, нагрузка соседних виртуальных машин и ограничения самого тарифа.
Для базы особенно важны не только красивые показатели последовательного чтения больших файлов, но и производительность большого количества небольших операций ввода-вывода.
Именно здесь появляется показатель IOPS — количество операций ввода-вывода в секунду.
Для небольшого проекта углубляться в дисковые бенчмарки обычно не требуется.
Но если база стала узким местом, характеристики хранилища обязательно нужно включить в диагностику.
Удаленная база данных может оказаться медленнее локальной
Когда backend и СУБД находятся на одной машине, сетевой путь между ними минимален.
После переноса базы на отдельный сервер каждый запрос должен пройти по сети.
Если серверы находятся в одном дата-центре и связаны хорошей внутренней сетью, задержка может быть очень небольшой.
Проблема начинается, когда приложение и база физически расположены далеко друг от друга.
Представим backend в Москве и PostgreSQL в другой части Европы.
Один сетевой запрос может казаться достаточно быстрым. Но приложение редко обращается к базе только один раз.
Для формирования страницы или ответа API могут выполняться десятки запросов.
Дополнительная задержка начинает складываться.
В результате мощная удаленная база может субъективно работать хуже более скромной СУБД рядом с приложением.
Поэтому backend и основную базу данных обычно разумно размещать близко друг к другу.
В идеальном случае — внутри одной инфраструктуры с низкой сетевой задержкой.
Приватная сеть лучше публичного интернета
Если хостинг-провайдер позволяет объединить VPS во внутреннюю приватную сеть, это удобный вариант для связи приложения и базы.
СУБД не требуется принимать подключения через публичный интернет.
Backend обращается к ней по внутреннему адресу.
Это уменьшает внешнюю поверхность атаки и часто упрощает сетевую архитектуру.
Если приватной сети нет, доступ все равно можно жестко ограничить firewall и другими средствами.
Не открывайте MySQL и PostgreSQL всему интернету без необходимости
При самостоятельной настройке VPS возникает соблазн разрешить удаленное подключение к базе с любого адреса. Так удобнее подключаться к ней с рабочего компьютера.
Для рабочей системы это плохая идея.
Порт СУБД, доступный всему интернету, становится еще одной точкой для автоматического сканирования и атак.
Если удаленное подключение действительно необходимо, доступ лучше ограничивать.
Например, разрешить соединения только с IP backend-сервера и доверенных административных адресов.
Еще один вариант — использовать VPN или SSH-туннель для административного доступа.
Также важно правильно настроить саму СУБД.
MySQL и PostgreSQL позволяют управлять тем, на каких интерфейсах принимаются подключения и какие пользователи могут соединяться с каких адресов.
Firewall и настройки СУБД должны дополнять друг друга.
И конечно, для приложения следует создать отдельного пользователя базы с необходимыми правами, а не подключать backend под учетной записью администратора СУБД.
Количество соединений может стать проблемой раньше мощности сервера
Каждое приложение должно каким-то образом соединяться с базой.
Если запросов становится много, неправильная работа с соединениями способна создать серьезную нагрузку.
Представим приложение, которое для каждого небольшого действия постоянно создает новые соединения, а затем оставляет их висеть.
Через некоторое время СУБД упирается в лимит подключений.
При этом процессор может быть далеко не полностью загружен.
Для таких сценариев используется пул соединений, или connection pooling.
Приложение переиспользует уже созданные подключения вместо бесконечного открытия новых.
Для PostgreSQL в определенных архитектурах дополнительно применяются специализированные решения для pooling.
Но и здесь нет правила, что отдельный пулер обязательно нужен любому маленькому сайту.
Сначала нужно понимать поведение конкретного приложения.
Медленная база не всегда означает слабый сервер
Это одна из самых важных вещей при работе с СУБД.
Представим таблицу с миллионами записей.
Приложение регулярно ищет данные по определенному полю, но подходящего индекса нет.
База вынуждена просматривать огромное количество строк.
Можно увеличить CPU. Добавить RAM. Перейти на более дорогой NVMe.
Запрос, вероятно, станет несколько быстрее.
Но фундаментальная проблема останется.
После создания правильного индекса тот же запрос иногда ускоряется на порядки.
Другой пример — приложение делает сто отдельных запросов там, где можно было получить необходимые данные значительно эффективнее.
Или строит тяжелый отчет при каждом открытии страницы, хотя результат можно вычислять заранее или кешировать.
Поэтому перед увеличением сервера стоит посмотреть медленные запросы и план их выполнения.
MySQL и PostgreSQL предоставляют инструменты, которые помогают понять, как СУБД выполняет запрос.
Хорошая оптимизация приложения часто оказывается дешевле постоянного наращивания инфраструктуры.
Нужно ли использовать Redis рядом с базой данных
Redis не является заменой MySQL или PostgreSQL в обычном смысле.
Чаще его используют как быстрый кеш, хранилище временных данных, механизм очередей или для других специализированных задач.
Например, приложение постоянно запрашивает из PostgreSQL один и тот же редко меняющийся набор данных.
Результат можно временно сохранить в кеше.
Следующие запросы будут обслуживаться быстрее и не станут лишний раз нагружать основную СУБД.
Но добавлять Redis только потому, что база работает медленно, неправильно.
Сначала нужно понять причину.
Если тормозит неэффективный SQL-запрос, кеш может временно скрыть проблему, но не исправит ее.
Кроме того, кеш нужно корректно обновлять после изменения исходных данных.
Иначе приложение начнет показывать устаревшую информацию.
Что такое управляемая база данных DBaaS
Самостоятельно устанавливать СУБД на VPS необязательно.
Облачные провайдеры предлагают управляемые базы данных — DBaaS, или Database as a Service.
Пользователь создает экземпляр MySQL, PostgreSQL или другой поддерживаемой СУБД через панель управления или API, а значительную часть инфраструктурной работы выполняет провайдер.
Конкретный набор функций зависит от сервиса.
Провайдер может заниматься развертыванием, обновлениями, резервными копиями, мониторингом и отказоустойчивостью.
Пользователю не нужно самостоятельно обслуживать операционную систему сервера базы.
Это особенно удобно для команды разработчиков без отдельного администратора.
Но DBaaS обычно стоит дороже простого VPS с сопоставимыми вычислительными ресурсами.
Пользователь платит не только за CPU, RAM и диск, но и за управляемость сервиса.
Кроме того, доступ к низкоуровневым настройкам может быть ограничен.
Поэтому выбор между собственным PostgreSQL на VPS и управляемым PostgreSQL — это во многом выбор между контролем и количеством работы, которую команда хочет выполнять самостоятельно.
DBaaS не оптимизирует запросы за разработчика
Управляемая база может автоматизировать значительную часть эксплуатации, но она не знает бизнес-логику приложения.
Провайдер не исправит автоматически неудачную структуру таблиц, лишние запросы или отсутствие нужных индексов.
DBaaS снимает часть инфраструктурных задач, но качество самой базы по-прежнему остается ответственностью разработчика.
Резервные копии базы данных нельзя хранить только рядом с ней
Для базы резервное копирование особенно важно.
Код приложения обычно можно снова получить из Git. Пользовательские данные, которые существовали только в рабочей базе, взять больше неоткуда.
Самый простой backup — периодический дамп базы.
Он может сохраняться в отдельный файл и отправляться во внешнее хранилище.
Но по мере роста базы простая схема становится менее удобной.
Большой дамп долго создается и долго восстанавливается.
Для серьезных систем используются более продвинутые механизмы резервирования.
В любом случае важно, чтобы единственная копия не находилась на том же сервере.
Если VPS потерян вместе со своим диском, локальный backup исчезнет вместе с рабочей базой.
Поэтому резервные копии нужно хранить независимо.
Их также необходимо защищать.
В backup находится та же информация, что и в рабочей базе, а иногда даже больше исторических данных.
Открытый доступ к резервной копии может быть таким же серьезным инцидентом, как утечка основной СУБД.
Point-in-time recovery спасает когда обычного backup недостаточно
Представим, что резервная копия базы создается каждую ночь.
В 16:00 сотрудник или ошибочный скрипт удаляет важные данные.
Восстановление ночного backup вернет базу в состояние на начало дня, но все изменения за последующие часы будут потеряны.
Для критичных систем может использоваться восстановление на определенный момент времени — point-in-time recovery, или PITR.
СУБД сохраняет необходимую историю изменений, благодаря чему базу можно восстановить к состоянию непосредственно перед проблемным событием.
Это значительно сокращает потенциальную потерю данных.
Но такая схема требует дополнительного хранения и правильной настройки.
Для небольшого сайта PITR может быть избыточным.
Для активно изменяющейся бизнес-базы его ценность значительно выше.
При выборе DBaaS полезно посмотреть, поддерживается ли восстановление на момент времени и какая глубина истории доступна на конкретном тарифе.
Реплика базы данных не является резервной копией
Еще одна распространенная ошибка — считать репликацию полноценной заменой backup.
При репликации изменения основной базы передаются на другой экземпляр.
Это может быть полезно для отказоустойчивости и распределения нагрузки.
Но если пользователь случайно удалил важную таблицу, такое изменение тоже может быть передано на реплику.
В результате копия честно повторит ошибку основной базы.
То же относится к повреждению данных на уровне приложения.
Поэтому репликация и резервное копирование решают разные задачи.
Хорошая инфраструктура может использовать и то и другое.
Зачем нужна read replica
В некоторых проектах количество операций чтения значительно превышает количество записей.
Например, большая система аналитики постоянно выполняет запросы к данным, но обновляет их значительно реже.
Тогда часть чтений можно направить на реплику.
Основная база продолжает обрабатывать запись, а дополнительные экземпляры помогают обслуживать чтение.
Такой подход позволяет масштабировать определенный тип нагрузки.
Но у репликации может быть задержка.
Изменение уже записано в основную базу, а на реплике появится немного позже.
Для одних операций это несущественно. Для других пользователь должен немедленно увидеть только что сохраненные данные.
Поэтому приложение должно понимать, какие запросы можно безопасно отправлять на read replica.
Небольшому сайту такая архитектура почти никогда не нужна.
Это инструмент масштабирования под конкретную нагрузку, а не обязательная функция хорошего хостинга.
Высокая доступность базы стоит денег
Если единственный сервер PostgreSQL перестал работать, приложение, скорее всего, тоже потеряет большую часть функциональности.
Можно увеличить надежность инфраструктуры с помощью резервных экземпляров и автоматического переключения.
В случае отказа основной базы другой узел принимает ее роль.
Но такая схема сложнее и дороже одного VPS.
Для личного проекта простой базы в течение часа может быть неприятным, но не критичным.
Для SaaS с тысячами платящих клиентов тот же час способен привести к финансовым и репутационным потерям.
Поэтому уровень отказоустойчивости должен соответствовать стоимости простоя.
Не существует универсального требования, что PostgreSQL обязательно должен работать в кластере.
Нужно сопоставить вероятность отказа, последствия и стоимость защиты от него.
Мониторинг базы помогает покупать ресурсы по фактам
После запуска базы стоит следить хотя бы за основными показателями.
Насколько загружен процессор? Сколько используется памяти? Не заканчивается ли диск? Как меняется размер базы? Сколько активных соединений? Есть ли медленные запросы?
Очень полезно наблюдать динамику.
Если база увеличивается на 20 ГБ каждый месяц, а свободно 30 ГБ, проблема появится довольно скоро, даже если сегодня все работает идеально.
То же касается соединений.
Если их количество постепенно приближается к пределу, лучше разобраться заранее.
Для PostgreSQL и MySQL существуют собственные метрики и инструменты диагностики, а хостинг или облачная платформа могут предоставлять дополнительный мониторинг.
Главное — не ждать момента, когда база полностью перестанет отвечать.
Что проверить перед выбором хостинга для базы данных
Начать нужно не с максимального тарифа, а с требований приложения.
Какая СУБД используется? Какой объем базы сейчас? Насколько быстро она растет? Сколько одновременных пользователей работает с приложением? Много ли записей и сложных запросов? Насколько критична потеря данных?
После этого можно сравнивать варианты размещения.
Для отдельного сервера базы я бы проверила:
- поддержку необходимой СУБД и ее версии;
- доступный объем оперативной памяти;
- процессорные ресурсы;
- тип дисков;
- реальные ограничения дисковой производительности;
- объем доступного хранилища;
- возможность увеличения диска;
- возможность увеличения RAM и CPU;
- приватную сеть между backend и базой;
- сетевую задержку;
- наличие статических внутренних адресов;
- возможность ограничить подключения по IP;
- наличие firewall;
- резервные копии;
- частоту создания backup;
- срок их хранения;
- возможность скачать копию независимо от провайдера;
- поддержку point-in-time recovery, если она нужна;
- мониторинг ресурсов;
- доступ к метрикам СУБД;
- возможность создания реплик;
- варианты высокой доступности;
- географию дата-центров;
- стоимость исходящего трафика, если он тарифицируется;
- качество технической поддержки.
Для DBaaS дополнительно нужно выяснить, что именно провайдер берет на себя.
Слово «управляемая» у разных сервисов может означать разный набор функций.
Проверьте, кто выполняет обновления, как устроены резервные копии, можно ли выбрать версию СУБД, как происходит масштабирование и что случится при отказе основного экземпляра.
Какой хостинг для базы данных выбрать в итоге
Для обычного сайта отдельный сервер базы чаще всего вообще не нужен.
Если проект работает на виртуальном хостинге и предоставляемая MySQL или другая поддерживаемая СУБД справляется с задачей, усложнять инфраструктуру нет смысла.
На VPS небольшое приложение и база тоже вполне могут работать вместе.
Это простой и экономичный вариант.
Когда СУБД начинает конкурировать с приложением за ресурсы, требуется независимое масштабирование или появляются более серьезные требования к доступности, базу можно вынести на отдельный VPS.
При этом сервер приложения и сервер базы желательно размещать рядом, используя внутреннюю сеть с минимальной задержкой.
Не открывайте порт MySQL или PostgreSQL всему интернету просто ради удобства. Ограничивайте сетевой доступ и используйте отдельные учетные записи с необходимыми правами.
Если команда не хочет самостоятельно обслуживать СУБД, стоит рассмотреть DBaaS.
Управляемая база обычно обходится дороже самостоятельного PostgreSQL или MySQL на VPS, зато провайдер берет на себя часть эксплуатационной работы.
При выборе ресурсов особенно внимательно смотрите на RAM и дисковую подсистему. Для активно используемой базы они могут оказаться важнее огромного количества процессорных ядер.
Но не пытайтесь решить сервером проблему плохих SQL-запросов.
Отсутствующие индексы, неудачная структура данных и сотни лишних обращений к СУБД способны замедлить проект даже на дорогой инфраструктуре.
Настройте мониторинг и принимайте решения на основании реальных показателей.
Резервные копии храните независимо от основного сервера и периодически проверяйте восстановление. Для критичных систем рассмотрите point-in-time recovery.
Не путайте backup с репликацией. Реплика помогает решить определенные задачи доступности и масштабирования, но способна скопировать ошибочное удаление данных так же успешно, как правильное изменение.
И главное — не выносите базу на отдельный сервер только потому, что так архитектура выглядит солиднее.
Лучший хостинг для MySQL или PostgreSQL — не обязательно отдельная машина. Это инфраструктура, в которой база получает достаточно памяти, быстрый и стабильный диск, безопасное сетевое окружение, надежные резервные копии и находится достаточно близко к приложению.
Пока один сервер уверенно справляется с этой задачей, он может оставаться самым простым и рациональным вариантом. А когда база действительно перерастет его возможности, переход к отдельному VPS или управляемой СУБД станет не модным архитектурным решением, а понятным следующим этапом развития проекта.
