Data engineering
OLTP vs OLAP: разделите нагрузку
Читать про аварию «аналитика на реплике» — не то же, что вызвать её, а потом починить. Поднимите row-store OLTP-базу, загоните в неё аналитический скан, пока checkout не деградирует, затем разделите нагрузку в колоночный store, кормимый через CDC/ETL, — и докажите каждый шаг измерениями.
Превратите ментальную модель юнита в воспроизводимый инженерный цикл: воспроизвести конкуренцию, измерить её, поднять правильный OLAP-layout, подключить feed и проверить и что аналитика ускорилась, и что транзакционный путь перестал страдать.
Воспроизведите отказ «аналитика на OLTP» на row store, затем перенесите аналитику в отдельный колоночный store, кормимый через CDC или ETL — доказав, что аналитический запрос резко ускорился И что транзакционная нагрузка больше не страдает, числами до/после при одинаковой нагрузке.
- Таблица до/после: время аналитического запроса, просканированные байты/страницы, OLTP p99, hit ratio buffer cache и replica lag — всё измерено при одинаковой нагрузке, не оценено.
- План колоночного store показывает, что он читает только колонки, на которые ссылается (pruning), и аналитический запрос минимум в 10× быстрее скана на row store.
- С аналитикой, унесённой с OLTP-инстанса, транзакционный p99 и hit ratio кэша возвращаются к baseline, пока идёт аналитический запрос — конкуренция исчезла.
- Абзац разбора: почему индекс не помог (selectivity против объёма скана), какое свойство column store дало большую часть ускорения и цену задержки данных, которую вы приняли за изоляцию.
- Добавьте сравнение сжатия: сообщите размер таблицы на диске в row store против колоночного store и разложите, какие колонки сжались сильнее и почему (низкая кардинальность, один тип).
- Сделайте CDC-feed почти real-time и измерьте сквозной лаг от коммита в OLTP до видимости в колоночном store; постройте график лага под всплеском записи.
- Добавьте guardrail, не дающий аналитическим запросам попадать на OLTP-инстанс (отдельная роль/endpoint, statement timeout или query router) и покажите, что он блокирует разрушительный скан.
- Поднимите вариант HTAP (например column-реплику или HTAP-движок) для той же нагрузки и сравните его с разделением на два хранилища по аналитической задержке, OLTP p99 под нагрузкой, свежести данных и операционной стоимости.
Это цикл, который вы запускаете на каждом реальном решении по архитектуре данных: воспроизвести конкуренцию, чтобы понять её, доказать, что индекс не починит агрегат по всей таблице, поднять правильный колоночный layout (денормализованный, низкокардинальный, пруньящийся), накормить его через CDC или ETL и проверить числами до/после, что аналитика ускорилась, а транзакционный путь перестал страдать — приняв ограниченное окно задержки данных ради изолированных хранилища, кэшей и failure domains. Сделав это раз на игрушке, делаешь продакшен-версию мышечной памятью.