Выделенный сервер для PostgreSQL и MySQL: ANKH или SCARAB для большой базы

MAATRIX · Выделенные серверы · Статья 6 из 48

Тридцать миллионов строк звучат внушительно. Такую цифру хочется произнести на совещании, выдержать паузу и перейти к покупке серьёзного оборудования. Однако для базы данных это примерно как «тридцать миллионов предметов» для склада: прежде чем строить новый ангар, хорошо бы выяснить, храним мы пуговицы или холодильники.

Выделенный сервер для PostgreSQL или MySQL выбирают по объёму данных, запросам и требованиям к сохранности. Число строк помогает описать задачу, но не решает её. На двух машинах из американской линейки MAATRIX — SCARAB и ANKH — это особенно хорошо видно: разница в аренде небольшая, а в памяти существенная. Разберём, когда эта память действительно нужна и что ещё следует проверить до переезда.

Сначала посмотрите, что скрывается за миллионами строк

Представим два условных проекта. Первый хранит события датчиков: короткое время, номер устройства и значение. Второй — карточки заказов с длинными текстами, служебными полями и многочисленными индексами. Даже при одинаковом количестве записей их размеры, стоимость обновления и характер чтения будут различаться.

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

Не забудьте о том, что место занимает сама организация хранения. Индексы ускоряют подходящие запросы, но требуют диска и обслуживания при изменениях. Журналы транзакций, временные результаты сортировки и запас для перестроения объектов тоже не исчезают после покупки NVMe. Вопрос «поместится ли база в один терабайт?» должен относиться ко всей работающей системе, а не только к размеру вчерашней выгрузки.

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

За что ANKH просит дополнительные двадцать долларов

Доплата составляет $20, или примерно 6,5% от аренды SCARAB. За неё в карточке указаны дополнительные два ядра и вдвое больше памяти. Поэтому ANKH разумно первым включить в испытания, если вы уже решили, что нужен отдельный физический сервер для базы. Это вывод о соотношении заявленных ресурсов и цены, а не результат теста PostgreSQL или MySQL.

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

Надписи EPYC и Ryzen не отвечают на все вопросы о надёжности. Поддержка возможностей процессором и оснащение конкретного арендованного сервера — разные вещи. Тип памяти, работа ECC, модели SSD и защита их буферов при потере питания требуют подтверждения. Ни один из этих пунктов нельзя достроить в воображении по одному названию семейства CPU.

У обоих тарифов указан один накопитель. Следовательно, из карточек не следует наличие зеркала или второго локального диска для восстановления. Для базы, потеря которой остановит продажи или учёт, это отдельный пункт разговора с провайдером. Самый быстрый запрос мало радует, если после аппаратного отказа выясняется, что рабочая копия была единственной.

Память нужна не всей истории человечества

Активно используемые страницы желательно удерживать в памяти: это уменьшает необходимость читать их с накопителя. Но требование «база целиком обязана помещаться в RAM» слишком категорично. Архивные разделы могут обращаться к диску редко и без вреда для пользовательского отклика. Важнее понять, какие данные действительно участвуют в повседневных операциях.

В PostgreSQL память расходуют общий буферный кэш, процессы, операции сортировки и хеширования, обслуживание и операционная система. В MySQL с InnoDB важную роль играет buffer pool, где хранятся страницы данных и индексов. Его назначение подробно объясняет руководство MySQL. Назначать весь объём RAM одному параметру в любом случае нельзя.

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

Представим измеренный вами рабочий набор, который почти заполняет 32 ГБ вместе с прочими расходами. Здесь переход на 64 ГБ может уменьшить чтение с диска и дать запас для пиков. Но если запрос каждый раз сканирует огромный архив, дополнительные гигабайты не отменят его работу. Иногда правильный индекс, изменение запроса или выделенная аналитическая копия полезнее удвоения RAM.

И наоборот: не стоит объявлять память бесполезной только потому, что график свободной RAM низкий. Операционная система использует доступное пространство под файловый кэш. Смотрите на давление на память, вытеснение, временные файлы и задержки приложения. Показатель «занято» без объяснения, чем именно занято, легко превращается в причину ненужной покупки.

Один плохой запрос умеет занять любой сервер

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

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

Полезные вопросы к плану просты: сколько строк ожидалось и сколько оказалось на деле, где идёт полное чтение, какие соединения таблиц дороги, появляются ли временные результаты. Само по себе последовательное сканирование не является ошибкой: когда требуется значительная часть таблицы, оно может быть разумным выбором. Цель — понять решение планировщика, а не заставить его показывать слово Index любой ценой.

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

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

Диск работает даже тогда, когда всё прочитано в кэш

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

Не переносите цифру из рекламного теста SSD прямо на число заказов в секунду. У СУБД другой размер операций, другая очередь и требования к подтверждению записи. Кроме того, состояние заполненного накопителя и совместная работа с резервным копированием могут отличаться от короткого теста на пустом диске.

В PostgreSQL следует оставить место и ресурсы для autovacuum. Он обслуживает таблицы, в которых после изменений остаются старые версии строк; отключать его ради красивого мгновенного графика — сомнительная экономия. Назначение обычного VACUUM и его отличие от более тяжёлых операций объясняет документация PostgreSQL. На больших активно изменяемых таблицах важно наблюдать, успевает ли обслуживание за потоком изменений.

Проверьте отдельно рост журналов и причины удержания старых данных. Отстающая реплика или неверно организованное архивирование способны съесть свободное место быстрее ожидаемого. Увеличение диска даёт время, но не объясняет происхождение роста. Аварийная очистка файлов вручную без понимания назначения может превратить нехватку места в невосстановимую базу.

При выборе между ANKH и SCARAB дисковая ёмкость одинакова. Если ограничение находится именно здесь, переход на ANKH проблему не решит. Нужны другие условия хранения, сокращение удерживаемой истории или иной способ размещения данных. Иногда база уже переросла оба тарифа, и это вполне нормальный результат расчёта.

Проверка, после которой можно выбирать тариф

Подготовьте копию базы, близкую к рабочей по структуре и объёму. Сохраните распределение данных: равномерно сгенерированный набор может скрыть перекосы реальной системы. Перенесите нужные индексы и настройки, обновите статистику штатными средствами. Тестовые внешние интеграции должны быть отключены или переведены в безопасный режим.

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

Повторите измерения после прогрева кэша и в условиях первоначального чтения. Зафиксируйте версии СУБД, настройки, объём данных и число активных клиентов. Тогда результат можно будет воспроизвести после обновления, а сравнение SCARAB и ANKH не сведётся к воспоминанию «в тот четверг было быстрее».

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

ANKH при данном прайсе выглядит сильным стартовым кандидатом благодаря памяти за небольшую доплату. SCARAB разумен там, где его достаточность уже доказана, а дополнительные ресурсы не используются. Окончательное решение принимают вместе с требованиями к дискам, восстановлению и размещению в США. Десятки миллионов строк вполне могут жить спокойно — если у них есть подходящие запросы, достаточно места и администратор, который интересуется не только их количеством.

Все материалы о выделенных серверах