Хостинг базы данных MySQL + PHP

Сервер под базу данных подбирают по одному главному признаку: помещается ли рабочий набор данных в оперативную память. Пока помещается, база отвечает за миллисекунды. Как только перестает — начинается чтение с диска, и время отклика вырастает в десятки раз независимо от процессора. Отсюда порядок приоритетов при выборе: сначала память, потом диски, и только потом ядра. Конфигурации доступны от 12 000 ₽ в месяц, дата-центры категории TIER III, площадки в тринадцати городах.

Главное правило: рабочий набор и память

Рабочий набор — это та часть базы, к которой обращаются регулярно. Он почти всегда меньше полного объема: в базе на 500 ГБ активно используются, скажем, 60 ГБ, а остальное лежит архивом.

Задача при выборе сервера — уместить этот рабочий набор в память вместе с накладными расходами. Если получилось, диск нужен в основном для записи. Если нет, каждая вторая операция уходит на диск, и дальше уже неважно, сколько у вас ядер.

Оценить размер рабочего набора можно по показателю попаданий в кеш. У PostgreSQL его считают по представлению pg_statio_user_tables, у MySQL смотрят соотношение чтений из буферного пула к чтениям с диска. Показатель ниже 95% — сигнал, что памяти мало.

Сколько памяти нужно базе данных

Память с коррекцией ошибок обязательна. Одиночная ошибка в бите на сервере без коррекции превращается в тихо испорченную запись, которая уедет в резервные копии и обнаружится через месяц.

Ориентиры по объему:

Настройки по умолчанию почти всегда занижены. У PostgreSQL shared_buffers обычно ставят около четверти оперативной памяти, у MySQL innodb_buffer_pool_size на выделенном сервере поднимают до 70–80%. Часто нехватка памяти лечится правкой конфигурации, а не переездом на старшую конфигурацию — это стоит проверить до заказа.

Диски: почему NVMe и какой RAID

База данных нагружает диск не объемом, а количеством мелких операций и задержкой подтверждения записи. Поэтому решает не размер накопителя, а его тип.

С уровнем массива история такая же прямая. Зеркало с чередованием обходится записи в две операции, массив с одной контрольной суммой — в четыре, с двумя — в шесть. Для базы с активной записью это разница в разы, поэтому под базы берут зеркало с чередованием, а массивы с контрольными суммами оставляют хранилищам и резервным копиям.

Отдельная рекомендация: журнал транзакций выносят на отдельный накопитель. Это снимает конкуренцию за операции между журналом и данными и заметно ускоряет запись.

Процессор: ядра или частота

Выбор зависит от того, как база нагружается.

• Много одновременных соединений с короткими запросами — нужны ядра. Каждое соединение обслуживается отдельным процессом или потоком.
• Мало соединений с тяжелыми запросами — нужна частота. Один сложный запрос упирается в скорость одного ядра.
• 1С в файловом режиме — только частота. Количество ядер там почти не влияет.
• Аналитические запросы по большим объемам — снова ядра, современные базы умеют распараллеливать такие запросы.

Практическое следствие: под учетную систему на десяток человек машина с высокой частотой ядра отработает лучше и дешевле, чем два процессора с сорока потоками.

Готовые ориентиры по конфигурациям

Цифры ориентировочные: реальные требования зависят от структуры данных и запросов сильнее, чем от названия базы. Память и диски добавляются в работающий сервер по запросу, процессоры — нет, поэтому по сокетам запас закладывают сразу.

Резервные копии и репликация

Резервная копия, которую ни разу не восстанавливали, резервной копией не является. Это главная мысль раздела, и проверять восстановление стоит по расписанию, а не после аварии.

• Копии хранят отдельно от сервера с базой — отказ дискового массива не должен уносить их вместе с данными.
• Удобное место для хранения — объектное хранилище S3: копии не занимают диски рабочего сервера и лежат вне его отказа.
• Для быстрых точек восстановления держат непрерывное архивирование журнала, а не только суточный снимок.
• Реплика на втором сервере закрывает отказ основного узла, но не заменяет копию: ошибочно удаленные данные уедут в реплику за секунды.

Где размещать: задержка до приложения и 152-ФЗ

База и приложение должны стоять рядом. Каждый запрос — это сетевой обход, и на странице с сотней запросов лишние миллисекунды складываются в заметную задержку. Если приложение работает в московском дата-центре, база в Амстердаме будет тормозить его сильнее, чем любой недостаток железа.

Второй фактор правовой. Часть 5 статьи 18 закона 152-ФЗ обязывает хранить персональные данные граждан России в базах на территории России. Для базы с клиентскими данными это означает московскую площадку. За рубежом размещают базы без персональных данных, обезличенные наборы и вторичные копии при соблюдении порядка трансграничной передачи. Мы не оказываем юридических услуг: схему размещения стоит согласовать с юристом до запуска.

Как заказать

1. Оцените размер активной части базы и подберите объем памяти с запасом.
2. Выберите NVMe и зеркало с чередованием, журнал вынесите отдельно.
3. Определитесь с процессором: ядра под много соединений, частота под тяжелые запросы.
4. Укажите площадку рядом с приложением.
5. Оплатите по счету, картой, через ЮMoney или с баланса.

Если нужной конфигурации в каталоге нет, оборудование закупят под проект: арендовать выделенный сервер можно в любой из доступных локаций. Скидки за предоплату: 3 месяца — 3%, 6 месяцев — 6%, 12 месяцев — 12%.

Коротко

• Сервер под базу подбирают по объему памяти: активная часть данных должна в нее помещаться.
• Память только с коррекцией ошибок, настройки по умолчанию почти всегда занижены.
• Диски — NVMe, массив — зеркало с чередованием, журнал транзакций выносится отдельно.
• Много соединений требует ядер, тяжелые запросы и 1С в файловом режиме — частоты ядра.
• Резервные копии хранятся вне сервера, восстановление проверяется по расписанию.
• База ставится рядом с приложением; база с персональными данными россиян — на московской площадке.