'/%3e%3cpath%20d='M83.8172%20112C100.688%20112%20111.886%2098.2694%20112%2083.8882H44.0245C25.8409%2083.8882%2016.001%2094.3169%2016.001%20112H83.8172Z'%20fill='url(%23paint1_linear_101_577)'/%3e%3cpath%20d='M44.1725%2044.1138H16.0008C15.9465%2051.0963%2018.504%2058.2306%2024.2977%2064.0225L44.1706%2083.8881L52.8986%2075.3569L61.7636%2066.7019C63.2767%2065.2244%2063.2786%2062.7888%2061.7636%2061.3094L44.1725%2044.1138Z'%20fill='%233A5FFF'/%3e%3cpath%20d='M83.8248%2083.8862H111.996C112.051%2076.9037%20109.493%2069.7693%20103.7%2063.9774L83.8267%2044.1118L75.0986%2052.6431L66.2337%2061.2981C64.7206%2062.7756%2064.7187%2065.2112%2066.2337%2066.6906L83.8248%2083.8862Z'%20fill='%233A5FFF'/%3e%3cdefs%3e%3clinearGradient%20id='paint0_linear_101_577'%20x1='16.001'%20y1='30.055'%20x2='111.998'%20y2='30.055'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3clinearGradient%20id='paint1_linear_101_577'%20x1='111.998'%20y1='97.9451'%20x2='16.001'%20y2='97.9451'%20gradientUnits='userSpaceOnUse'%3e%3cstop%20stop-color='%2370ADFE'/%3e%3cstop%20offset='0.62'%20stop-color='%233A5FFF'/%3e%3c/linearGradient%3e%3c/defs%3e%3c/svg%3e)
OLAP и OLTP
Граница между OLTP и OLAP объясняет, почему обычно нельзя «просто построить аналитику в боевой базе» и зачем нужны отдельные хранилища.
OLTP
- Оптимизирован под короткие транзакции с строгими гарантиями ACID.
- Хранение по строкам — удобно для записи и точечных чтений.
- Объёмы: миллионы или сотни миллионов строк, не более.
- Примеры: PostgreSQL, MySQL, MS SQL Server, Oracle.
OLAP
- Оптимизирован под аналитические запросы по огромным таблицам.
- Колонное хранение и сжатие — гораздо быстрее агрегатов.
- Объёмы: миллиарды и триллионы строк.
- Примеры: BigQuery, Snowflake, Redshift, ClickHouse, Vertica.
Почему важно различать
- Тяжёлые аналитические запросы в OLTP роняют продукт.
- OLAP плохо подходит для записи единичных строк и онлайн-операций.
- В современных архитектурах эти роли разделяют намеренно и связывают пайплайнами.
Когда применять и когда нет
Применять
- При проектировании архитектуры данных компании
- При выборе базы под новый продукт или новый аналитический проект
- В обсуждении производительности отчётов и нагрузки на продукт
Не применять
- В очень маленьком проекте — обычно никаких отдельных OLAP-систем не нужно, всё помещается в одну OLTP-базу с view-аналитикой
Примеры применения
Команда продукта решает построить «дашборд для руководства» прямо в Postgres-базе сервиса. После пары запросов с агрегатами по миллионам строк продакшн «лёг» на 10 минут. Через неделю команда подняла отдельный ClickHouse, налила туда нужные данные через пайплайн, и нагрузка на продукт перестала зависеть от аналитики совсем. Один и тот же отчёт в Postgres шёл 45 секунд, в ClickHouse — 200 миллисекунд.
Часто задаваемые вопросы
В небольших объёмах — да, многие OLTP-базы тянут аналитические запросы поверх обычных индексов. Но при росте таблиц и запросов производительность быстро падает, и приходится разводить нагрузку на отдельные системы.
HTAP (hybrid transactional / analytical processing) — попытка сделать одну систему и для транзакций, и для аналитики. Примеры: TiDB, SingleStore. Это интересный класс решений, но в большинстве случаев пока компании всё равно предпочитают разделять OLTP и OLAP.