#oltp — Public Fediverse posts

HTAP внутри OLTP: как мы строили векторизованный движок с самого начала

Как встроить векторизованный движок в OLTP-ядро с нуля — без отдельного аналитического слоя. Разбираем PhysicalType, SelectionVector, RowToColumnBridge, SIMD на листовых страницах B-Tree и Hash Join. Бенчмарк на 2,25 млн строк: от 1.22× на простых агрегатах до 2.67× на GROUP BY.

https://habr.com/ru/articles/1032894/

#htap #векторизация #база_данных #simd #btree #Hash_Join #rust #oltp

Buffer Pool и Clock-sweep: как мы боремся с cache pollution и p99 latency

Один аналитический запрос способен испортить p99 latency всего OLTP-трафика — на время, пока горячий рабочий набор не прогреется заново с диска. Это cache pollution, и с ним рано или поздно сталкивается любая СУБД с честным LRU. Разбираем, как мы решили эту проблему в нашем OLTP-движке: почему выбрали Clock-sweep вместо LRU, как BufferRing изолирует полные сканы от горячих данных, и почему no-steal — это не стилистический выбор, а требование корректности recovery. С кодом, инвариантами и честными оговорками про то, что ещё не сделано.

https://habr.com/ru/articles/1030822/

#buffer_pool #clock_sweep #cache_pollution #lru #eviction_algorithm #oltp #p99_latency #nosteal #wal #backpressure

Как мы строим OLTP-ядро: от API-контрактов до eBPF-проб

В статье показываем контракты будущей OLTP-СУБД: как разделены слои ядра, зачем нужен per-tablespace page size, почему конфигурация уходит в adaptive tuning и как мы встраиваем USDT/eBPF-наблюдаемость прямо в бинарник.

https://habr.com/ru/articles/1022506/

#oltp #субд #базыданных #rust #ebpf #usdt #observability #postgresql_compatibility #storage_engine #adaptive_tuning

Как мы строим OLTP-ядро: от API-контрактов до eBPF-проб

В статье показываем контракты будущей OLTP-СУБД: как разделены слои ядра, зачем нужен per-tablespace page size, почему конфигурация уходит в adaptive tuning и как мы встраиваем USDT/eBPF-наблюдаемость прямо в бинарник.

https://habr.com/ru/articles/1022506/

#oltp #субд #базыданных #rust #ebpf #usdt #observability #postgresql_compatibility #storage_engine #adaptive_tuning

Как мы строим OLTP-ядро: от API-контрактов до eBPF-проб

В статье показываем контракты будущей OLTP-СУБД: как разделены слои ядра, зачем нужен per-tablespace page size, почему конфигурация уходит в adaptive tuning и как мы встраиваем USDT/eBPF-наблюдаемость прямо в бинарник.

https://habr.com/ru/articles/1022506/

#oltp #субд #базыданных #rust #ebpf #usdt #observability #postgresql_compatibility #storage_engine #adaptive_tuning

Как я проектирую OLTP-БД с нуля: принципы, trade-off'ы и архитектурные решения

Почему эксплуатация современных баз данных всё чаще напоминает сборку сложного карточного домика, я уже разбирал в прошлых статьях. Теперь самое интересное: как построить движок, чтобы этих проблем избежать. В этой статье я открываю капот своей OLTP-базы данных, которую пишу с нуля на Rust. Это не обзор готового коробочного решения, а честный рассказ про инжиниринг на раннем этапе. Я покажу, как абстрактные идеи вроде «fail-closed контрактов» превращаются в работающий код, почему я выбрал UNDO-log MVCC вместо Multi-version Heap и зачем всё это упаковывается в PostgreSQL-wire протокол. Архитектура ещё подвижна, и сейчас — лучшее время, чтобы обсудить её с теми, кто каждый день эксплуатирует БД в продакшене. Заглянуть под капот движка

https://habr.com/ru/articles/1014098/

#базы_данных #СУБД #архитектура_бд #Rust #OLTP #MVCC #undolog #PostgreSQL #разработка_субд #system_design

[Перевод] MariaDB 12.3: binlog внутри InnoDB

Коротко для ленивых В MariaDB 12.3 binlog можно хранить внутри InnoDB через binlog_storage_engine=innodb . Главный эффект: вместо двух fsync() на commit остаётся один, поэтому на write-heavy нагрузке резко растут TPS и снижается tail latency. В тестах из статьи прирост на полном durability-профиле составил примерно 2.4x–3.3x . Backup, restore и ресинк реплик становятся проще, потому что binlog и данные теперь консистентны на уровне одного механизма хранения. Цена за это: обязателен GTID, Galera пока не поддерживается, а innodb_log_file_size нужно подбирать внимательнее из-за роста объёма redo. Если у вас обычная схема primary + async replica на InnoDB, эту возможность точно стоит хотя бы протестировать.

https://habr.com/ru/articles/1011298/

#MariaDB_123 #InnoDB #binlog #GTID #репликация #производительность_SQL #crash_recovery #fsync #OLTP

Определение фактического профиля нагрузки в PostgreSQL и динамические состояния БД

Привет, ХАБР! Я Владимир Хаймин , эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить, что она ведет себя как-то иначе? Как определить фактический профиль нагрузки OLAP или OLTP и выразить это через метрики, пригодные для событийного и графического мониторинга? Эта статья является скорее исследовательской в области Data Science в прикладном контексте PostgreSQL. Data Science – это не только задачи ИИ: (ML, LLM,..), но прежде всего математика. Мы используем регрессивные методы для получения некоторых нужных нам параметров исходя из табличных рекомендованных данных. Также мы делаем упор на исследование состояния БД на основе статистики динамики ожиданий. Задача, несмотря на ее простой смысл, в решении оказалась не такой простой, и мы в итоге работали над ней довольно долго, хоть и в фоновом режиме. Также обратились к студенческому сообществу и провели по этой теме Хакатон ВТБ х Башня , прошедший в МГТУ им. Баумана 27 ноября 2025 года. В нем приняли участие студенты и выпускники НИУ ВШЭ, СПбГУ, ВКА им. А.Ф. Можайского, РАНХИГС, Московского Политехнического университета, НИТУ МИСИС, а также уже действующие архитекторы и администраторы БД. У команд было всего три дня на решение задачи, и хотя полностью её не удалось выполнить никому, совокупный результат всех участников позволил сформировать корректное решение. Результат именно этих работ я и изложил в статье и обязательно буду упоминать команды и авторов интересных идей, о которых пойдет речь.

https://habr.com/ru/companies/vtb/articles/1011188/

#postgresql #postgresql_performance #olap #oltp #htap

Определение фактического профиля нагрузки в PostgreSQL и динамические состояния БД

Привет, ХАБР! Я Владимир Хаймин , эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить, что она ведет себя как-то иначе? Как определить фактический профиль нагрузки OLAP или OLTP и выразить это через метрики, пригодные для событийного и графического мониторинга? Эта статья является скорее исследовательской в области Data Science в прикладном контексте PostgreSQL. Data Science – это не только задачи ИИ: (ML, LLM,..), но прежде всего математика. Мы используем регрессивные методы для получения некоторых нужных нам параметров исходя из табличных рекомендованных данных. Также мы делаем упор на исследование состояния БД на основе статистики динамики ожиданий. Задача, несмотря на ее простой смысл, в решении оказалась не такой простой, и мы в итоге работали над ней довольно долго, хоть и в фоновом режиме. Также обратились к студенческому сообществу и провели по этой теме Хакатон ВТБ х Башня , прошедший в МГТУ им. Баумана 27 ноября 2025 года. В нем приняли участие студенты и выпускники НИУ ВШЭ, СПбГУ, ВКА им. А.Ф. Можайского, РАНХИГС, Московского Политехнического университета, НИТУ МИСИС, а также уже действующие архитекторы и администраторы БД. У команд было всего три дня на решение задачи, и хотя полностью её не удалось выполнить никому, совокупный результат всех участников позволил сформировать корректное решение. Результат именно этих работ я и изложил в статье и обязательно буду упоминать команды и авторов интересных идей, о которых пойдет речь.

https://habr.com/ru/companies/vtb/articles/1011188/

#postgresql #postgresql_performance #olap #oltp #htap

Определение фактического профиля нагрузки в PostgreSQL и динамические состояния БД

Привет, ХАБР! Я Владимир Хаймин , эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить, что она ведет себя как-то иначе? Как определить фактический профиль нагрузки OLAP или OLTP и выразить это через метрики, пригодные для событийного и графического мониторинга? Эта статья является скорее исследовательской в области Data Science в прикладном контексте PostgreSQL. Data Science – это не только задачи ИИ: (ML, LLM,..), но прежде всего математика. Мы используем регрессивные методы для получения некоторых нужных нам параметров исходя из табличных рекомендованных данных. Также мы делаем упор на исследование состояния БД на основе статистики динамики ожиданий. Задача, несмотря на ее простой смысл, в решении оказалась не такой простой, и мы в итоге работали над ней довольно долго, хоть и в фоновом режиме. Также обратились к студенческому сообществу и провели по этой теме Хакатон ВТБ х Башня , прошедший в МГТУ им. Баумана 27 ноября 2025 года. В нем приняли участие студенты и выпускники НИУ ВШЭ, СПбГУ, ВКА им. А.Ф. Можайского, РАНХИГС, Московского Политехнического университета, НИТУ МИСИС, а также уже действующие архитекторы и администраторы БД. У команд было всего три дня на решение задачи, и хотя полностью её не удалось выполнить никому, совокупный результат всех участников позволил сформировать корректное решение. Результат именно этих работ я и изложил в статье и обязательно буду упоминать команды и авторов интересных идей, о которых пойдет речь.

https://habr.com/ru/companies/vtb/articles/1011188/

#postgresql #postgresql_performance #olap #oltp #htap

Определение фактического профиля нагрузки в PostgreSQL и динамические состояния БД

Привет, ХАБР! Я Владимир Хаймин , эксперт по системам управления базами данных PostgreSQL в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер нагрузки определяется исходно в архитектуре проекта. Но если система определена архитектором как OLTP, но в действительности может вести себя в некоторые периоды времени как OLAP. Нормально ли такое поведение, и каким образом мы можем определить, что она ведет себя как-то иначе? Как определить фактический профиль нагрузки OLAP или OLTP и выразить это через метрики, пригодные для событийного и графического мониторинга? Эта статья является скорее исследовательской в области Data Science в прикладном контексте PostgreSQL. Data Science – это не только задачи ИИ: (ML, LLM,..), но прежде всего математика. Мы используем регрессивные методы для получения некоторых нужных нам параметров исходя из табличных рекомендованных данных. Также мы делаем упор на исследование состояния БД на основе статистики динамики ожиданий. Задача, несмотря на ее простой смысл, в решении оказалась не такой простой, и мы в итоге работали над ней довольно долго, хоть и в фоновом режиме. Также обратились к студенческому сообществу и провели по этой теме Хакатон ВТБ х Башня , прошедший в МГТУ им. Баумана 27 ноября 2025 года. В нем приняли участие студенты и выпускники НИУ ВШЭ, СПбГУ, ВКА им. А.Ф. Можайского, РАНХИГС, Московского Политехнического университета, НИТУ МИСИС, а также уже действующие архитекторы и администраторы БД. У команд было всего три дня на решение задачи, и хотя полностью её не удалось выполнить никому, совокупный результат всех участников позволил сформировать корректное решение. Результат именно этих работ я и изложил в статье и обязательно буду упоминать команды и авторов интересных идей, о которых пойдет речь.

https://habr.com/ru/companies/vtb/articles/1011188/

#postgresql #postgresql_performance #olap #oltp #htap

Контракт вместо настроек: чего я жду от OLTP-БД

После первой статьи в комментариях несколько раз прозвучало примерно одно и то же: "Всё правильно, но это же про любую зрелую СУБД — что с этим делать?" Я думал над этим вопросом несколько недель. И в итоге решил не искать ответ в виде "возьмите правильный инструмент X" — а попробовать честно сформулировать: какими свойствами OLTP-БД должна обладать сама по себе , независимо от того, насколько хорош ваш оператор, консультант или runbook. Что такое "контракт" — и почему это не маркетинг Попробую объяснить не через определение, а через ощущение. Когда вы покупаете автомобиль, вы не читаете инструкцию к тормозам каждое утро. Вы просто знаете: нажал педаль — машина тормозит. Это контракт . Он не зависит от того, правильно ли вы настроили тормозную жидкость этим утром или не забыли включить "режим торможения" в меню.

https://habr.com/ru/articles/1007602/

#postgresql #rust #data_base #oltp #hiload #system_design #субд

Мы знаем как готовить БД. Но индустрия изменилась: что бы я заложил в OLTP-БД с нуля

Обычно мы используем СУБД как инструмент: учитываем нюансы синтаксиса, оптимизатора, утилит и поведения движка — и решаем прикладные задачи. Но недавно, разворачивая очередной PostgreSQL‑кластер для продакшена, я поймал себя на мысли: не слишком ли много всего нужно поднять вокруг PostgreSQL, чтобы система работала одновременно безопасно и предсказуемо по производительности?

https://habr.com/ru/articles/1003102/

#базы_данных #sql_server #postgresql #oltp #администрирование_баз_данных #latency #MVCCAutovacuum

Считаем ресурсы под PostgreSQL

Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто). Q: Для кого эта статья? A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса. Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет» A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте. В статье вы получите пошаговый расчёт диска, RAM, CPU и базовые рекомендации по конфигу PostgreSQL, а также в подарок готовый промпт для ИИ, если захотите делегировать все расчёты нейромозгу. Ну давай считать

https://habr.com/ru/articles/995722/

#PostgreSQL #расчёт_ресурсов #sizing_базы_данных #OLTP #OLAP #shared_buffers #max_connections #connection_pool #PGTune #database_per_service

Считаем ресурсы под PostgreSQL

Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто). Q: Для кого эта статья? A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса. Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет» A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте. В статье вы получите пошаговый расчёт диска, RAM, CPU и базовые рекомендации по конфигу PostgreSQL, а также в подарок готовый промпт для ИИ, если захотите делегировать все расчёты нейромозгу. Ну давай считать

https://habr.com/ru/articles/995722/

#PostgreSQL #расчёт_ресурсов #sizing_базы_данных #OLTP #OLAP #shared_buffers #max_connections #connection_pool #PGTune #database_per_service

Считаем ресурсы под PostgreSQL

Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто). Q: Для кого эта статья? A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса. Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет» A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте. В статье вы получите пошаговый расчёт диска, RAM, CPU и базовые рекомендации по конфигу PostgreSQL, а также в подарок готовый промпт для ИИ, если захотите делегировать все расчёты нейромозгу. Ну давай считать

https://habr.com/ru/articles/995722/

#PostgreSQL #расчёт_ресурсов #sizing_базы_данных #OLTP #OLAP #shared_buffers #max_connections #connection_pool #PGTune #database_per_service

Считаем ресурсы под PostgreSQL

Не так давно на моей текущей работе впервые за весь мой немногочисленный 4-летний опыт бэкендера понадобилось для нового микросервиса рассчитывать ресурсы под PostgreSQL для данного сервиса. Раньше для меня данная тема было чем-то, чем занимаются DevOps/DBA и никогда прежде не задумывался и не исследовал информацию о том, как качественно рассчитать необходимые ресурсы, чтобы бизнесу не пришлось переплачивать за очень дорогие железки лишние деньги, чтобы потом оказалось, что от купленных мощностей в реальности используется 20-40% (опыт на нескольких работах показывает, что такое случается ну очень часто). Q: Для кого эта статья? A: Да в целом для любых технических специалистов, которые так или иначе взаимодействуют с технической поддержкой PostgreSQL и которым впервые нужно для новой БД (например, под микросервис) и сформулировать задачу для DevOps команды на поднятие СУБД для вашего сервиса. Q: «Зачем мне это? Ну прикину я на глаз, что здесь нужно 50ГБ диска, 64ГБ RAM и нормально поедет» A: Очень часто в условиях микросервисной архитектуры используется парадигма database per service и в таком случае нельзя просто запросить максимально мощную виртуальную машину. Ресурсы стоят много денег, инфраструктура должна масштабироваться, а значит необходимо уметь определять, какой именно мощности ВМ требуется и какие параметры PostgreSQL следует задать на старте. В статье вы получите пошаговый расчёт диска, RAM, CPU и базовые рекомендации по конфигу PostgreSQL, а также в подарок готовый промпт для ИИ, если захотите делегировать все расчёты нейромозгу. Ну давай считать

https://habr.com/ru/articles/995722/

#PostgreSQL #расчёт_ресурсов #sizing_базы_данных #OLTP #OLAP #shared_buffers #max_connections #connection_pool #PGTune #database_per_service

“Heeey, I’m using that!” 😅

Ants Aasma digs into OLTP lock contention in PostgreSQL—why it happens, how isolation levels, latency, and concurrency control affect it, and how to fix it without breaking correctness.

#PostgreSQL #P2D2 #OLTP #Performance

Benchmarking lead Jeb Miller, who recently joined MariaDB Foundation after over two decades at MySQL, on "Why sysbench‑tpcc results on outdated hardware should not be presented as a valid OLTP vendor comparison" https://mariadb.org/why-sysbench%E2%80%91tpcc-results-on-outdated-hardware-should-not-be-presented-as-a-valid-oltp-vendor-comparison/ #mariadb #opensource #database #mysql #percona #tpcc #oltp

Ah, the classic tale of #OLTP vs #OLAP, now with an extra layer of buzzword soufflé 🥱. Apparently, it's groundbreaking news that OLAP loves big batches, and they cannot lie 🤷‍♂️. But fear not, dear reader, #MooseStack is here to save the day, because setting up #Redpanda #streaming buffers is everyone's idea of a good time 🙄.
https://www.fiveonefour.com/blog/optimizing-writes-to-olap-using-buffers #buzzwords #HackerNews #ngated

Что для OLTP хорошо, то для OLAP — смерть: ликбез и выбор серверов

Вот скажите мне, хабравчане, в чём сила? Разве в деньгах? Вот и финдиректор говорит, что в деньгах. А я вот думаю, что сила в данных: у кого данные, тот и сильней! Техгиганты, вроде Google (Alphabet), Meta (признана экстремистской в России) и Яндекса, получают огромную прибыль с монетизации пользовательских данных; менее очевидные Spotify, OZON и т.п. тоже неплохо зарабатывают на данных и рекламе. Банки каждую секунду проводят сотни тысяч транзакций, небольшие интернет-магазины собирают кучу телеметрии, а социальные сети крутят бесконечные алгоритмические фиды, чтобы вы смотрели свою персональную ленту с котиками и мемами. Каждый клик, каждое движение мышкой, каждый свайп или тап по экрану — это запись в базе данных. И да, серверы давно умеют с этим всем работать. И вот есть у бизнеса база данных, зачем тогда изобретать ложку для супа отдельные подходы для работы с данными в ней? Выбираешь что-то оптимальное/лучшее — и радуешься жизни. А вот зачем. Для транзакций в реальном времени нужна одна система — OLTP (Online Transaction Processing) , а для аналитики другая — OLAP (Online Analytical Processing) . OLTP похож на Соника — он всегда в движении, стремительно мчится вперёд, реагирует на каждое препятствие и собирает колечки. А OLTP — отрабатывает каждую транзакцию быстро и предсказуемо. OLAP же напоминает Кирби — он втягивает в себя всё, что попадётся — горы предметов, врагов, целые миры. А OLAP поглощает массивы данных — миллионы и миллиарды строк, чтобы потом переварить их и превратить в осмысленный отчёт. Дропдаун

https://habr.com/ru/companies/servermall/articles/948686/

#oltp #oltpсистемы #olap #olapкубы #htap #серверы #базы_данных #аналитика_данных #itинфраструктура #субд

Как YDB изолирует OLTP и OLAP

Привет, Хабр! Меня зовут Олег Доронин, и мы с командой делаем СУБД Яндекса, которая называется YDB. Каждый транзакционный запрос к базе данных обычно работает с небольшим набором строк и быстро отрабатывает за единицы или десятки миллисекунд, но таких запросов каждую секунду поступает огромное количество. А вот аналитические запросы обычно выполняются не так часто, но каждый из них может требовать обработки вплоть до всех строк в одной или нескольких таблицах. Такие запросы могут выполняться секунды, минуты, или даже часы в зависимости от объёмов данных и сложности запрошенных вычислений. Чтобы эти два принципиально разных паттерна нагрузки не мешали друг другу, гибридным базам данных важно изолировать транзакционную нагрузку от аналитической. Под катом я расскажу, как мы сделали в YDB компоненты для управления смешанной нагрузкой, которые изолируют миллионы RPS от аналитики, и как менеджер смешанной нагрузки устроен внутри.

https://habr.com/ru/companies/yandex/articles/935506/

#workload_manager #ydb #sql #highload #oltp #olap #htap

🧙‍♂️ One does not simply build reports on OLTP data…

This week on The Drill Down with Ahmad & James, our special guest
Kristyna Ferris will be presenting a session titled "The Fellowship of the Star Schema: Transforming OLTP Data for Power BI"

🛠️ This session is packed with:
- Clear distinctions between OLTP & OLAP
- Tips for building Power BI-ready models
- A sprinkle of Slowly Changing Dimension magic

💡Whether you’re a data wizard 🧙, business hobbit 🧝‍♀️, or SQL ranger 🏹 — this is your quest.

🗓️ Join us LIVE on LinkedIn | Wednesday, July 2nd @ 2PM Central
https://lnkd.in/eWh4SsBb

#TheDrillDown #MicrosoftFabric #PowerBI #DataEngineering #DataTransformation #DataAnalytics #BusinessIntelligence #StarSchema #OLTP #KristynaFerris

Что такое OLTP: просто о сложном

Часто начинающие разработчики сталкиваются с проблемой непонимания принципов работы устоявшихся решений или технологий. А старшие товарищи простыми словами не могут объяснить, как им кажется «простых истин». Это произошло и с OLTP, так что я решил простыми словами объяснить принципы работы важнейшей для современной экономики технологии. Что же такое OLTP?

https://habr.com/ru/articles/922528/

#oltp #базы_данных #транзакции #Online_Transaction_Processing #оперативная_обработка_транзакций

Как мы заменили сотни Join’ов на один РТ-процессинг с 1kk RPS

Как связаны скидки, пользовательские пути и огромные массивы данных в Яндекс Рекламе? Привет, Хабр! Меня зовут Максим Стаценко, я работаю с базами данных и яростно в них копаюсь с 2010 года, а в Big Data — с 2016. Сейчас работаю в Яндексе в DWH поиска и рекламы. Мы работаем с ОЧЕНЬ большими данными. Каждый день миллионы пользователей видят рекламу Яндекса, а наши системы обрабатывают огромные объёмы данных. Чтобы реклама работала эффективно, нам нужно в каждый момент времени иметь максимально полную информацию об истории жизни рекламного объявления, а значит нужно каким-то образом передавать данные от одного события к другому внутри рекламной воронки. Расскажу, как мы решали эту проблему.

https://habr.com/ru/companies/oleg-bunin/articles/884560/

#ytsaurus #mapreduce #olap #oltp #антифрод #распределенные_системы #оптимизация #обработка_данных #хранилища_данных

I've been following the #ClickHouse open source project, its amazing speed benchmarks and its adoption in the #observability domain.

Check out this month's OpenObservability Talks episode for a deep dive
https://medium.com/p/2004160b2f5e/

#database #analytics #OLTP #opensource

Wow - https://PGConf.DE (Die Deutsche PostgreSQL Konferenz 2025) had an excellent turnout of 347 attendees, the largest ever for PostgreSQL Conference Germany! Our team were proud bronze sponsors for the event, and we're very much looking forward to the 2026 edition of the conference. Till then 🐘

See the wrap-up for the conference: https://www.postgresql.eu/events/pgconfde2025/news/conference-wrap-up-169/

#berlin #germany #tech #techevent #postgresql #postgres #data #datascience #metrics #timeseries #geospatial #analytics #olap #oltp

Денежные переводы в SQL

Переводим деньги в SQL В этом посте я покажу распространённые стратегии обработки переводов между счетами, сосредоточив внимание на согласованности данных, уровнях изоляции и компромиссах. Мы будем использовать упрощённые SQL и Java фрагменты с комментариями.

https://habr.com/ru/articles/908198/

#sql #acid #oltp #isolation #isolation_levels #isolation_level

https://blog.gslin.org/archives/2025/05/08/12389/postgresql-18-%e7%9a%84-async-i-o/

PostgreSQL 18 的 async i/o

#async #database #i/o #input #io #io_uring #linux #oltp #output #performance #pg #pgsql #postgresql #rdbms #read #speed #stream

Почему сложно разработать OLAP-базу данных, если у тебя уже есть OLTP

Это адаптированная для Хабра расшифровка доклада Алексея Дмитриева, директора аналитической платформы YDB DWH, которую создаёт команда Yandex Cloud, — компонента нашей гибридной базы данных YDB для обработки аналитических нагрузок. Когда проект только начинался, у нас было много наработок, которые мы успешно переиспользовали в других проектах. Но оказалось, что OLAP‑нагрузка так сильно отличается от OLTP, что за три года пришлось практически написать по ещё одной реализации многих частей системы. Под катом история о том, почему на рынке так мало гибридных баз данных класса Hybrid Transactional and Analytical Processing (HTAP) и какие сложности стоят на пути их разработки.

https://habr.com/ru/companies/yandex_cloud_and_infra/articles/898716/

#ydb #htap #olap #oltp

Как организовать анализ большого объема данных в реальном времени

С ростом сложности ИТ-систем и задач аналитики изменяются требования и к возможностям инструментов. Для многих сценариев приоритетными становятся решения, которые могут работать как с историческими данными, так и с теми, которые обновляются в реальном времени. То есть аналитикам все чаще нужен инструмент, работающий на стыке возможностей транзакционных и аналитических (OLAP и OLTP) систем. Меня зовут Николай Карлов. Я директор инновационных проектов в VK Tech. В этой статье я расскажу, что такое HTAP-системы, какие преимущества они предоставляют, и познакомлю с нашей колоночной СУБД Tarantool Column Store, которая реализует HTAP-обработку. Статья подготовлена по мотивам вебинара «Анализируем данные в Real-time». Его вы можете посмотреть здесь .

https://habr.com/ru/companies/vk/articles/832584/

#tarantool #архитектура #отказоустойчивость #olap #oltp #tarantool_column_store

Оценка потенциальной производительности информационных систем на задачах OLTP

Все мы сегодня наблюдаем неприятное явление деградации эффективности ПО. Эффективность проседает во всём, от неэффективного пользовательского интерфейса и до того, в чём компьютеры, вроде бы, просто обязаны быть самыми быстрыми, то есть в массовых задачах повседневной обработки информации. Решение задачи повышения производительности ПО не может быть получено без понимания, а на что мы в принципе можем рассчитывать? Именно такую отправную точку и предлагается рассмотреть в данном тексте. Далее показаны потенциальные возможности ПО на самых массовых на сегодня задачах, заключающихся во взаимодействии оператора с информационными системами. Англоязычное название этой группы задач - on-line transaction processing (OLTP). К этому классу, в том числе, относится всё взаимодействие с браузером, которые представляют клиентскую часть системы. За кадром, невидимая для операторов, остаётся почти чистая задача параллельной обработки множества запросов.

https://habr.com/ru/articles/789074/

#производительность #эффективность #oltp

Оценка потенциальной производительности информационных систем на задачах OLTP

Все мы сегодня наблюдаем неприятное явление деградации эффективности ПО. Эффективность проседает во всём, от неэффективного пользовательского интерфейса и до того, в чём компьютеры, вроде бы, просто обязаны быть самыми быстрыми, то есть в массовых задачах повседневной обработки информации. Решение задачи повышения производительности ПО не может быть получено без понимания, а на что мы в принципе можем рассчитывать? Именно такую отправную точку и предлагается рассмотреть в данном тексте. Далее показаны потенциальные возможности ПО на самых массовых на сегодня задачах, заключающихся во взаимодействии оператора с информационными системами. Англоязычное название этой группы задач - on-line transaction processing (OLTP). К этому классу, в том числе, относится всё взаимодействие с браузером, которые представляют клиентскую часть системы. За кадром, невидимая для операторов, остаётся почти чистая задача параллельной обработки множества запросов.

https://habr.com/ru/articles/789074/

#производительность #эффективность #oltp

Scalable OLTP in the Cloud: What's the BIG DEAL?

https://pathelland.substack.com/p/scalable-oltp-in-the-cloud-whats?utm_source=post-email-title&publication_id=175337&post_id=139962994&utm_campaign=email-post-title&isFreemail=true&r=4pxfn&utm_medium=email

"This thought experiment explores the asymptotic limits to scale for OLTP systems." -- #PAT_HELLAND

#OLTP #SQL #Scaling

Инструкция по установке Postgres для OLTP приложений и 1С. Часть 1 Базовая конфигурация

В Postgres достаточно подробная документация, и видимо поэтому , при инсталляции Postgres для 1С большинство параметров приходится выставлять самим. Параметров в Postgres много, а составить эффективную комбинацию не так просто. Все упрощается если рассмотреть профиль нагрузки, например, 1С это прежде всего профиль OLTP нагрузки – так устроены его метаданные (объекты). Если сосредоточится на оптимизации профиля OLTP, понимание Postgres сразу упростится. Установить Postgres для OLTP

https://habr.com/ru/articles/776536/

#Postges #1c #oltp

An interesting article about OLTP databases in the cloud and whether the scalability problem has been solved:

http://muratbuffalo.blogspot.com/2023/01/is-scalable-oltp-in-cloud-solved.html

#databases #oltp