OLTP и OLAP: две стороны дата-инженерии, о которых стоит знать👨💻
В последние годы бизнес стал чётко понимать, насколько важны данные. Причём не только «что происходит прямо сейчас», но и вся история: как вёл себя пользователь месяц назад, когда упал спрос, какие товары чаще всего покупают в пятницу вечером.
Те компании, которые научились собирать и использовать такие данные, вырываются вперёд. Остальные — гадают на кофейной гуще.
Вот тут и появляются два типа баз, с которыми мы, как дата-инженеры, работаем каждый день: OLTP и OLAP.
🌐Представь, что ты заказываешь еду в приложении. Ты жмёшь кнопку — и заказ уходит в базу. Вводишь номер карты — сохраняется платёж. Все эти действия происходят в реальном времени — и проходят через OLTP.
OLTP (Online Transaction Processing) — это базы, которые: быстро записывают и обновляют информацию,справляются с тысячами одновременных действий, строго следят за целостностью данных/
Примеры: PostgreSQL, Oracle, MySQL
Они хорошо подходят для продуктовых систем, но не предназначены для анализа больших массивов данных.
💻 OLAP — это уже про аналитику
Теперь представь, что маркетологу нужно понять: как часто люди заказывают роллы по пятницам, сколько заказов в среднем в декабре и как это отличается от января.
Вот такие запросы уже не про одно событие, а про тенденции. Для них нужны другие базы — это OLAP.
OLAP (Online Analytical Processing) — это базы, которые: хранят исторические данные, быстро считают метрики и строят агрегаты,отлично подходят для аналитических дашбордов, BI-систем и витрин
Примеры: ClickHouse, Vertica, Redshift
Эти базы заточены под чтение по столбцам — поэтому отлично справляются с запросами вроде: “покажи средний чек за последние полгода по категориям”.
👨💻И вот что важно: на первый взгляд синтаксис в OLTP и OLAP может быть похож — SQL есть SQL, но «под капотом» они работают абсолютно по-разному.
Запрос, который в Oracle выполнится за 50 мс, может в ClickHouse грузиться минуту. И наоборот.
Поэтому одна из ключевых задач дата-инженера — писать оптимальные запросы под конкретную архитектуру. Тут важны не только JOIN’ы и WHERE’ы, но и как ты хранишь данные, как распределяешь, по каким полям сортируешь и партиционируешь.
А какими СУБД вы пользовались и какие возникали проблемы?
#sql #olap #oltp #clickhouse #postgresql #bigdata #analytics
В последние годы бизнес стал чётко понимать, насколько важны данные. Причём не только «что происходит прямо сейчас», но и вся история: как вёл себя пользователь месяц назад, когда упал спрос, какие товары чаще всего покупают в пятницу вечером.
Те компании, которые научились собирать и использовать такие данные, вырываются вперёд. Остальные — гадают на кофейной гуще.
Вот тут и появляются два типа баз, с которыми мы, как дата-инженеры, работаем каждый день: OLTP и OLAP.
🌐Представь, что ты заказываешь еду в приложении. Ты жмёшь кнопку — и заказ уходит в базу. Вводишь номер карты — сохраняется платёж. Все эти действия происходят в реальном времени — и проходят через OLTP.
OLTP (Online Transaction Processing) — это базы, которые: быстро записывают и обновляют информацию,справляются с тысячами одновременных действий, строго следят за целостностью данных/
Примеры: PostgreSQL, Oracle, MySQL
Они хорошо подходят для продуктовых систем, но не предназначены для анализа больших массивов данных.
💻 OLAP — это уже про аналитику
Теперь представь, что маркетологу нужно понять: как часто люди заказывают роллы по пятницам, сколько заказов в среднем в декабре и как это отличается от января.
Вот такие запросы уже не про одно событие, а про тенденции. Для них нужны другие базы — это OLAP.
OLAP (Online Analytical Processing) — это базы, которые: хранят исторические данные, быстро считают метрики и строят агрегаты,отлично подходят для аналитических дашбордов, BI-систем и витрин
Примеры: ClickHouse, Vertica, Redshift
Эти базы заточены под чтение по столбцам — поэтому отлично справляются с запросами вроде: “покажи средний чек за последние полгода по категориям”.
👨💻И вот что важно: на первый взгляд синтаксис в OLTP и OLAP может быть похож — SQL есть SQL, но «под капотом» они работают абсолютно по-разному.
Запрос, который в Oracle выполнится за 50 мс, может в ClickHouse грузиться минуту. И наоборот.
Поэтому одна из ключевых задач дата-инженера — писать оптимальные запросы под конкретную архитектуру. Тут важны не только JOIN’ы и WHERE’ы, но и как ты хранишь данные, как распределяешь, по каким полям сортируешь и партиционируешь.
А какими СУБД вы пользовались и какие возникали проблемы?
#sql #olap #oltp #clickhouse #postgresql #bigdata #analytics