Услуга · SQL · схемы · DWH · ETL
Отчёт, который считается сорок минут, почти никогда не лечится добавлением оперативной памяти. Мы читаем планы запросов, разбираем схему и индексы, а потом строим хранилище и ETL, которые успевают к утру.
Симптомы
Если узнали хотя бы две — дело обычно не в железе. Ниже написано, что за каждой из них стоит на самом деле.
Отчётность
Сводный отчёт строится сорок минут, и никто не может объяснить почему
Причина почти всегда видна в плане запроса: последовательное чтение вместо индексного доступа, соединение вложенными циклами на большой выборке, сортировка, которой не хватило памяти. Мы работаем с планами, а не с догадками.
Ночная загрузка
ETL не успевает до утра, и утром бизнес открывает вчерашние цифры
Разбираем окно загрузки по шагам: что действительно долго, что можно считать инкрементально, что параллелить. Скрипт по расписанию превращается в пайплайн с ретраями и понятным статусом шага.
Наследство
Прошлый DBA ушёл, и схему целиком больше не понимает никто
Восстанавливаем модель данных по фактической базе: сущности, связи, ключи; отдельно помечаем то, что осталось от прошлых поколений и уже никем не пишется. Дальше знание живёт в описании и миграциях, а не в чьей-то голове.
Миграция
Переезжаем с MS SQL на PostgreSQL и не знаем, за что хвататься
Начинаем с инвентаризации: типы, процедуры и функции на T-SQL, представления, задания по расписанию и всё, что на них завязано в приложении. Перенос разбиваем на этапы с проверяемым результатом, а не переключаем систему за одну ночь.
Рост объёма
Данных стало больше, и то, что раньше работало, теперь мешает всем остальным
Разделяем контуры: транзакционная нагрузка остаётся на PostgreSQL или MS SQL, тяжёлые исторические агрегаты уезжают в отдельное хранилище. Аналитик перестаёт конкурировать за ресурсы с кассой и складом.
Что делаем
Треки независимы: можно взять только первый и остановиться на отчёте, а можно пройти всю цепочку — от разбора текущей базы до хранилища, из которого считается аналитика.
Обычно идут в этом порядке, но начать можно с любого
Работаем с тем, что уже есть: находим запросы, которые съедают время и ресурсы, и объясняем, почему они так себя ведут.
Проектируем модель данных под ваши инварианты: чтобы неверное состояние нельзя было записать, а не только «нельзя было ввести с формы».
Строим хранилище со слоями и пайплайны, которые можно перезапустить с середины, а не «запустить заново и подождать».
Инструменты, с которыми работаем в проектах
Вход
Первый шаг всегда один и тот же: фиксированная работа с фиксированным результатом. Отчёт остаётся у вас, даже если дальше вы решите ничего не менять или делать всё своими силами.
Короткий созвон: какая СУБД, какие процессы страдают, что уже пробовали. Что нужно от вас: read-only доступ и три самых медленных отчёта. Если продакшен закрыт — работаем на копии или по выгрузке структуры и статистики.
Собираем измеримое: планы проблемных запросов, статистику обращений, размеры таблиц и индексов, длительность шагов ночной загрузки. На этом шаге мы ещё ничего не советуем — только измеряем.
От симптома к причине: где виноват отсутствующий индекс, где — форма запроса, где — схема, а где блокировки. Отдельно отмечаем случаи, когда проблема не в базе, а в том, как её дёргает приложение.
Быстрые правки проверяем на копии и замеряем на одинаковых данных: план до, план после, время до, время после. Правку без замера мы не считаем сделанной работой.
Что чинить сейчас, что позже и что трогать не нужно. Каждый пункт — с оценкой трудоёмкости и ожидаемым эффектом, чтобы решение о бюджете принимали вы, а не мы за вас.
Диагностика3–5 дней
Фиксированная стоимость, считаем после короткого созвона: она зависит от размера базы, числа систем и того, к чему есть доступ. На выходе — отчёт с планами запросов до и после, разбором причин и планом работ с оценкой.
Для оптимизации, проектирования схем, переноса баз и построения хранилища фиксированного прайса нет: объём зависит от того, что уже написано и сколько систем на это опирается. Оценку даём после диагностики — из её же отчёта.
Информация на сайте не является публичной офертой. Стоимость и сроки фиксируются в договоре после диагностики. Гарантия — 2 недели на исправление ошибок, связанных с реализацией по техническому заданию.
Опыт
Хранилища, ETL и регламентированный учёт — это то, с чего начинался опыт основателя: 9+ лет в разработке, с 2015 года, значительная часть — на стороне данных.
DWH · ETL · BI
MS SQL · PostgreSQL · ClickHouse · Airflow
Хранилище, которое пережило две смены платформы и смену инструмента оркестрации. Каждый переход был ответом на конкретный профиль запросов, а не сменой моды.
Кейсы
В продуктовых проектах база — не приложение к коду, а его несущая часть. Три разбора, где это видно.
ERP · PostgreSQL 16
Единая шапка документа с per-type расширениями, граф связей «на основании», помесячная сквозная нумерация и CQRS-поиск на Elasticsearch. Схема меняется миграциями, а не руками в проде.
100+обратимых миграций на Goose
Разбор проекта →Логистика · MS SQL
MS SQL Server с версионированными миграциями под восемью сервисами и централизованное логирование Vector → Elasticsearch: видно не только «медленно», но и где именно.
16 ч → 9 минобработка ключевых процессов
Разбор проекта →Ритейл · расчёты
Скорость продаж на EMA со сглаживанием выбросов, потребность с сезонностью и страховым запасом, снимок shop_article_metrics, привязанный к JobId: любой расчёт можно повторить и объяснить.
9 вкладокжурнал разбивки расчёта
Разбор проекта →Результат
Не набор советов на созвоне, а артефакты в вашем репозитории, по которым работу можно продолжить без нас.
План и время до и после по каждому проблемному запросу, снятые на одинаковых данных. Видно, что именно изменилось и за счёт чего.
до / после · одинаковые данные
Описание модели данных: сущности, связи, ключи и ограничения. Отдельным списком — то, что осталось от прошлых поколений системы.
модель + пояснения
Каждое изменение схемы — обратимая миграция в вашем репозитории, применяемая из CI. Откат становится операцией, а не спасательной операцией.
Goose · up / down
Пайплайны лежат кодом рядом с проектом и разворачиваются как обычный релиз. Ретраи, идемпотентность, backfill за нужную дату.
Airflow · Python
Разбор решений с вашей командой: что мы поменяли, почему именно так и на что смотреть, когда данных станет вдвое больше.
созвон + документация
Фиксированная стоимость, считаем после короткого созвона: она зависит от размера базы, числа систем и того, к чему есть доступ. Срок — 3–5 рабочих дней, на выходе отчёт с планом работ. Отчёт остаётся у вас, даже если дальше вы решите ничего не менять.
Read-only доступ к базе или к её копии и три самых медленных отчёта. Планы запросов и статистику мы снимаем сами. Если доступ к продакшену закрыт, работаем на копии или по выгрузке структуры и статистики — это дольше, но возможно.
Мы не обещаем результат до того, как увидели план запроса. Диагностика нужна ровно для того, чтобы отделить случаи, где помогает индекс или переписанный запрос, от случаев, где нужно менять схему или выносить аналитику в отдельное хранилище. Оба вывода мы формулируем письменно и с обоснованием.
Да. Начинаем с инвентаризации: типы, процедуры и функции на T-SQL, представления, задания по расписанию и всё, что на них завязано в приложении. Перенос разбиваем на этапы с проверяемым результатом на каждом, а не переключаем систему за одну ночь.
Скрипт по расписанию не отвечает на вопросы «что упало», «на каком шаге» и «как перезапустить только этот кусок». В Airflow пайплайн — это код в репозитории: зависимости шагов, ретраи, идемпотентность и backfill за нужную дату. Мы переносили ETL с SSIS на Airflow и делали динамические DAG, чтобы новый источник не требовал копии пайплайна.
PostgreSQL закрывает и транзакционный контур, и заметную часть аналитики: партиционирование, индексы, материализованные представления. Колоночное хранилище оправдано, когда запросы регулярно сканируют большие исторические таблицы и мешают основной нагрузке. В проекте игрового холдинга хранилище прошло путь от MS SQL к PostgreSQL и затем к ClickHouse — по мере роста объёма и изменения профиля запросов.
Контакты
Разговариваем планами запросов, схемой и цифрами замеров. Если проблема окажется не в базе, скажем прямо и покажем, где она на самом деле. maincode — инженерная студия ИП Диденко М. С.
Смежные услуги
Граница простая: нужно построить систему, в которой данные рождаются, — это ERP; нужно добыть данные снаружи — это парсинг; нужно, чтобы существующие системы перестали расходиться, — это интеграции. Если ваша задача другая, всё равно напишите: скажем, к чему она ближе, или честно ответим, что она не наша.
Услуга
Когда данные нужно не только считать, но и порождать: документы, склад, финансы и статусы в одной учётной системе.
Услуга
Когда данные лежат в разных системах и расходятся: обмен с гарантией доставки, идемпотентностью и журналом, по которому видно, что доехало.
Услуга
Когда нужных данных внутри просто нет: сборщик, база и веб-интерфейс с фильтрами и выгрузкой в Excel.