Выберите тему — соберём контекст
Проектирование и оптимизация баз данных: PostgreSQL и MySQL, индексы и планы запросов, репликация, кэш на Redis и проверенное резервное копирование.
Почти все проблемы с базами данных проявляются одинаково: сначала «стало медленнее», потом «непонятно, что с этим делать». Ниже — типовые ситуации, с которыми приходят на аудит, и к чему они приводят.
На тестовых данных всё летало, а в продакшене появились сотни тысяч строк, и отчёты стали занимать секунды. Часто причина не в «слабом сервере», а в выборке, которая читает таблицу целиком, и в отсутствии нужного индекса.
Сначала это замечают пользователи, потом — руководство
Индекс добавляют под каждый медленный запрос, и со временем их становится больше, чем нужно. Каждый лишний индекс замедляет вставку и обновление и занимает место, а нужного составного индекса всё равно нет.
Запись медленнее, база больше, эффекта нет
Дамп снимается по расписанию, а восстановление никто не пробовал. Обнаруживается это в момент аварии, когда выясняется, что копия битая, неполная или восстанавливается дольше, чем бизнес готов ждать.
Риск реализуется ровно тогда, когда дороже всего
Структуру правят прямо в продакшене, потому что «надо быстро». Никто не помнит, какие изменения уже применены на каждом стенде, локальная база разработчика расходится с боевой, а откатить релиз нечем.
Разные окружения живут по разным правилам
Дубли строк, отрицательные остатки, ссылки на несуществующие записи — всё это ловится уже в отчётах или у клиента. Ограничения на уровне базы не заведены, поэтому приложение остаётся единственным «контролёром», а он не всегда прав.
Данные, которым нельзя доверять
Нет ответа на простые вопросы: сколько живёт самый долгий запрос, растут ли таблицы, успевает ли реплика, когда последний раз обновлялась статистика. Без метрик любое решение о масштабировании принимается наугад.
Реагируем на аварию вместо того, чтобы её видеть
Обе системы зрелые и справятся с большинством проектов. Разница проявляется на сложной доменной логике, аналитике и требованиях к целостности данных. Ниже — честные развилки, по которым мы выбираем.
| Критерий | PostgreSQL | MySQL |
|---|---|---|
| Тип нагрузки | Сложные аналитические запросы, отчёты, агрегации рядом с транзакционной нагрузкой | Преимущественно короткие транзакционные запросы, простые выборки по ключу |
| Целостность данных | Строгая типизация, богатый набор ограничений, отложенные проверки внешних ключей | Ограничения есть, но исторически часть проверок выполнялась неявно — зависит от режима SQL |
| Транзакции и блокировки | MVCC: читатели не блокируют писателей; уровень изоляции настраивается под задачу | В InnoDB чтение тоже не блокирует запись, но поведение и уровни изоляции отличаются от PostgreSQL |
| Расширения и типы | Расширения (например, для индексов по JSONB или геоданных), массивы, диапазоны, собственные типы | Ядро проще, расширяемость ограничена; для сложных типов чаще выносят логику в приложение |
| Изменение схемы | DDL транзакционен: изменение структуры можно откатить вместе с транзакцией | DDL не транзакционен так же, как в PostgreSQL: часть операций применяется необратимо |
| Команда и хостинг | Часто уже есть у команды; поддержка во всех крупных облаках и managed-сервисах | Огромная база специалистов, самый распространённый вариант в веб-хостинге и легаси-проектах |
| Когда выбираем | Сложная доменная логика, отчётность и аналитика, требования к целостности и типам | Простая модель данных, важна привычная инфраструктура и максимальная распространённость стека |
Если у вас уже есть база и команда, которая её знает, — это весомый аргумент остаться на ней. Смена СУБД сама по себе редко решает проблему производительности.
Разница между «тормозит» и «работает быстро» видна в плане выполнения запроса. Переключите режим, чтобы сравнить чтение таблицы целиком и поиск по составному индексу.
СУБД читает таблицу целиком и отбрасывает почти всё. Время растёт линейно вместе с объёмом таблицы — на тестовой базе этого не видно.
Seq Scan
Полный перебор таблицы вместо поиска по индексу
rows
Оценка числа строк расходится с фактом — статистика устарела
142 ms
При 10-кратном росте данных запрос станет пропорционально дольше
Составной индекс покрывает условие фильтрации целиком. Планировщик перестал читать лишние строки, и время перестало зависеть от размера таблицы.
Index Scan
Поиск по индексу вместо полного перебора
rows=12
Оценка совпала с фактом — статистика актуальна
0.038 ms
Время определяется глубиной индекса, а не объёмом таблицы
Seq Scan on orders (cost≈0.00..18334.00 rows≈1 width=64) (actual time=0.015..142.318 rows=12 loops=1)Index Scan using orders_customer_status_created_idx on orders (cost≈0.29..8.31 rows=12 width=64) (actual time=0.021..0.038 rows=12 loops=1)
Составной индекс: (customer_id, status, created_at)
Тот же индекс с обратным порядком столбцов для этого запроса уже не подойдёт: СУБД сможет использовать только его начало.
Объём подбирается под ситуацию: для нового проекта это проектирование схемы, для работающей системы чаще начинается с аудита и оптимизации запросов.
Структуру проектируем от запросов, которые приложение действительно выполняет: где нужна нормализация, где оправдана денормализация, какие ограничения должна держать сама база, а не только код приложения.
Что дальше
Покажем на вашей базе, что именно упирается в предел, и предложим порядок изменений с оценкой риска.
Заказать аудитУбираем дублирование там, где оно порождает расхождения, и не дробим структуру там, где это только усложняет запросы.
Внешние ключи, уникальность, проверки значений: база не даёт записать то, что противоречит модели, даже при ошибке в коде.
Деньги — точный числовой тип, не float. Даты — с часовым поясом. Строки — с явной длиной и кодировкой.
Каждое изменение структуры — файл миграции под контролем версий, который проходит ревью и может быть откачен.
Сначала измеряем: находим тяжёлые запросы, читаем их план выполнения, и только потом меняем индексы или сам запрос. Иначе оптимизация превращается в угадывание.
Что дальше
Покажем на вашей базе, что именно упирается в предел, и предложим порядок изменений с оценкой риска.
Заказать аудитПорядок столбцов определяется тем, как фильтрует и сортирует конкретный запрос, а не алфавитом.
Жадная загрузка связей в ORM вместо сотни отдельных запросов из цикла — типовая причина «медленной страницы».
Любое изменение подкреплено планом: видно, что перебор таблицы превратился в поиск по индексу.
Без своевременного обновления статистики планировщик выбирает плохой план даже при верных индексах.
Конкурентный доступ — источник самых неприятных дефектов: списание дважды, потерянное обновление, зависшая блокировка. Эти сценарии разбираются на этапе проектирования.
Что дальше
Покажем на вашей базе, что именно упирается в предел, и предложим порядок изменений с оценкой риска.
Заказать аудитОперация, меняющая несколько таблиц, выполняется целиком или не выполняется вовсе.
Читаем без блокировки там, где это допустимо; держим транзакции короткими, чтобы не собирать очередь ожиданий.
Повторная обработка платежа или вебхука не создаёт вторую операцию — защита на уровне ограничений базы.
Выбираем осознанно: где нужен строгий уровень, а где достаточно чтения зафиксированных данных.
Масштабирование начинается не с покупки более мощного сервера, а с вопроса «что именно упирается в предел». Кэш, реплики и партиционирование решают разные задачи.
Что дальше
Покажем на вашей базе, что именно упирается в предел, и предложим порядок изменений с оценкой риска.
Заказать аудитПовторяющиеся выборки и счётчики уходят из базы в кэш — основной источник снижения нагрузки на чтение.
Отчёты и тяжёлые выборки переносятся на реплику, чтобы не мешать транзакционной нагрузке.
Большие таблицы делятся по периоду, и запросы читают нужную часть вместо всей истории.
Устаревшие данные переносятся в архив по регламенту, а не удаляются навсегда «чтобы стало быстрее».
Резервная копия имеет ценность только тогда, когда из неё восстановились на реальном стенде и уложились в допустимое время. Это проверяется, а не предполагается.
Что дальше
Покажем на вашей базе, что именно упирается в предел, и предложим порядок изменений с оценкой риска.
Заказать аудитПолные и инкрементальные копии по расписанию, с хранением в отдельном месте от самой базы.
Регулярный тест: развернуть копию на отдельном стенде и убедиться, что она читается и полна.
Заранее известно, сколько занимает возврат в работу, — иначе в аварии решения принимаются вслепую.
Долгие запросы, блокировки, рост таблиц, отставание реплики — с оповещением до того, как это заметит клиент.
Учётная запись приложения не должна уметь удалять таблицы, а сотрудник не должен видеть чужие данные. Это настраивается в базе, а не только в приложении.
Что дальше
Покажем на вашей базе, что именно упирается в предел, и предложим порядок изменений с оценкой риска.
Заказать аудитУ приложения, у миграций и у разработчика — разные учётные записи с разным объёмом прав.
Приложению выдаются только те операции, которые ему действительно нужны.
Чувствительные поля шифруются, доступ к ним фиксируется в журнале, выгрузки ограничены.
База не смотрит в интернет: доступ только из защищённого контура или через туннель.
Начинаем с замеров, а не с изменений: пока не видно планов запросов и размеров таблиц, любая оптимизация — предположение.
Снимаем реальную картину: размеры таблиц, самые тяжёлые запросы, их планы, состояние индексов, статистика, настройки бэкапов. Смотрим код доступа к данным в приложении, включая связи ORM.
Отчёт с узкими местами и приоритетами
Описываем структуру, ограничения, индексы и связи под фактические сценарии работы. Отдельно фиксируем, какие данные растут быстро и что с ними будет через год.
Схема, миграции, состав индексов
Применяем изменения через миграции, переносим данные без остановки работы, сравниваем планы запросов до и после. Каждое изменение обратимо.
Изменения в продакшене с подтверждением
Настраиваем мониторинг, бэкапы и проверку восстановления. Передаём документацию по схеме и регламент действий при аварии.
Мониторинг, регламент, обученная команда
Вместо проверки «а не обработали ли мы уже этот платёж» в коде — уникальное ограничение в базе. Повторный запрос с тем же ключом просто не сможет создать вторую операцию, даже если придёт дважды одновременно.
ALTER TABLE payments
ADD CONSTRAINT payments_external_id_unique
UNIQUE (external_id);Когда два процесса меняют одну строку, второй должен дождаться первого, а не перезаписать результат. Advisory-блокировка берётся на время операции и снимается автоматически вместе с транзакцией.
-- PostgreSQL
SELECT pg_advisory_xact_lock(hashtext('order:42'));
-- MySQL: именованная блокировка на время транзакции
SELECT GET_LOCK('order:42', 5);Состав работ фиксируется до начала. Ниже — типовой набор; для действующей системы он сужается до того, что действительно даёт эффект.
Как начинается работа
Аудит базы — самостоятельный результат, а не «первый этап продажи разработки». Отчёт можно передать своей команде или другому подрядчику: мы не привязываем смету аудита к последующим работам.
Чтобы разговор о базе не превращался в обмен непонятными словами.
По умолчанию для новой разработки мы чаще предлагаем PostgreSQL: строгая типизация, транзакционный DDL и расширения упрощают жизнь на сложной доменной логике. MySQL остаётся разумным выбором, когда модель данных простая, команда уже работает с ним, а инфраструктура и хостинг заточены под него. Решение принимается по вашей нагрузке и опыту команды, а не по общему правилу.
Часто да. Индексы, устранение запросов из циклов (N+1), актуализация статистики и кэширование повторяющихся выборок дают эффект без изменения бизнес-логики. Если узкое место в самой модели данных — это выяснится на аудите, и тогда мы покажем, какие изменения нужны и чем они обойдутся.
Тем, что одни и те же данные начинают храниться в нескольких местах и рано или поздно расходятся. Денормализация оправдана, когда она решает конкретную проблему производительности, а согласованность копий поддерживается осознанно — например, триггером или фоновой задачей. Мы не используем её «для скорости» без такой поддержки.
Начинаем с замеров, а не с изменений. Смотрим планы тяжёлых запросов и размеры таблиц, находим, что именно упирается в предел: чтение с диска, блокировки, нехватка памяти под кэш страниц или неудачные запросы. Дальше порядок зависит от причины: индексы и запросы, затем кэш и реплики, затем партиционирование и архивация.
Регулярно и по регламенту, а не «когда будет время». Настроенный бэкап сам по себе ничего не гарантирует: важно хотя бы периодически разворачивать копию на отдельном стенде, проверять полноту данных и замерять время восстановления. Мы передаём этот регламент вместе с проектом.
И с тем, и с другим. Для действующей системы начинаем с аудита и точечных изменений, чтобы не останавливать работу. Для нового проекта проектируем схему до первой строки кода: переделывать структуру, когда в ней уже есть данные, заметно дороже.
Вы. Передаём схему с описанием, миграции, регламент бэкапов и мониторинг, объясняем, почему приняты те или иные решения. Можем остаться на сопровождении, но не строим систему так, чтобы без нас её нельзя было эксплуатировать.
Пришлите доступ к тестовой копии или опишите, что именно тормозит. На аудите покажем планы тяжёлых запросов, состояние индексов и бэкапов — и назовём порядок изменений с оценкой риска.
Cookie и аналитика
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie (Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия — от него можно отказаться. Подробнее: Политика использования cookie и обработка персональных данных.