Базы данных
Запускайте PostgreSQL, MySQL, ClickHouse или Redis на выделенном сервере для баз данных, где буферный пул, очередь NVMe и каждое ядро EPYC служат одному-единственному клиенту — вам.
Во всех тарифах на EPYC стоят модули памяти ECC: они исправляют битовые ошибки на пути к процессору, а не только внутри самого чипа, как встроенная (on-die) ECC в DDR5.
От 128 до 384 ГБ ОЗУ, чтобы горячая часть данных отдавалась из буферного пула, а не с дисков.
Случайные чтения и коммиты с частыми fsync идут прямо на локальные NVMe — без сетевого блочного хранилища и общей очереди посередине.
Соединяйте основной сервер и реплику в одной локации через бесплатную приватную VLAN, а между регионами — через туннель WireGuard.
Рекомендуемые серверы
От первого развертывания до нагруженного продакшена. Наличие и цены в реальном времени; выбранные серверы в наличии готовы к работе менее чем за 2 минуты.
Наш выборОсновная БД для растущего приложения
12 ядер / 24 потока · 3,7–5,4 ГГц
12 ядер Zen 4 с частотой до 5,4 ГГц — для быстрых одиночных запросов, а 128 ГБ DDR5 ECC и 2 × 1,92 ТБ NVMe подойдут для большинства OLTP-баз объемом до терабайта.
Крупные OLTP-базы и аналитика
24 ядра / 48 потоков · 2,85–4,0 ГГц
24 ядра, 256 ГБ 8-канальной DDR4 ECC и 2 × 3,84 ТБ NVMe с портом 10 Гбит/с — для больших буферных пулов, параллельных запросов и быстрого пересоздания реплик.
ClickHouse и большие данные
32 ядра / 64 потока · 3,25–3,8 ГГц
32 ядра Zen 4, 384 ГБ 12-канальной DDR5 ECC и 256 МБ кэша L3 для сканирований и агрегаций по миллиардам строк, с портом 10 Гбит/с.
Подбор конфигурации
Эти диапазоны — ориентиры, а не результаты измерений: важно, какая доля ваших данных горячая, поэтому перед выбором проверьте коэффициент попаданий в кэш на текущей системе.
| Профиль базы данных | Что определяет конфигурацию | Рекомендуемый тариф |
|---|---|---|
| PostgreSQL или MySQL до ~500 ГБ | Горячие данные помещаются в 128 ГБ; быстрые ядра для одиночных запросов | AMD EPYC 4464P |
| Кэш и сессии на Valkey или Redis | Весь набор данных в ОЗУ плюс запас для снапшотов через fork | AMD EPYC 4464P |
| OLTP на |
Больший буферный пул, больше ядер, PgBouncer перед базой | AMD EPYC 7443P |
| Узел набора реплик MongoDB | Кэш WiredTiger — около половины ОЗУ; рабочий набор в памяти | AMD EPYC 7443P |
| Аналитика ClickHouse на миллиардах строк | Ядра и пропускная способность памяти для сканирования; NVMe для кусков данных (parts) | AMD EPYC 9354P |
Советы экспертов
Краткие практические советы наших инженеров для этой задачи.
Коммит надежно сохранен, только когда он попал на энергонезависимый носитель. На основном сервере оставьте безопасные значения по умолчанию: fsync = on в PostgreSQL, innodb_flush_log_at_trx_commit = 1 и sync_binlog = 1 в MySQL или MariaDB. Если допустимо потерять коммиты последних мгновений перед сбоем, параметр synchronous_commit = off в PostgreSQL ускорит работу ценой этого окна, не создавая риска повреждения данных.
cat /proc/mdstat.pg_test_fsync.recordsize с размером страницы (для начала 16K для InnoDB и 8K для PostgreSQL) и ограничьте ARC, чтобы он не конкурировал с буферным пулом.База данных, которая читает из ОЗУ, редко ждет. Подберите объем памяти под горячие данные, а затем настройте каждый движок так, чтобы он не конкурировал ни с другими, ни с ОС:
shared_buffers — около 25% ОЗУ, effective_cache_size — около 70% и умеренное значение work_mem, ведь его может задействовать каждая сортировка или хеш-операция в каждом запросе.innodb_buffer_pool_size — maxmemory заметно меньше объема ОЗУ: при создании снапшотов процесс форкается, и механизму копирования при записи (copy-on-write) нужен запас.max_memory_usage, чтобы один тяжелый отчет не обрушил весь сервер.Затем следите за коэффициентом попаданий в кэш: если под нагрузкой он падает, добавление ОЗУ обычно помогает больше, чем более быстрые диски.
Реплику, на которую вы будете переключаться при сбое, держите в той же локации и соединяйте через бесплатную приватную VLAN: задержка останется достаточно низкой, чтобы можно было позволить себе синхронную репликацию. Для аварийного восстановления добавьте асинхронную реплику в другой локации через WireGuard: при синхронном коммите через океан каждая транзакция ждала бы прохождения пакетов туда и обратно.
С root-доступом вы устанавливаете именно то, что нужно. Это проверенные решения для такой задачи.
Частые вопросы
Да — для любой базы данных, которую нельзя восстановить из другого источника. Сбойный бит в ОЗУ может попасть на диск в составе страницы, которая выглядит вполне корректной, а затем разойтись по всем репликам и резервным копиям. ECC исправляет однобитовые ошибки и сообщает о двухбитовых. Во всех тарифах на EPYC используется ECC; в тарифах Ryzen из линейки «Производительные» стоит DDR5 без ECC — для кэшей и stateless-приложений это нормально, но для основной базы данных это менее надежный выбор.
На основном сервере оставьте RAID 1, который используется по умолчанию: он переживет отказ NVMe-диска на время замены, а замену по нашему SLA мы стремимся выполнить в течение четырех часов после диагностики. RAID 0 вдвое увеличивает емкость и скорость записи, но при отказе одного диска теряется все, поэтому используйте его только для реплик, которые можно пересоздать. ZFS добавляет контрольные суммы, сжатие и снапшоты, но взамен требует настройки recordsize и ARC.
Для PostgreSQL настройте новый сервер как потоковую реплику с помощью pg_basebackup, дождитесь, пока она догонит основной сервер, а затем во время короткой паузы в записи повысьте ее до основного (promote). С MySQL и MariaDB схема та же: копия через mariadb-backup или XtraBackup плюс репликация. Логические дампы проще, но на больших базах работают медленнее и требуют простоя, который растет вместе с объемом данных.
ClickHouse распределяет сканирование по всем ядрам и выигрывает от высокой пропускной способности памяти, поэтому для больших таблиц естественный выбор — EPYC 9354P: 32 ядра, 12-канальная DDR5 и 384 ГБ. Для небольших аналитических нагрузок подойдет EPYC 7443P. Данные в столбцах часто сжимаются до малой доли исходного объема, поэтому на 2 × 3,84 ТБ NVMe помещается больше данных, чем можно подумать, глядя на эту цифру.
Да, и на одной машине каждый запрос обходится без лишнего сетевого перехода. Сначала выделите базе данных фиксированный объем памяти, остаток отдайте приложению, а тяжелые воркеры, если они конкурируют за ресурсы, закрепите за отдельными ядрами. Разнесите их по разным серверам, когда приложению понадобится горизонтальное масштабирование, а базе — реплика: благодаря приватной VLAN связь между ними не будет проходить через интернет.
Выберите один из рекомендуемых серверов в наличии — он может быть готов к работе менее чем за 2 минуты, с оплатой с баланса и без платы за установку.
Это единственный способ вернуть доступ к аккаунту, если вы забудете пароль или потеряете устройство для двухфакторной аутентификации. Показать его повторно мы не сможем.