07 июн. 2025 г.·8 мин
Майкл Стоунбрейкер и современные базы данных: что он изменил
Изучите ключевые идеи Майкла Стоунбрейкера — от Ingres и Postgres до Vertica — и как они сформировали SQL‑СУБД, аналитические движки и современные архитектуры данных.
Изучите ключевые идеи Майкла Стоунбрейкера — от Ingres и Postgres до Vertica — и как они сформировали SQL‑СУБД, аналитические движки и современные архитектуры данных.
Майкл Стоунбрейкер — учёный в области вычислений, чьи проекты не только повлияли на исследовательскую школу баз данных, но и прямо сформировали продукты и шаблоны проектирования, которыми ежедневно пользуются команды. Если вы использовали реляционную базу, аналитическое хранилище или стриминговую систему, вы уже воспользовались идеями, которые он помог доказать, реализовать или популяризировать.
Это не биография и не академический обзор теории баз данных. Вместо этого мы свяжем основные системы Стоунбрейкера (Ingres, Postgres, Vertica и др.) с теми решениями, которые вы видите в современных стеках данных:
Под современной базой данных мы понимаем систему, которая надёжно умеет:
Разные базы оптимизируют эти цели по‑разному — особенно если сравнивать транзакционные приложения, BI‑дашборды и поточные пайплайны.
Мы сосредоточимся на практическом влиянии: на идеях, которые проявляются в сегодняшнем мире «warehouse + lake + stream + microservices» и на том, как они влияют на то, что вы покупаете, строите и эксплуатируете. Ожидайте ясных объяснений, компромиссов и реальных последствий — но не глубоких доказательств или деталей реализации.
Карьера Стоунбрейкера проще всего читается как последовательность систем, созданных для конкретных задач — а затем лучших идей, мигрировавших в основные продукты.
Ingres начался как академический проект, который доказал: реляционные базы могут быть быстрыми и практичными, а не только теорией. Он помог популяризировать SQL‑подобные запросы и мышление о планировании запросов на основе стоимости, которое позже стало нормой в коммерческих движках.
Postgres (исследовательская система, ставшая основой PostgreSQL) испытал другую ставку: базы данных не должны быть фиксированными. Нужно уметь добавлять новые типы данных, новые индексы и более богатое поведение без переписывания движка.
Многие «современные» возможности восходят к той эпохе — расширяемые типы, пользовательские функции и база, способная адаптироваться по мере изменения нагрузок.
С ростом аналитики ряды ориентированные системы испытывали трудности с большими сканами и агрегатами. Стоунбрейкер продвигал колоночное хранение и связанные техники исполнения, направленные на чтение только нужных столбцов и хорошее сжатие — идеи, ставшие стандартом в аналитических БД и облачных хранилищах.
Vertica перенесла идеи колоночного хранения в коммерчески жизнеспособный MPP‑SQL‑движок, спроектированный для больших аналитических запросов. Шаблон повторялся по отрасли: прототип подтверждает концепт; продукт делает его надёжным, с инструментами и учётом реальных клиентских ограничений.
Поздние работы расширились до потоковой обработки и специализированных движков, утверждая, что универсальная база редко выигрывает повсеместно.
Прототип создаётся, чтобы быстро проверить гипотезу; продукт должен делать ставку на эксплуатацию: обновления, мониторинг, безопасность, предсказуемую производительность и поддержку. Влияние Стоунбрейкера видно потому, что многие идеи‑прототипы перешли в коммерческие базы как стандартные возможности, а не нишевые опции.
Ingres (сокр. от INteractive Graphics REtrieval System) был ранним доказательством, что реляционная модель может быть не только элегантной теорией. Тогда многие системы строились вокруг кастомных методов доступа и специфичных путей данных.
Ingres решал простую, бизнес‑дружественную проблему:
Как позволить людям задавать гибкие вопросы к данным, не переписывая ПО при каждом изменении вопроса?
Реляционные СУБД обещали, что вы описываете что хотите (например, «клиенты в Калифорнии с просроченными счетами»), а не как извлечь это пошагово. Чтобы сделать это реальностью, нужна система, которая умеет:
Ingres был большим шагом к «практической» реляционной обработке — такой, что могла работать на доступном тогда железе и оставаться отзывчивой.
Ingres помог закрепить идею, что база должна делать тяжёлую работу по планированию запросов. Вместо того, чтобы разработчики вручную настраивали каждый путь доступа, система могла выбирать, какую таблицу читать первой, какие индексы использовать и как выполнять соединения.
Это помогло распространиться SQL‑подходу: когда можно писать декларативные запросы, итерации идут быстрее, и больше людей — аналитики, продуктовые команды, финансы — могут прямо задавать вопросы без ожидания отдельного отчёта.
Большой практический инсайт — оптимизация на основе стоимости: выбирать план с наименьшей ожидаемой «стоимостью» (I/O, CPU, память), опираясь на статистику по данным.
Это важно, потому что часто даёт:
Ingres не изобрёл все части современной оптимизации, но помог утвердить шаблон: SQL + оптимизатор — это то, что превращает реляционные системы из «приятной идеи» в повседневный инструмент.
Ранние реляционные базы обычно предполагали фиксированный набор типов данных (числа, текст, даты) и фиксированный набор операций (фильтр, соединение, агрегат). Это работало — пока команды не начали хранить новые виды информации (геоданные, логи, временные ряды, доменно‑специфичные идентификаторы) или требовать специальных возможностей производительности.
С жёсткой архитектурой каждое новое требование превращалось в плохой выбор: запихать данные в текстовые поля, приручить отдельную систему или ждать, пока вендор добавит поддержку.
Postgres продвинул идею: база должна быть расширяемой — то есть в неё можно добавлять новые возможности контролируемо, не теряя гарантий безопасности и корректности, которые вы ожидаете от SQL.
Проще говоря, расширяемость — как добавлять сертифицированные насадки к электроинструменту, а не перепаивать мотор. Вы учите базу «новым трюкам», при этом транзакции, права и оптимизация запросов продолжают работать согласованно.
Этот подход ясно проявляется в экосистеме PostgreSQL и множества систем, вдохновлённых им. Вместо ожидания встроенной функции команды могут использовать проверенные расширения, которые чисто интегрируются с SQL и операционными инструментами.
Типичные примеры высокого уровня:
Ключевая мысль: Postgres сделал «изменять возможности базы» предметом проектирования, а не побочным эффектом — и эта идея до сих пор формирует развитие современных платформ данных.
Базы данных — это не только про хранение информации, но и про то, чтобы информация оставалась правильной, даже когда многое происходит одновременно. Для этого существуют транзакции и механизмы контроля конкурентности — причина, по которой SQL‑системы стали надёжными для реального бизнеса.
Транзакция — это набор изменений, который должен либо полностью выполниться, либо полностью откатиться.
Если вы переводите деньги между счетами, размещаете заказ или обновляете инвентарь, недопустимы «половинчатые» результаты. Транзакция гарантирует, что вы не получите ситуацию, где заказ списал деньги, но не зарезервировал товар — или товар уменьшился без соответствующего заказа.
Практически транзакции дают:
Конкурентность — это когда много людей и приложений одновременно читают и меняют данные: кассы клиентов, операторы поддержки, фоновые джобы, аналитики.
Без правил появляются проблемы вроде:
Один влиятельный подход — MVCC. Концептуально MVCC держит несколько версий строки короткое время, чтобы читатели могли смотреть на стабильный снимок, пока писатели вносят изменения.
Большой плюс в том, что чтения реже блокируют записи, а писатели не так часто задерживаются из‑за долгих запросов. Вы всё ещё получаете корректность, но с меньшими задержками.
Сегодня БД обслуживают часто смешанные нагрузки: интенсивные записи приложений плюс частые чтения для дашбордов, отображения клиентских страниц и оперативной аналитики. Современные SQL‑системы опираются на техники вроде MVCC, умных блокировок и уровней изоляции, чтобы сбалансировать скорость и корректность — вырастая без потери доверия к данным.
Рядовые (row‑ориентированные) базы проектировались для обработки транзакций: много мелких чтений и записей, обычно затрагивающих одну запись. Такой подход хорош, когда нужно быстро получить или обновить всю запись.
Представьте таблицу. Row‑store — как хранить каждую строку в отдельной папке: когда нужно «всё про Заказ #123», вы достаёте одну папку и всё. Column‑store — как хранить по столбцам: один ящик для «order_total», другой для «order_date», третий для «customer_region».
Для аналитики вам редко нужна вся папка — чаще вы спрашиваете «Какой был общий доход по регионам за прошлый квартал?». Такой запрос затрагивает несколько полей на миллионах строк.
Аналитические запросы часто:
С колоночным хранением движок может читать только столбцы, упомянутые в запросе, пропуская остальные. Меньше данных с диска и в памяти — большой выигрыш в производительности.
В колонках значения часто повторяются (регионы, статусы, категории), поэтому они хорошо сжимаются — а сжатие ускоряет аналитику: система читает меньше байт и иногда может работать прямо по сжатым данным эффективнее.
Колоночные хранилища обозначили переход от OLTP‑первичных систем к аналитическим двигателям, где сканирование, сжатие и быстрые агрегаты становятся первичными целями дизайна, а не побочным эффектом.
Vertica — яркий пример того, как идеи Стоунбрейкера о аналитических базах превратились в продукт для промышленной эксплуатации. Она соединила уроки колоночного хранения с распределённым дизайном, нацеленным на конкретную задачу: быстро отвечать на большие аналитические SQL‑запросы, даже когда объёмы данных выходят за рамки одного сервера.
MPP — это массово‑параллельная обработка. Проще говоря: много машин обрабатывают один SQL‑запрос одновременно.
Вместо одного сервера, читающего все данные и выполняющего группировки и сортировки, данные разделяются по узлам. Каждый узел обрабатывает свою часть параллельно, а система объединяет частичные результаты в окончательный ответ.
Это позволяет сократить минуты до секунд — при условии, что данные хорошо распределены и запрос можно распараллелить.
Системы типа Vertica хороши, когда у вас много строк и нужно эффективно сканировать, фильтровать и агрегировать. Типичные кейсы:
MPP‑аналитика не заменяет транзакционные системы. Они оптимизированы для чтения множества строк и вычисления сводок, а не для частых мелких обновлений.
Типичные компромиссы:
Ключ — фокус: Vertica и похожие системы добиваются скорости, настраивая хранение, сжатие и параллельное исполнение под аналитику, при этом принимая ограничения, которые транзакционные системы стараются избегать.
База может «хранить и запрашивать» данные и всё равно быть медленной для аналитики. Разница часто не в SQL, а в том, как движок его исполняет: как читает страницы, перемещает данные через CPU, использует память и минимизирует лишнюю работу.
Аналитические проекты Стоунбрейкера подчёркивали, что производительность запросов — это проблема исполнения не меньше, чем хранения. Это сместило фокус команд с оптимизации одиночных обращений на оптимизацию длинных сканов, соединений и агрегатов по миллионам/миллиардам строк.
Многие старые движки обрабатывают «кортеж за кортежем» (по одной строке), что создаёт много вызовов и накладных расходов. Векторное исполнение меняет модель: движок обрабатывает пакет значений в плотном цикле.
Просто: это как везти продукты тележкой вместо того, чтобы по одному нести сумки. Пакетирование снижает накладные расходы и позволяет CPU работать в своём оптимальном режиме: предсказуемые циклы, меньше ветвлений и лучшая работа с кэшем.
Быстрые аналитические движки сосредоточены на эффективности CPU и кэша. Инновации исполнения обычно фокусируются на:
Эти идеи важны, потому что аналитические запросы часто ограничены пропускной способностью памяти и промахами кэша, а не скоростью диска.
Современные хранилища данных и SQL‑движки — облачные хранилища, MPP‑системы и быстрые встроенные аналитические инструменты — часто по умолчанию используют векторное исполнение, операторы, осведомлённые о сжатии, и кэш‑дружественные конвейеры.
Даже когда вендоры рекламируют «автомасштабирование» или «разделение хранения и вычислений», повседневная скорость зависит именно от этих решений исполнения.
Если вы оцениваете платформы, спрашивайте не только что они хранят, но и как выполняют соединения и агрегаты под капотом — и заточен ли их модель исполнения под аналитику, а не под транзакционные нагрузки.
Потоковые данные — это просто события, которые приходят непрерывно: платеж, показ товара, сенсорное чтение, лог‑строка. Каждое событие появляется в реальном времени и продолжается.
Традиционные БД и пакетные пайплайны хороши, когда можно подождать: загрузить данные за вчера, запустить отчёт и обновить дашборды. Но реальное время ждать не будет.
Если вы обрабатываете данные только батчами, вы получаете:
Потоковые системы проектируются исходя из идеи, что вычисления могут выполняться непрерывно по мере прихода событий.
Непрерывный запрос — это как SQL‑запрос, который не «закрывается». Вместо единичного результата он обновляет результат по мере прихода новых событий.
Потоки бесконечны, поэтому используют окна (windows), чтобы ограничить вычисления: «последние 5 минут», «каждая минута» или «последние 1000 событий». Это позволяет считать скользящие счётчики, средние и топ‑N без переработки всего потока.
Реальное время особенно полезно, когда важна скорость реакции:
Стоунбрейкер десятилетиями утверждал: базы не должны быть универсальными «на всё». Причина проста: разные нагрузки вознаграждают разные проектные решения. Оптимизируя под одну задачу (маленькие транзакционные обновления), вы обычно ухудшаете другую (сканирование миллиардов строк для отчёта).
Большинство современных стеков используют больше одной системы данных, потому что бизнес хочет разного рода ответы:
Это практическое проявление «one size doesn’t fit all»: выбирают движки, соответствующие характеру работы.
Быстрый фильтр при обосновании ещё одной системы:
Несколько систем могут быть полезны, но только если у каждого есть чёткая нагрузка. Новый инструмент должен оправдать своё место сокращением затрат, латентности или риска — а не ради модного названия.
Предпочитайте меньше систем с чётким операционным владением и выведите из эксплуатации компоненты, у которых нет ясной измеряемой цели.
Исследовательские нити Стоунбрейкера — реляционные основы, расширяемость, колоночные хранилища, MPP‑исполнение и «правильный инструмент для задачи» — видны в стандартных формах современных платформ данных.
Хранилище (warehouse) отражает десятилетия работы по оптимизации SQL, колоночному хранению и параллельному исполнению. Когда вы видите быстрые дашборды на огромных таблицах, часто за этим стоят колоночные форматы, векторное исполнение и MPP.
Lakehouse заимствует идеи хранилища (схемы, статистика, кэширование, оптимизация на основе стоимости), но опирает их на открытые форматы файлов и объектное хранилище. Сдвиг «хранилище дешёвое, вычисления эластичные» — новый; однако мышление о запросах и транзакциях под ним — нет.
MPP‑аналитические системы (shared‑nothing кластеры) — прямые наследники исследований, доказавших, что SQL масштабируется через партиционирование данных, вынос вычислений к данным и аккуратное управление перемещением данных при соединениях и агрегациях.
SQL стал общим интерфейсом между хранилищами, MPP‑движками и слоями запроса по «озеру». Команды используют его как:
Даже если исполнение происходит в разных движках (батч, интерактив, стриминг), SQL часто остаётся языком для пользователей.
Гибкое хранение не отменяет потребности в структуре. Понятные схемы, документированные значения и контролируемая эволюция уменьшают поломки по цепочке.
Хорошее управление — это не бюрократия, а обеспечение надёжности данных: единые определения, владение, проверки качества и контроль доступа.
При оценке платформ спрашивайте:
Если вендор не может простыми словами соотнести продукт с этими пунктами, «инновация» может быть в основном упаковкой.
Главная мысль Стоунбрейкера проста: базы работают лучше, когда они проектируются под конкретную задачу — и когда они могут эволюционировать по мере изменения этой задачи.
Прежде чем сравнивать фичи, опишите, что вам действительно нужно делать:
Полезное правило: если вы не можете описать нагрузку в пару предложений (шаблоны запросов, объём данных, требования по задержке, конкурентность), вы будете выбирать по хайпу.
Команды недооценивают, как часто меняются требования: новые типы данных, метрики, правила соответствия, новые потребители.
Выбирайте платформы и модели данных, которые делают изменения обычным делом, а не риском:
Быстрые ответы ценны, только если они правильные. При оценке спрашивайте, как система обрабатывает:
Запустите небольшой «proof на ваших данных», а не только демо:
Много советов по базам данных останавливаются на «выберите движок», но командам ещё нужно выпускать приложения и внутренние инструменты вокруг этого: админ‑панели, дашборды метрик, сервисы приёма, бэк‑офисные рабочие процессы.
Если вы хотите быстро прототипировать без изобретения пайплайна заново, платформа для быстрого кодинга (vibe‑coding) вроде Koder.ai может помочь поднять веб‑приложения (React), бэкенды (Go + PostgreSQL) и даже мобильные клиенты (Flutter) из диалогового рабочего процесса. Это полезно при итерации схемы, создании небольшого внутреннего «data product» или валидации реального поведения нагрузки перед долгосрочными инфраструктурными решениями.
Если хотите углубиться, ищите материалы по колоночному хранению, MVCC, MPP‑исполнению и потоковой обработке. Больше объяснений публикуется в /blog.
Он редкий пример, когда исследовательские системы превратились в продуктовую ДНК. Идеи, доказанные в Ingres (SQL + оптимизация запросов), Postgres (расширяемость + принципы MVCC) и Vertica (колоночное хранение + MPP для аналитики), сегодня видно в том, как проектируют и продают хранилища, OLTP‑БД и потоковые платформы.
SQL выиграл потому, что позволяет описать что нужно получить, а СУБД уже решает как это сделать эффективно. Такое разделение обеспечило:
Костевой оптимизатор использует статистику по таблицам, чтобы сравнить возможные планы выполнения и выбрать тот, у которого наименьшая ожидаемая «стоимость» (I/O, CPU, память). На практике это помогает:
MVCC (мульти-версионный контроль конкурентного доступа) хранит несколько версий строк, чтобы считывающие транзакции видели стабильную снимок данных, пока другие транзакции пишут. Про практическое влияние:
Расширяемость означает, что база данных может безопасно приобретать новые возможности — типы, функции, индексы — без форка или переписывания ядра. Это полезно, когда нужно:
Оперативное правило: относитесь к расширениям как к зависимостям — версионируйте, тестируйте обновления и ограничивайте, кто их устанавливает.
Строевые (row) СУБД хороши, когда вы часто читаете или записываете целые записи (OLTP). Колоночные СУБД выгодны при сканировании большого числа строк с обращением к небольшому числу полей (аналитика).
Простая эвристика:
MPP (massively parallel processing) делит данные между узлами, и много машин совместно выполняют один SQL‑запрос. Это оправдано при:
Следите за компромиссами: выбор распределения данных, затраты на shuffle при соединениях и менее удобная работа с частыми одиночными обновлениями.
Векторная (vectorized) обработка обрабатывает данные пакетами (векторами), а не по одной строке, что снижает накладные расходы и эффективнее использует кэш CPU. Практическое проявление:
Пакетные системы запускают работы периодически, поэтому данные «свежие» с задержкой. Потоковые системы воспринимают события как непрерывный поток и вычисляют результаты инкрементально.
Типичные сценарии, где потоковая обработка окупается:
Чтобы держать вычисления ограниченными, потоки используют окна (например, последние 5 минут) вместо «всё время».
Используйте несколько систем, когда у каждой есть чёткая рабочая нагрузка и измеримая выгода (по затратам, задержке или надёжности). Чтобы не раздувать парк инструментов:
Если нужен фреймворк выбора, повторно используйте чеклист из поста и связанные материалы в /blog.