Майкл Стоунбрейкер и современные БД: SQL, аналитика, архитектура

О чём статья и чем важен Стоунбрейкер

Майкл Стоунбрейкер — один из тех исследователей и инженеров, чьи идеи не остались «в лаборатории». Он запускал проекты, которые становились реальными продуктами, а затем — ориентиром для всей индустрии. Когда сегодня обсуждают, почему одни базы данных хороши для транзакций, другие — для аналитики, а третьи умеют работать с потоками событий, в этих разговорах регулярно всплывают концепции, которые он продвигал и проверял на практике.

Это не биография и не перечень заслуг. Здесь важнее цепочка идей: какие проблемы в данных и запросах считались ключевыми в разные эпохи, какие архитектурные решения предлагались, что «взлетело» и стало стандартом де‑факто, а что оказалось полезным только в определённых сценариях.

Какие системы и направления затронем

Мы пройдём по нескольким классам технологий, которые заметно повлияли на современную архитектуру данных:

• SQL‑системы и эволюция реляционной модели (от Ingres к Postgres и дальше).
• Аналитические движки и колоночный подход (OLAP‑нагрузки, хранилища, ускорение сканов и агрегаций).
• Распределённые и параллельные СУБД (MPP), когда один сервер уже «не тянет» объём.
• Потоковые системы, где данные приходят непрерывно и важно реагировать быстро.

Мини-словарь: OLTP, OLAP, DWH

OLTP — «операционные» транзакции: оформить заказ, списать деньги, обновить статус доставки. Важны скорость коротких операций и корректность.

OLAP — аналитика: посчитать выручку по регионам, сравнить периоды, построить отчёт. Запросы обычно тяжелее и читают много данных.

DWH (хранилище данных) — место, куда собирают данные из разных систем, приводят к единому виду и используют для аналитики и отчётности.

Дальше мы будем возвращаться к этим понятиям, чтобы видеть: какая архитектура решает какую задачу — и почему «одна база на всё» работает не всегда.

Ingres и становление практического SQL

Реляционная модель обещала простую вещь: данные хранятся в таблицах, а нужный результат можно получить декларативным запросом, не расписывая пошаговый алгоритм. На практике ранним системам пришлось решить несколько «приземлённых» задач, без которых SQL оставался бы красивой идеей: обеспечить целостность данных, выполнять запросы достаточно быстро и предсказуемо, а также поддерживать параллельную работу пользователей.

Какие проблемы нужно было закрыть

Во-первых — целостность. Ограничения (например, уникальность ключей), правила ссылочной связанности и транзакционность превращают таблицы из набора строк в систему, которой можно доверять.

Во-вторых — выполнение запросов. Даже простой SELECT на реальных объёмах данных требует индексирования, грамотной работы с диском и планирования соединений (JOIN), иначе «удобный» язык становится слишком дорогим.

Ingres как ранняя практическая реализация

Ingres — один из проектов, показавших, что реляционный подход можно довести до промышленного уровня. Его ценность не только в том, что он поддерживал реляционные запросы, а в том, что он сделал их исполнимыми в реальных условиях: с дисковыми ограничениями, конкуренцией запросов и необходимостью обслуживать разные сценарии — от выборок по ключу до сложных соединений.

Оптимизатор и статистика: почему это критично

Ключевой «невидимый» компонент SQL‑СУБД — оптимизатор запросов. Он выбирает план выполнения: какие индексы использовать, в каком порядке соединять таблицы, где делать фильтрацию и агрегации. Чтобы решать это не вслепую, системе нужна статистика: распределения значений, кардинальности, селективность условий.

Что сегодня ожидается «по умолчанию»

От современных SQL‑систем мы уже автоматически ждём того, что когда-то было инновацией: стоимостной оптимизатор, сбор статистики, индексы, транзакции и базовые гарантии целостности — без ручного «подгона» под каждый запрос.

Postgres: ставка на расширяемость и эволюцию данных

Postgres появился как ответ на простую боль, знакомую любой организации: данные меняются быстрее, чем успевают меняться правила хранения. Стоунбрейкер видел, что «классическая» реляционная модель отлично работает для таблиц и SQL‑запросов, но хуже адаптируется к новым типам данных, нестандартным правилам целостности и будущим требованиям, которые ещё нельзя сформулировать.

Зачем был нужен Postgres

Ключевая ставка — расширяемость без поломки привычного подхода. Вместо того чтобы выбрасывать SQL и начинать заново, Postgres развивал идею «объектно‑реляционной» системы: остаётся табличная основа и запросы, но платформа позволяет добавлять новые сущности и поведение.

В ранних идеях проекта важное место занимали правила, триггеры и механизм управления изменениями: данные должны не только лежать, но и «жить» по заданным бизнес‑правилам рядом с местом хранения.

Объектно-реляционность без отказа от SQL

Это не про «сложнее и умнее», а про более дешёвую эволюцию:

• можно вводить новые типы данных, когда появляются новые источники и форматы;
• можно подключать новые методы индексации под разные сценарии поиска;
• можно расширять логику проверки и обработки данных, не переписывая всю систему.

Как расширяемость повлияла на экосистему

Вокруг Postgres сформировалась культура расширений: дополнительная функциональность поставляется как подключаемые модули, а не как «монолитная версия базы». Это снижает порог экспериментов: вы пробуете новую возможность, не ломая ядро и не мигрируя на другую СУБД.

Практический урок для архитектуры

Проектируйте схему и платформу так, чтобы изменения были дешёвыми. Закладывайте точки расширения (типы, индексы, правила валидации), изолируйте нестабильные части модели данных и принимайте заранее, что «финальной схемы» не будет — будет управляемая эволюция.

MVCC и конкурентный доступ без постоянных блокировок

Зачем вообще нужна многоверсионность

В классических СУБД чтение и запись часто конкурируют за одни и те же строки. Если читатель «держит» блокировку, писателю приходится ждать; если приоритет у писателя — тормозят отчёты и аналитические запросы. На реальной нагрузке это превращается в очереди, скачки задержек и непредсказуемую производительность.

MVCC (многоверсионный контроль конкурентного доступа) решает задачу иначе: вместо постоянного «перетягивания» блокировок система хранит несколько версий данных и даёт каждому запросу согласованную картину.

Интуиция MVCC: снимки вместо блокировок

Представьте, что каждый запрос читает данные как бы «на момент старта» — по снимку (snapshot). Параллельно транзакция записи не переписывает строку «поверх», а создаёт новую версию. Поэтому чтение обычно не блокирует запись, и наоборот: читатель видит старую подтверждённую версию, писатель готовит новую.

Это особенно важно для смешанных сценариев OLTP+OLAP: короткие транзакции продолжают работать, пока в фоне идут отчёты, и система меньше «замирает» из‑за конфликтов.

Компромиссы: место, очистка, долгие транзакции

Цена MVCC — дополнительные версии, а значит расход места и необходимость уборки. Почти всегда есть механизм очистки (vacuum/garbage collection), который удаляет устаревшие версии, когда они больше никому не нужны.

Отдельный риск — долгие транзакции: пока «старый» снимок жив, система вынуждена хранить старые версии, и очистка замедляется.

Что проверять в любой СУБД

Сравнивая продукты, смотрите не только на слово «MVCC» в документации, а на практику:

• уровни изоляции и их поведение по умолчанию;
• какие блокировки всё же остаются (DDL, индексы, горячие обновления);
• как проявляются конфликты (например, при конкурентных обновлениях);
• как устроены очистка версий и мониторинг долгих транзакций.

Эти детали напрямую определяют, будет ли система «мягко» переживать пики нагрузки или начнёт тормозить именно тогда, когда это критично.

«Один размер для всех» — когда это не работает

Идея «универсальной СУБД», которая одинаково хорошо справляется со всеми задачами, звучит удобно: один продукт, одна команда, единые процессы. Но на практике разные типы нагрузки требуют противоположных архитектурных решений. Именно это наблюдение Стоунбрейкер много раз подчёркивал на примерах систем для транзакций и аналитики.

Почему требования конфликтуют

OLTP (операционные транзакции) обычно означает тысячи коротких запросов в секунду: вставки, обновления, точечные чтения по ключу. Здесь важны минимальные задержки, эффективные индексы, быстрая фиксация транзакций, предсказуемое время ответа.

OLAP/аналитика — это редкие, но тяжёлые запросы: сканирование больших объёмов, агрегации, JOIN’ы, расчёты по историческим данным. Тут выигрывают колоночное хранение, компрессия, векторизованное выполнение, продуманная работа с параллелизмом и кэшами.

Попытка «усреднить» систему приводит к тому, что она:

• либо тормозит транзакции из‑за фоновых сканов и конкуренции за ресурсы,
• либо делает аналитику дорогой (много лишнего ввода‑вывода и слабая утилизация CPU).

Как выбирать подход: один движок или разделение контуров

Частая практическая стратегия — разделять контуры: отдельная БД под OLTP и отдельное хранилище/аналитический движок под отчёты (DWH). Это снижает взаимное влияние нагрузок и позволяет оптимизировать каждую систему под свою работу.

Если хочется меньше компонентов, альтернативой бывает единая платформа с разными режимами хранения и выполнения. Но важно заранее проверить, что она выдержит ваши пики и типовые запросы, а не только «среднюю температуру».

Цена специализации: интеграция и наблюдаемость

Больше систем — это больше точек отказа и работы для команды: синхронизация данных, контроль качества, управление схемами, мониторинг задержек, трассировка пайплайнов.

Практичный критерий: если аналитика начинает мешать операционным процессам (или наоборот), разделение почти всегда окупается — при условии, что вы инвестируете в интеграцию и наблюдаемость с самого начала.

Колоночная аналитика: идеи C-Store и их наследие

C‑Store — один из ключевых проектов, показавших, почему аналитические запросы требуют другой «начинки», чем классические OLTP‑СУБД. Его идеи разошлись по современным хранилищам данных и аналитическим движкам настолько широко, что сегодня многие практики кажутся очевидными — хотя когда-то это был радикальный поворот.

Почему колонки ускоряют аналитику

В аналитике часто считают агрегаты по небольшому набору полей: «выручка по регионам», «средний чек по каналам», «топ товаров». При строковом хранении приходится читать целые строки, даже если нужны 2–3 столбца из 50.

Колоночный формат делает обратное: система читает только нужные столбцы, то есть меньше данных проходит через диск, сеть и CPU‑кэш. Особенно заметно это на широких таблицах и запросах типа «сканирование + фильтр + агрегация».

Сжатие и векторная обработка

Колоночные данные обычно лучше сжимаются: в одном столбце значения однотипны и часто повторяются (категории, статусы, коды). Отсюда два эффекта:

• меньше объём хранения и меньше ввода‑вывода;
• часть операций можно выполнять «на сжатых данных» или очень эффективно распаковывать блоками.

Вторая важная идея — векторная обработка: выполнять операции не по одной строке, а пачками значений (батчами). Это лучше укладывается в архитектуру современных CPU и снижает накладные расходы интерпретации.

От C-Store к промышленным DWH

Практики C‑Store — колоночные форматы, агрессивное сжатие, батч/векторизация, оптимизация под сканирование больших объёмов — стали основой для многих DWH и MPP‑решений. Даже когда продукт «не чисто колонночный», внутри часто живут похожие принципы.

Если хочется глубже разобраться в выборе между транзакциями и аналитикой, см. также /blog/oltp-vs-olap.

Ограничения: обновления и транзакции

Цена аналитической скорости — сложности с частыми точечными обновлениями и множеством мелких вставок. Колоночные структуры хуже подходят для сценариев, где важны мгновенные одиночные записи и строгая транзакционность на высокой конкуренции. Поэтому на практике часто разделяют контуры: OLTP — отдельно, аналитика/DWH — отдельно, а данные переносятся пакетами или потоками.

MPP и параллельное выполнение запросов

MPP (Massively Parallel Processing) — подход, в котором запросы выполняются одновременно на многих узлах кластера. Ключевая идея — не «ускорять один сервер», а добавлять узлы и получать прирост производительности за счёт параллелизма.

Shared-nothing: почему это масштабируется

В архитектуре shared‑nothing у каждого узла свои CPU, память и диск, а данные заранее распределены по узлам (шардинг/партиционирование). Узлы не делят общий диск или общую память, поэтому меньше конкуренции за ресурсы и проще добавлять мощности: увеличили число узлов — увеличили суммарный объём хранения и вычислений.

Параллельные планы выполнения

План запроса в MPP обычно раскладывается на «фрагменты» (stages), которые исполняются на узлах над локальными кусками данных. Если фильтрация и агрегация могут делаться локально, система старается «поджать» данные как можно раньше.

Самая дорогая часть — операции, требующие перестановки данных между узлами: JOIN и GROUP BY часто запускают пересылку по сети (shuffle/exchange). Поэтому выбор ключа распределения и стратегия соединений напрямую влияют на скорость.

Типичные узкие места

Один из частых врагов параллелизма — перекос данных (skew): когда часть ключей «горячая», один узел получает непропорционально много строк и тормозит весь запрос.

Второй класс проблем — сетевые пересылки и координация: широкие JOIN’ы, неправильный порядок операций, лишние перемещения данных, а также накладные расходы планировщика и синхронизаций.

Связь с современными аналитическими платформами

Современные MPP‑хранилища и аналитические платформы развивают те же принципы: распределение данных, параллельное сканирование и агрегации, минимизация shuffle. На практике это превращается в прикладные правила: продумывать ключи распределения, следить за skew, проектировать модели данных так, чтобы «тяжёлые» соединения происходили как можно локальнее.

OLTP в памяти и масштабирование транзакций

Традиционные OLTP‑системы долгое время проектировались «от диска»: данные лежат на медленном носителе, а главная задача — экономить операции ввода‑вывода. Отсюда тяжёлые буферы, сложные индексы и осторожные схемы блокировок.

OLTP в памяти переворачивает приоритеты. Если данные и рабочий набор помещаются в RAM, то главным становится не I/O, а задержки на CPU, синхронизация потоков и «цена» конкурентного доступа. Часто упрощается модель хранения (например, меньше уровней абстракции и накладных расходов), а журналирование и репликация выносятся в отдельные, более предсказуемые контуры.

H-Store/VoltDB как иллюстрация подхода

Проекты Стоунбрейкера H‑Store и его коммерческое продолжение VoltDB популяризировали ключевую идею: масштабировать транзакции через партиционирование данных и ограничение формы транзакций.

• Данные делятся по ключу (партиции), каждая обслуживается «своим» потоком/узлом.
• Большинство транзакций должно укладываться в одну партицию — тогда они быстрые и почти не требуют межузловой координации.
• Выполнение часто проектируется так, чтобы минимизировать конфликты и ожидания (вплоть до последовательной обработки внутри партиции).

Где это выигрывает

Подход особенно силён там, где операции частые и однотипные, а запросы предсказуемы: расчёт лимитов и балансов, телеметрия с быстрыми апдейтами, игровые или рекламные счётчики, бронирования с понятным ключом разделения. В таких сценариях «сначала партиционирование» даёт линейное масштабирование и очень низкие задержки.

Где нужно осторожничать

Слабое место — кросс‑партиционные транзакции: как только одной операции нужно затронуть несколько разделов, появляется дорогая координация и риск падения производительности. Аналогично, сложные отчёты и произвольная аналитика поверх транзакционных данных обычно лучше живут в отдельном контуре (DWH/OLAP), чем внутри memory‑OLTP.

Потоковые системы: обработка данных в реальном времени

Потоковую обработку полезно выделять в отдельный класс систем, потому что у неё другая «физика» данных: не запросы к уже лежащим таблицам, а непрерывный поток событий, который нужно обработать сразу, пока он не потерял актуальность. Это меняет приоритеты — важнее задержка (latency) и стабильность обработки, чем максимальная скорость разового SQL‑запроса.

Какие задачи решают потоки

Типичные сценарии почти всегда завязаны на события и реакцию:

• мониторинг метрик и логов с оперативными алертами;
• обработка кликов/заказов/платежей «по факту поступления»;
• агрегаты «на лету»: сколько ошибок за последние 5 минут, какой оборот по регионам за час, какие товары всплеснули по спросу;
• обогащение событий справочниками (например, добавление атрибутов клиента) и маршрутизация в разные системы.

Идея, которую продвигали исследовательские проекты Стоунбрейкера (вроде Aurora/Borealis), в том, что запрос становится долговременным: вы один раз задаёте логику, а система применяет её ко всем новым данным.

Базовые понятия: окна и время события

В потоках почти всегда нужен window — окно времени или количества событий, внутри которого считаются агрегаты. Важно различать время события (когда оно произошло) и время обработки (когда дошло до системы). Из‑за задержек появляются поздние данные: событие могло случиться «в прошлой минуте», но приехать позже. Тогда система должна уметь корректировать результаты (например, пересчитать окно) или явно ограничивать, насколько «поздние» события принимаются.

Как связать потоки и хранилища

Потоки редко живут сами по себе: чаще они питают хранилища и витрины.

Практичный паттерн: поток → оперативные агрегаты для real‑time дашбордов → выгрузка в DWH для исторической аналитики. При этом полезно заранее определить, какие вычисления делать в потоке (быстро, но ограниченно), а какие — в DWH (глубже, но с задержкой).

Хороший результат даёт единая модель данных и договорённость о «истине»: где формируются итоговые показатели и как они пересчитываются при поздних событиях.

Нестандартные данные и расширенные модели

Долгое время «база данных» ассоциировалась с таблицами и строками. Но в реальных продуктах данные часто выходят за рамки классической схемы: координаты и геометрии, тексты, временные ряды, массивы, полу‑структурированные документы. Подход Стоунбрейкера (особенно в Postgres) был в том, чтобы не заставлять всё притворяться таблицами, а расширять модель данных — и при этом сохранять преимущества СУБД: транзакционность, запросы, оптимизацию.

Данные не только таблицы

Примеры «нестандартных» типов, которые быстро становятся нормой:

• Геоданные: точки, полигоны, расстояния, пересечения (и запросы типа «найти в радиусе»).
• Текст: поиск по словам и фразам, ранжирование, морфология.
• Временные ряды: агрегации по окнам, «последнее значение», downsampling.
• Массивы и структуры: списки тегов, параметры, вложенные атрибуты.

Ключевая идея здесь — приближать вычисления к данным. Если СУБД умеет хранить тип и выполнять над ним операции, то фильтрация и агрегация происходят там же, где лежат данные: меньше пересылок, меньше промежуточных выгрузок, проще контролировать консистентность.

На что смотреть при выборе расширяемой СУБД

Важно оценивать не «поддерживает ли она тип данных», а насколько полно он встроен в ядро запросов:

• Индексы под ваши операции (например, пространственные запросы, поиск по документам).
• Функции и операторы: можно ли выразить нужные условия в SQL без внешней обработки.
• Типы и ограничения целостности: проверки формата, диапазонов, уникальности, ссылочной целостности.

Практический вывод

Заранее зафиксируйте, какие запросы будут «нормой»: поиск рядом на карте, фильтры по событиям во времени, полнотекст, смешанные условия по JSON‑полям. От этого зависит, стоит ли делать ставку на расширяемость (типы/операторы/индексы) или лучше выделять специализированное хранилище под отдельный класс задач.

Что из этих инноваций стало стандартом де-facto

Многие идеи, которые Стоунбрейкер продвигал в разных проектах, сегодня воспринимаются как «само собой разумеющееся» — даже если в конкретном продукте они реализованы иначе или называются по‑другому.

Что закрепилось как норма

MVCC (многоверсионность) стало базовым способом давать параллельный доступ без постоянных жёстких блокировок. Практический эффект понятен бизнесу: меньше «очередей» на записи и чтение, стабильнее время ответа при росте нагрузки.

Расширяемость и плагины тоже превратились в стандарт ожиданий. Пользователи хотят подключать новые типы данных, индексы, функции, интеграции — и делать это без переписывания ядра. Это прямо продолжает линию Postgres: база данных как платформа, а не «закрытая коробка».

Колоночное хранение и векторное выполнение стали нормой для аналитики. Даже там, где система формально «строчная», часто появляются колоночные форматы, отдельные движки или ускорители, потому что стоимость сканирования больших объёмов и время на отчёты критичны.

MPP и параллелизм в аналитических запросах — ещё один де‑факто стандарт: данные и вычисления распределяют по узлам, чтобы укладываться в окна отчётности.

Что изменилось со временем

Облака, дешёвое хранение и автоматизация сдвинули акценты: теперь важны не только алгоритмы, но и эксплуатация — автоподстройка, эластичность, предсказуемая стоимость, управляемые сервисы.

Отсюда практический вывод: архитектурные решения важно проверять не только в «теории оптимальности», но и в том, насколько быстро команда может их развернуть, повторить, обновить и откатить.

Мини‑чек‑лист: решения, которые стоит проговаривать

• Где нужна MVCC/изоляция, а где достаточно более простой (и дешёвой) модели?
• Аналитика: делаете ставку на колонки/векторизацию или «универсальный» движок?
• Нужен ли MPP, или хватит масштабирования «вверх» и кэширования?
• Какие расширения критичны (типы, индексы, функции), и как вы будете ими управлять?
• Какие компромиссы принимаете осознанно: стоимость vs. сложность vs. задержка vs. надёжность?

Практические выводы для архитектуры данных сегодня

Идеи Стоунбрейкера полезны не как «история технологий», а как набор критериев: под разные задачи нужны разные компромиссы. Перед тем как выбирать СУБД или строить платформу, полезно пройтись по нескольким вопросам.

1) Сначала — профиль нагрузки, потом — продукты

Определите, какие запросы будут доминировать:

• OLTP: много коротких транзакций, строгая согласованность, предсказуемая задержка.
• OLAP: тяжёлые агрегаты, сканы больших объёмов, важны стоимость запроса и пропускная способность.
• Смешанная: отчёты поверх операционных данных (часто источник конфликтов по ресурсам).
• Real‑time: постоянный поток событий и требования к «времени до инсайта».

Эта классификация сразу подсказывает, где уместны MVCC, колоночное хранение, MPP или потоковая обработка — и где это будет лишним.

2) Единая СУБД или специализация — решайте по границам контуров

Два рабочих подхода:

• Единая СУБД, но разделение контуров: отдельные схемы/кластеры/ресурсные пулы для транзакций и аналитики, чтобы они не «давили» друг друга.
• Специализированные системы: операционная БД для OLTP, колоночная/MPP для аналитики, потоковый слой для событий.

Выбор зависит от того, что дороже: операционная сложность или потери от компромиссного «одного размера для всех».

3) Продумайте контуры данных как продукт

Архитектура — это не только хранилище. Минимальный набор контуров:

• Ingestion: откуда берём данные, как повторяем загрузку, как обрабатываем опоздавшие события.
• Качество: правила валидации, контроль дубликатов, договорённости по временным зонам и ключам.
• Каталог и семантика: единые определения метрик и витрин, чтобы «выручка» не отличалась по командам.
• Права доступа: роли, маскирование чувствительных полей, аудит.

Если вы часто делаете такие контуры «с нуля», полезно иметь быстрый способ собирать вспомогательные сервисы и интерфейсы: загрузчики, админки, простые витрины, дашборды для проверки качества данных. Например, в TakProsto.AI можно через чат собрать прототип веб‑интерфейса (React), серверной части (Go) и схемы в PostgreSQL, а затем развернуть, подключить домен и при необходимости экспортировать исходники. Это удобно именно на этапе, когда вы валидируете гипотезы по данным и проверяете нагрузочный профиль до того, как «зацементируете» архитектуру.

Отдельно для дата‑контуров важны практики управления изменениями. Здесь помогают функции вроде снапшотов и отката (rollback): легче безопасно экспериментировать со схемой, пайплайнами и версиями витрин.

4) Метрики успеха и типичные ошибки

Заранее зафиксируйте метрики: p95 задержки, стоимость запроса, время до инсайта, операционная сложность (сколько людей и регламентов нужно, чтобы это поддерживать).

Частые ошибки: преждевременная распределённость, игнорирование перекоса данных (одни ключи «горячее» других), и отсутствие наблюдаемости (нет понятных метрик, трассировки и причин деградации).

И ещё одна практичная вещь: чем быстрее вы можете собрать тестовый стенд и воспроизвести характерную нагрузку, тем меньше «архитектуры на вере». В этом смысле платформы, которые ускоряют разработку через чат‑подход (vibe‑кодинг) и дают быстрый деплой в российском контуре, помогают проверять решения раньше и дешевле — особенно когда нужно сравнить несколько вариантов (например, один контур vs. разделение OLTP/DWH, или разные ключи партиционирования).