Data engineering
OLTP vs OLAP: тест на свободное воспроизведение
Воспроизведение бьёт перечитывание. На каждый промпт скажите или запишите полный ответ по памяти, прежде чем открыть модельный, — усилие припоминания и закрепляет разделение нагрузок.
Восстановите хребет юнита — почему layout следует за паттерном доступа, три множителя column store, почему индекс не спасёт агрегат, авария на реплике и фикс через разделение хранилищ — не подглядывая в урок.
- 01Почему OLTP и OLAP нужны противоположные физические layout-ы и какой каждый?
- 02Назовите три множителя, делающих column store быстрее row store на аналитике, и примерно насколько велик совокупный разрыв.
- 03Коллега спрашивает, почему нельзя просто добавить индекс, чтобы 90-дневный агрегат выручки на Postgres стал быстрым. Объясните.
- 04Почему запуск дашборда аналитики на прод-реплике — авария, ждущая своего часа, и какова правильная архитектура?
- 05Почему OLTP-схема остаётся нормализованной, а OLAP-target денормализован, и почему это не противоречие?
- 06Что такое HTAP и почему он не отменяет нужду думать о разделении OLTP/OLAP?
Если вы смогли восстановить каждый ответ по памяти, вы держите хребет юнита: паттерн доступа диктует layout (row store для point-записей, column store для сканов); column store выигрывает за счёт pruning, сжатия 5–10× и векторизации, складывающихся в разрыв 10×–1000×, который не закроет ни один индекс; OLTP нормализует, а OLAP денормализует, потому что каждый соответствует своей нагрузке; аналитика на прод-реплике — авария, потому что один скан вытесняет buffer cache, конкурирует за I/O и поднимает lag; а фикс — отдельный колоночный store, кормимый через CDC/ETL, где HTAP управляет конкуренцией — но никогда её не отменяет.