Data engineering
OLTP vs OLAP: тест с множественным выбором
Суть Тест на синтез по всему юниту OLTP vs OLAP — row store против column store, column pruning, сжатие, векторизация, авария от аналитики на реплике и когда разделять хранилища.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбитеШесть вопросов, проходящих через весь юнит. Каждый отражает решение, которое вы принимаете на реальном архитектурном ревью, — не определение для пересказа, а компромисс, который надо взвесить, когда дашборд и путь оформления заказа делят одну базу.
Цель
Убедитесь, что вы связываете физический layout, множители column store, режим отказа «аналитика на реплике» и решение о разделении хранилищ — тот синтез, к которому вёл обзорный урок.
Викторина
Completed
Запрос считает SUM(total) по 40M строкам orders, у каждой по 50 колонок. Почему column store громит row store именно на этом запросе?
Heads-up Агрегату по всей таблице нужны почти все строки, поэтому искать нечего — планировщик всё равно делает sequential scan. Выигрыш в том, что читается меньше колонок, а не в индексе.
Heads-up Ни один движок не определяется кэшированием всего. Структурный выигрыш — в layout на диске (одна колонка непрерывно), что включает pruning, сжатие и векторизованные сканы даже с диска.
Heads-up Column store медленнее на одиночных записях, а не быстрее — запись трогает каждый файл колонки. Преимущество в сканах по колонкам, это совсем другая ось.
Викторина
Completed
Сервис A делает point lookup по id со скоростью 5k req/s; сервис B гоняет агрегат по колонкам тех же данных. Почему один layout не может хорошо обслуживать обоих?
Heads-up Бесплатного переключателя нет. Layout физический: row store хранит строки непрерывно, column store — колонки непрерывно. HTAP-системы пытаются это совместить, но платят реальную цену; один layout не может быть оптимален для обеих форм.
Heads-up Это не ручка скорости. Несоответствие структурное — row store читает каждый байт каждой строки для агрегата, и больше CPU не меняет того, что он читает 50 колонок ради 1.
Heads-up Размер таблиц — не различие. Различие в паттерне доступа: point lookup и мелкие записи против сканов всей таблицы по нескольким колонкам — противоположные цели оптимизации.
Викторина
Completed
На ClickBench из 100M строк ClickHouse хранит данные примерно в 9 GiB там, где Postgres нужно около 100 GiB. Почему column store сжимает настолько лучше и почему это расширяет разрыв в пропускной способности скана, а не просто экономит диск?
Heads-up Разница в размере от колоночного сжатия однотипных значений, а не от выброса индексов. Выигрыш в пропускной способности — от pruning плюс чтения куда меньшего объёма сжатых байтов, а не от обслуживания индексов.
Heads-up Для аналитических запросов, упёртых в скан, узкое место — I/O. Меньше байтов на диске — меньше байтов читать, поэтому сжатие напрямую умножает пропускную способность скана; это не просто экономия хранения.
Heads-up Сжатие страниц row store мешает int, string, timestamp и float на странице и даёт лишь ~1.5–3×. Колонка пакует один тип вместе, поэтому достигает 5–10× — layout-ы не эквивалентны.
Викторина
Completed
Дашборд growth-команды гоняет 90-дневный агрегат выручки против прод-реплики Postgres. Checkout p99 прыгает с 40ms до 2s, а replica lag растёт до 90s. Какую первопричину senior назовёт первой?
Heads-up Индекс не помогает 90-дневному агрегату по всей таблице — искать нечего. А симптом — замедление OLTP от вытеснения кэша и конкуренции, а не медленный запрос дашборда.
Heads-up Дашборд только читает, а записи идут на primary, не на реплику. Урон — вытеснение buffer cache и конкуренция за ресурсы на реплике плюс replica lag, а не заблокированные записи.
Heads-up Размер пула — не механизм. Даже один аналитический скан отравляет buffer cache и конкурирует за I/O на row store, рассчитанном на транзакционный working set.
Викторина
Completed
Продукт хочет 90-дневный дашборд выручки. Какую из четырёх архитектур senior выкатит и почему?
Heads-up Индексы чинят selectivity, а не объём скана. 90-дневному агрегату по всем странам нужны почти все строки, поэтому планировщик игнорирует индекс и всё равно сканирует — вы добавили стоимость записи без выигрыша на чтении.
Heads-up Ежечасный пересчёт всё равно гоняет разрушительный полный скан на реплике — checkout деградирует раз в час, а кэш устаревает между прогонами. Это лечит проблему layout как проблему представления.
Heads-up Непиковые часы сужают радиус поражения, но не чинят: скан всё равно вытесняет buffer cache и поднимает replica lag в окне, а дашборды «за последние 90 дней» редко по-настоящему непиковые. Фикс — отдельное хранилище, а не расписание.
Викторина
Completed
Команда предлагает HTAP-движок, чтобы обслуживать и транзакции, и аналитику на одной системе, утверждая, что это снимает нужду разделять хранилища. Какова senior-формулировка?
Heads-up Ни один физический layout не оптимален и для point-записей, и для сканов по колонкам. HTAP-системы держат внутри и row, и column представление и платят за их поддержку — они управляют напряжением, а не отменяют его.
Heads-up У HTAP есть реальные применения, где задержка данных должна быть почти нулевой, а эксплуатация двух систем слишком дорога. Это компромисс, а не ошибка — но он не стирает конкуренцию, мотивирующую разделение.
Heads-up Даже с HTAP вы часто всё равно кормите downstream-склады; а смысл CDC в дизайне с двумя хранилищами — изоляция. То, что HTAP меняет, где лежат данные, само по себе не устраняет конкуренцию, ради ухода от которой делалось разделение.
Итог
Сквозная линия юнита — одно решение: паттерн доступа задаёт layout. Point lookup и мелкие записи хотят row store; сканы всей таблицы по нескольким колонкам хотят column store, где pruning (читать ~6% байтов), сжатие 5–10× и векторизованное пакетное выполнение складываются в разрыв 10×–1000×, который не закроет ни один индекс. Классический senior-провал — аналитика на прод-реплике OLTP, где один скан вытесняет горячий buffer cache, конкурирует за I/O и поднимает replica lag. Фикс архитектурный — отдельный колоночный store, кормимый через CDC или ETL, — с принятием небольшой задержки данных ради изолированных хранилища, кэшей и failure domains. HTAP может управлять конкуренцией, но никогда её не отменяет.