Сколько денег съедает неоптимизированная база данных

MAATRIX

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

Прямые расходы: платите за железо вместо оптимизации

Самый очевидный и самый недооценённый канал потерь — это апгрейд сервера как реакция на тормоза вместо разбора причины. База стала медленнее отвечать, нагрузка на CPU растёт, и первое, что приходит в голову — взять тариф побольше. В моменте это работает: больше ядер и памяти на некоторое время сглаживают симптом. Но если причина в отсутствующем индексе или запросе, который гоняет полный скан таблицы, апгрейд не решает проблему — он просто покупает немного времени за деньги.

Дальше вступает арифметика, которая многих удивляет. Не оптимизированный запрос с ростом данных не деградирует линейно — часто деградация ближе к квадратичной, потому что полный скан таблицы становится дороже пропорционально её размеру, а частота таких запросов от объёма данных не зависит. То есть один и тот же неисправленный запрос, который сегодня требует перехода на тариф в полтора раза дороже, через полгода роста базы потребует уже перехода на тариф в два-три раза дороже — потому что данных стало больше, а запрос как перебирал всю таблицу, так и перебирает. Оптимизация же (правильный индекс, переписанный запрос) обычно снимает нагрузку одномоментно и не требует повторных вложений при дальнейшем росте данных — до следующего порядка увеличения объёма данных.

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

Скрытые расходы: разработчики тушат пожар вместо работы над продуктом

Второй прямой расход считается ещё реже — это время разработчиков. Когда база время от времени "подвисает", кто-то из команды тратит на это не пять минут: сначала нужно понять, что тормозит именно база, а не сеть или бэкенд, затем найти конкретный запрос, затем разобраться, почему он медленный, затем протестировать исправление, не сломав ничего рядом. Реалистичная оценка — от пары часов на разовый разбор до нескольких дней, если проблема системная и разбросана по десяткам мест кода.

Хуже, если такой пожар повторяется регулярно: раз в неделю или две кто-то из инженеров бросает текущую задачу и идёт разбираться, "почему опять всё тормозит". Это время не заносится в бюджет "инфраструктуры" — оно тихо вычитается из времени на фичи, и именно поэтому его редко считают как расход. Но если умножить часовую ставку разработчика на количество часов, потраченных за квартал на такие разборы, сумма обычно оказывается заметно больше, чем стоил бы разовый апгрейд тарифа — с той разницей, что апгрейд решает проблему на время, а разбор кода — как правило навсегда.

Отдельная скрытая стоимость — это переключение контекста. Час, потраченный на разбор чужого медленного запроса в проде под давлением "у нас всё легло", по продуктивности сильно отличается от часа спокойной работы над фичей. Экстренные разборы обычно требуют больше нервов и времени на возврат в рабочий ритм, чем показывает голый счётчик часов.

Косвенные потери: пользователи и продажи, которые вы не увидели

Самый неудобный для оценки, но при этом часто самый крупный канал потерь — это ушедшие пользователи. Медленный отклик страницы или API напрямую превращается в отказы: часть посетителей интернет-магазина не дожидается загрузки страницы товара и уходит к конкуренту, часть пользователей SaaS-сервиса раздражается на подвисающий интерфейс и не продлевает подписку. Разбор влияния скорости загрузки на конверсию подробнее — в статье про ускорение загрузки сайта на VPS: там же логика применима и к времени ответа API, если бэкенд ждёт медленный SQL-запрос.

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

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

Где чаще всего теряются деньги: три конкретных источника

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

Отсутствующие индексы. Запрос без нужного индекса выполняется полным сканированием таблицы вместо точечного поиска. На маленькой таблице разницы не видно, на таблице в миллионы строк — разница может быть в сотни раз. Это самая частая и при этом самая дешёвая в исправлении причина: одна команда CREATE INDEX часто решает проблему, из-за которой до этого рассматривали апгрейд сервера. Подробнее о том, как индекс работает и когда он, наоборот, может замедлить запись — в статье как индекс ускоряет запрос и когда он его замедляет.

Плохо написанные запросы. Даже при наличии нужного индекса запрос может быть составлен так, что база не может его использовать: функция над индексированной колонкой в условии, SELECT * вместо нужных полей, запрос в цикле вместо одного с JOIN, ведущий % в LIKE. Разбор конкретных паттернов и того, как их находить через EXPLAIN и slow query log — в статье про медленные запросы MySQL, их причины и решение; методика разбора применима не только к MySQL.

Не настроенный пул соединений. Каждое новое соединение с базой — это накладные расходы на установку и авторизацию, и без пула приложение либо создаёт их заново на каждый запрос, либо упирается в лимит одновременных соединений под нагрузкой. Итог — рост задержек и ошибки вида "too many connections" именно в момент пиковой нагрузки, то есть именно тогда, когда цена простоя для бизнеса максимальна. Что такое connection pool и как его настроить — в статье что такое connection pool и почему без него база падает первой.

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

Методика: когда действительно нужно железо, а когда — оптимизация

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

Шаг 1 — найдите конкретных виновников, а не гадайте абстрактно. Включите лог медленных запросов (в MySQL — slow_query_log, в PostgreSQL — log_min_duration_statement) и посмотрите, какие именно запросы дают основную долю времени. Как правило, оказывается, что 80-90% проблемы создают буквально несколько запросов, а не вся база целиком.

Шаг 2 — по каждому найденному запросу оцените, что нужно для исправления: не хватает индекса (недорого и быстро), запрос переписывается на более эффективный (требует времени разработчика, но конечно), или это архитектурная проблема — например, аналитика бьёт по той же базе, что и продакшн-нагрузка (требует более серьёзного решения — вынести в отдельную реплику или отдельное хранилище).

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

Важная оговорка: методика не говорит "апгрейд не нужен никогда". Если база оптимизирована — индексы на месте, тяжёлые запросы переписаны, пул соединений настроен, — а нагрузка растёт из-за реального роста бизнеса и объёма данных, дополнительная память под буферы и более быстрый диск дают честный и оправданный эффект. Разница в том, что апгрейд должен идти после оптимизации, а не вместо неё — иначе вы платите за железо, которое компенсирует проблему, решаемую бесплатно.

Как посчитать это для своего проекта

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

Возьмите текущий счёт за сервер и оцените, на сколько вырос бы тариф при следующем апгрейде (обычно эта информация есть у хостинг-провайдера в виде списка планов). Это верхняя оценка "стоимости бездействия" за месяц — если проблема не в железе, а в запросах, вы платите эту разницу без необходимости.

Отдельно — по логу медленных запросов оцените, сколько конкретных запросов реально нужно исправить, и попросите разработчика (или сделайте сами, если умеете) честно прикинуть время на каждый: обычно это от 15-30 минут на простое добавление индекса до нескольких часов на переписывание сложного запроса с проверкой побочных эффектов.

Сравните две цифры не за один месяц, а за реалистичный горизонт — например, год. Ежемесячная переплата за железо умножается на 12 и продолжает расти вместе с данными; время на оптимизацию — это разовая инвестиция, которая с этого момента экономит и деньги на сервер, и нервы команды, и, возможно, часть уходящих из-за тормозов пользователей. В подавляющем большинстве случаев, когда причина медленной базы — конкретные необнаруженные запросы, оптимизация оказывается кратно дешевле по итоговому году, даже если стоимость часа разработчика выше стоимости лишнего гигабайта памяти в тарифе.

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

Частые вопросы