Определение фактического профиля нагрузки в 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 в ВТБ. Когда вы знакомитесь с документацией по какой-то системе в части базы данных, то обычно характер...

Хабр

Считаем ресурсы под 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 для данного сервиса. Раньше...

Хабр

INSERT в StarRocks: как три кластера раскрыли цену commit protocol

tl;dr: Каждая операция INSERT несет фиксированный overhead (в наших тестах 64–99 ms), независимо от количества строк. Формула: Total_time = N_statements * fixed_overhead + actual_write_time — подтверждена тестами. 1000 single-row INSERT = 64 секунды (Shared-data) или 100 секунд (Shared-Nothing). Разница не в диске и не в Docker, а в протоколе commit: TxnLog + publish через BRPC против 2PC + publish_version. В ANALYZE PROFILE commit overhead прячется в разнице TotalTime - ExecutionTime — это FE overhead. Батчинг нивелирует разницу: при INSERT SELECT оба режима дают ~0.25 с на 1000 строк.

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

#StarRocks #OLAP #distributed_databases #performance #INSERT_optimization #архитектура

INSERT в StarRocks: как три кластера раскрыли цену commit protocol

tl;dr: Каждая операция INSERT несет фиксированный overhead (в наших тестах 64–99 ms), независимо от количества строк. Формула: Total_time = N_statements * fixed_overhead + actual_write_time...

Хабр

In meinen heutigen #TechTipps möchte ich Euch gerne #duckdb
vorstellen.
DuckDB (https://duckdb.org) könnte Euch dann interessieren wenn ihr:

- in der IT (#Softwareentwicklung, Datenanalyse #Olap, Qualitätssicherung, Forschung, etc ) arbeitet
- privat an Datenanlyse jenseits von unübesichtlichen Tabellen (#Spreadsheets) interessiert seid
- Daten wie Kontoauszüge, Telefonbücher oder (elektronische) Kataloge durchforsten wollt

DuckDB kann als eigenständiges Kommandozeilen (#CLI) Programm ohne Abhängigkeiten bezogen und verwendet werden oder auch intergriert in andere #programmiersprachen (#python) oder #tools wie #jupyter integriert werden.

Die CLI-Version kann mit Parameter "-ui" verwendet werden und startet damit ein recht komfortables #webui im lokalen #browser.
Im ersten Schritt legt man nun ein "Notebook" an das zellenweise strukturiert ist.
Es können jederzeit neue Zellen an jeder Stelle im #workflow hinzugefügt, eingefügt oder gelöscht werden.
Unterteilt man nun seinen Anwendungsfall in kleine Schritte (Zellen) wird ein komplexes Thema schon viel einfacher.

Beispiel:
1. Zelle:
-- Datenbank im Speicher anlegen
ATTACH IF NOT EXISTS ':memory:' AS memory;

2.Zelle:
-- Tablle BLS 4.0 importieren
CREATE OR REPLACE TABLE BLS AS
SELECT * FROM
read_xlsx('/home/XXX/Downloads/BLS_4_0_2025_DE/BLS_4_0_Daten_2025_DE.xlsx',
sheet = 'BLS_4_0_Daten_2025_DE',
header = true, all_varchar = true);

3. Zelle
-- Zeige mir Lebensmittel mit Vitamin D
select Lebensmittelbezeichnung, "VITD Vitamin D [µg/100g]" as VD
from'BLS'
where
VD is not null and VD not ilike '0'
order by VD DESC;

Ergebnisse können als Tabelle oder CSV mit "Download" gespeichert werden.
😀

🌘 深入解析 StarRocks:為何 JOIN 操作比你想像中更快
➤ 透過成本基礎優化器與分散式執行策略,顛覆傳統 OLAP JOIN 效能瓶頸
https://www.starrocks.io/blog/inside-starrocks-why-joins-are-faster-than-youd-expect
本文深入探討 StarRocks 如何透過成本基礎優化器(CBO)與分佈式執行策略,大幅提升 JOIN 操作效能。相較於許多 OLAP 系統因 JOIN 效能瓶頸而被迫進行反正規化(Denormalization),StarRocks 選擇保持資料正規化並優化 JOIN 速度。文章詳細剖析了 JOIN 優化面臨的挑戰,包括多種 JOIN 策略的選擇、多表 JOIN 的順序排列、執行效果的預測難度,以及分散式環境下的最佳化難題。接著,文章闡述了 StarRocks 在邏輯層面(如 JOIN 類型轉換)與物理層面(如 JOIN 重排序與分散式規劃)的具體技術手段,並佐以 NAVER、Demandbase 及 Shopee 的實戰
#數據庫優化 #OLAP #分佈式系統
Inside StarRocks: Why Joins Are Faster Than You’d Expect

The engineering choices that turn joins into a strength. A deep dive with real-world case studies.

StarRocks to the rescue! 🚀 Apparently, the #OLAP world was too busy having a mental breakdown over #joins to realize that #StarRocks has some secret sauce that makes them faster than a cat meme's rise to fame. 😂 But hey, who cares about real solutions when we can just keep denormalizing everything into oblivion, right? 🙄
https://www.starrocks.io/blog/inside-starrocks-why-joins-are-faster-than-youd-expect #performance #dataanalytics #datavisualization #technologyhumor #HackerNews #ngated
Inside StarRocks: Why Joins Are Faster Than You’d Expect

The engineering choices that turn joins into a strength. A deep dive with real-world case studies.

Как JOIN изменил наш подход к инфраструктуре данных в NAVER

После миграции с ClickHouse на StarRocks NAVER существенно оптимизировала обработку многотабличных JOIN. StarRocks повысил производительность запросов, обеспечил бесшовное масштабирование и позволил построить единый слой запросов, совместимый с множеством источников данных. Эти улучшения позволили предоставлять инсайты в реальном времени и поддерживать принятие решений на основе данных во всей экосистеме NAVER.

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

#StarRocks #ClickHouse #Apache_Iceberg #Lakehouse #JOIN #OLAP #Kubernetes #материализованные_представления #federated_analytics #аналитика_в_реальном_времени

Как JOIN изменил наш подход к инфраструктуре данных в NAVER

Авторы:Youngjin Kim, руководитель команды, NAVER; Moweon Lee, инженер по данным, NAVER NAVER основана в 1999 году, является материнской компанией мессенджера LINE, пятой по величине поисковой системой...

Хабр

Инструмент перехвата медленных запросов StarRocks

Практическое руководство по построению сервиса перехвата медленных запросов в StarRocks: правила kill и пороги (full table scan, scan rows/bytes), анализ execution plan, интеграции с Grafana и Feishu, SQL-схемы и YAML-конфигурация для продакшена.

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

#StarRocks #медленные_запросы #slow_query #OLAP #MPP #full_table_scan #execution_plan #stream_load #Grafana

Инструмент перехвата медленных запросов StarRocks

Поскольку кластеров много, а на управление медленными запросами и обеспечение приоритета коротких запросов не хочется тратить много времени, был разработан вспомогательный сервис для контроля...

Хабр

Khi nào nên dùng cơ sở dữ liệu cột (columnar database)? Khi làm việc với truy vấn phân tích (OLAP), lượng dữ liệu lớn và cần hiệu suất cao. Columnar DB tận dụng vectorization, lưu trữ tuần tự và tối ưu bộ nhớ giúp truy vấn nhanh hơn. Phù hợp cho báo cáo, BI và phân tích dữ liệu chứ không phải giao dịch (OLTP). #ColumnarDatabase #OLAP #DataEngineering #CSDLcột #PhânTíchDữLiệu #BigData

https://www.reddit.com/r/programming/comments/1q5h5qc/when_to_use_a_columnar_database/

Инструменты и методы синхронизации данных из распространенных СУБД в StarRocks

В статье разберем, как синхронизировать данные из Oracle, MySQL, SQL Server, PostgreSQL, Kafka и MongoDB в StarRocks. Сравним Flink+CDC+SMT, DataX, Routine Load и Python по применимости, ограничениям и удобству эксплуатации, а также дадим рекомендации по выбору под разные сценарии.

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

#ETL #Apache_Flink #Apache_Kafka #MongoDB #PostgreSQL #MySQL #Oracle #Microsoft_SQL_Server #OLAP

Инструменты и методы синхронизации данных из распространенных СУБД в StarRocks

В повседневной работе нередко требуется синхронизировать данные из распространенных СУБД — Oracle, MySQL, SQL Server, PostgreSQL, а также из MongoDB и Kafka — в StarRocks для последующей очистки и...

Хабр