Майкл Стоунбрейкер и современные базы данных: что он изменил

Почему идеи Стоунбрейкера до сих пор встречаются в вашем стеке данных

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

Что вы получите из этой статьи

Это не биография и не академический обзор теории баз данных. Вместо этого мы свяжем основные системы Стоунбрейкера (Ingres, Postgres, Vertica и др.) с теми решениями, которые вы видите в современных стеках данных:

• Почему SQL стал общим языком для работы с данными
• Почему аналитические движки выглядят и ведут себя иначе, чем OLTP‑БД
• Почему «одна база на всё» часто терпит неудачу на практике
• Как архитектурные выборы влияют на стоимость, производительность и надёжность

Что значит «современная база данных» (простым языком)

Под современной базой данных мы понимаем систему, которая надёжно умеет:

• Хранить данные безопасно (чтобы вы их не потеряли)
• Запрашивать их быстро (чтобы команды могли получать ответы)
• Масштабироваться по объёму и числу пользователей (не падая)
• Сохранять корректность при конкурентном доступе (чтобы результаты соответствовали реальности)

Разные базы оптимизируют эти цели по‑разному — особенно если сравнивать транзакционные приложения, BI‑дашборды и поточные пайплайны.

Обещание этой статьи

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

Короткая полезная хронология его ключевых достижений

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

1970‑е: Ingres — сделать реляционные базы пригодными для практики

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

1980–1990‑е: Postgres — расширяемость и «позволь базе развиваться»

Postgres (исследовательская система, ставшая основой PostgreSQL) испытал другую ставку: базы данных не должны быть фиксированными. Нужно уметь добавлять новые типы данных, новые индексы и более богатое поведение без переписывания движка.

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

2000‑е: колоночные хранилища и аналитика как приоритет

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

Середина 2000‑х: Vertica — MPP‑аналитика как продукт

Vertica перенесла идеи колоночного хранения в коммерчески жизнеспособный MPP‑SQL‑движок, спроектированный для больших аналитических запросов. Шаблон повторялся по отрасли: прототип подтверждает концепт; продукт делает его надёжным, с инструментами и учётом реальных клиентских ограничений.

2010‑е и далее: стриминг и «правильный инструмент для задачи»

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

Прототипы исследований vs продукты (почему это важно)

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

Ingres: сделать реляционные базы практичными

Ingres (сокр. от INteractive Graphics REtrieval System) был ранним доказательством, что реляционная модель может быть не только элегантной теорией. Тогда многие системы строились вокруг кастомных методов доступа и специфичных путей данных.

Ingres решал простую, бизнес‑дружественную проблему:

Как позволить людям задавать гибкие вопросы к данным, не переписывая ПО при каждом изменении вопроса?

Что пытался исправить Ingres

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

• Надёжно хранить данные в таблицах
• Принимать высокоуровневый язык запросов, похожий на SQL
• Превращать запрос в эффективный план автоматически

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

Принятие SQL и рождение основ оптимизации запросов

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

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

Почему cost‑based оптимизация важна

Большой практический инсайт — оптимизация на основе стоимости: выбирать план с наименьшей ожидаемой «стоимостью» (I/O, CPU, память), опираясь на статистику по данным.

Это важно, потому что часто даёт:

• Более быстрые запросы без изменения приложения
• Меньше железа для достижения той же производительности
• Более предсказуемую производительность по мере роста данных

Ingres не изобрёл все части современной оптимизации, но помог утвердить шаблон: SQL + оптимизатор — это то, что превращает реляционные системы из «приятной идеи» в повседневный инструмент.

Postgres: большая идея расширяемых баз данных

Ранние реляционные базы обычно предполагали фиксированный набор типов данных (числа, текст, даты) и фиксированный набор операций (фильтр, соединение, агрегат). Это работало — пока команды не начали хранить новые виды информации (геоданные, логи, временные ряды, доменно‑специфичные идентификаторы) или требовать специальных возможностей производительности.

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

Расширяемость, объяснённая без жаргона

Postgres продвинул идею: база должна быть расширяемой — то есть в неё можно добавлять новые возможности контролируемо, не теряя гарантий безопасности и корректности, которые вы ожидаете от SQL.

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

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

Этот подход ясно проявляется в экосистеме PostgreSQL и множества систем, вдохновлённых им. Вместо ожидания встроенной функции команды могут использовать проверенные расширения, которые чисто интегрируются с SQL и операционными инструментами.

Типичные примеры высокого уровня:

• Пользовательские типы данных: храните более богатые значения (геопозиции, диапазоны, структуры, похожие на JSON)
• Пользовательские функции: вносите доменную логику прямо в запросы и отчёты
• Опции индексирования: выбирайте разные типы индексов для разных паттернов доступа, чтобы один и тот же SQL‑запрос стал намного быстрее

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

Транзакции и конкурентность: получать корректные результаты в масштабе

Базы данных — это не только про хранение информации, но и про то, чтобы информация оставалась правильной, даже когда многое происходит одновременно. Для этого существуют транзакции и механизмы контроля конкурентности — причина, по которой SQL‑системы стали надёжными для реального бизнеса.

Что на самом деле гарантирует транзакция

Транзакция — это набор изменений, который должен либо полностью выполниться, либо полностью откатиться.

Если вы переводите деньги между счетами, размещаете заказ или обновляете инвентарь, недопустимы «половинчатые» результаты. Транзакция гарантирует, что вы не получите ситуацию, где заказ списал деньги, но не зарезервировал товар — или товар уменьшился без соответствующего заказа.

Практически транзакции дают:

• Понятную людям согласованность: база не «частично» применяет изменения
• Восстанавливаемость: при сбое система может откатиться в безопасное состояние

Конкурентность: реальная вселенная проблем для баз

Конкурентность — это когда много людей и приложений одновременно читают и меняют данные: кассы клиентов, операторы поддержки, фоновые джобы, аналитики.

Без правил появляются проблемы вроде:

• Потерянных обновлений: два пользователя редактируют одну запись; один перезаписывает другого
• Грязных чтений: кто‑то видит данные, которые потом откатываются
• Непоследовательных отчётов: запрос видит смесь «до» и «после» состояний

MVCC простыми словами

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

Большой плюс в том, что чтения реже блокируют записи, а писатели не так часто задерживаются из‑за долгих запросов. Вы всё ещё получаете корректность, но с меньшими задержками.

Почему это важно в современных SQL‑нагрузках

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

Колоночные хранилища: перелом в аналитической производительности

Рядовые (row‑ориентированные) базы проектировались для обработки транзакций: много мелких чтений и записей, обычно затрагивающих одну запись. Такой подход хорош, когда нужно быстро получить или обновить всю запись.

Ряды против колонок (аналогия из жизни)

Представьте таблицу. Row‑store — как хранить каждую строку в отдельной папке: когда нужно «всё про Заказ #123», вы достаёте одну папку и всё. Column‑store — как хранить по столбцам: один ящик для «order_total», другой для «order_date», третий для «customer_region».

Для аналитики вам редко нужна вся папка — чаще вы спрашиваете «Какой был общий доход по регионам за прошлый квартал?». Такой запрос затрагивает несколько полей на миллионах строк.

Почему аналитика любит колонки

Аналитические запросы часто:

• Сканируют большие части таблицы
• Используют всего несколько столбцов
• Интенсивно агрегируют (SUM/AVG/COUNT) и фильтруют

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

Сжатие — не только экономия места

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

Более масштабный сдвиг

Колоночные хранилища обозначили переход от OLTP‑первичных систем к аналитическим двигателям, где сканирование, сжатие и быстрые агрегаты становятся первичными целями дизайна, а не побочным эффектом.

Vertica и MPP‑аналитика: масштабируем SQL для больших запросов

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

Что такое MPP (простыми словами)

MPP — это массово‑параллельная обработка. Проще говоря: много машин обрабатывают один SQL‑запрос одновременно.

Вместо одного сервера, читающего все данные и выполняющего группировки и сортировки, данные разделяются по узлам. Каждый узел обрабатывает свою часть параллельно, а система объединяет частичные результаты в окончательный ответ.

Это позволяет сократить минуты до секунд — при условии, что данные хорошо распределены и запрос можно распараллелить.

Что это даёт на практике

Системы типа Vertica хороши, когда у вас много строк и нужно эффективно сканировать, фильтровать и агрегировать. Типичные кейсы:

• Дашборды, читающие большие факт‑таблицы (продуктовая аналитика, маркетинг, операционные метрики)
• Плановые отчёты и ad‑hoc SQL‑анализ
• Большие агрегации (кохорты, воронки, top‑N, rollup по многим измерениям)

Компромиссы по сравнению с транзакционными базами

MPP‑аналитика не заменяет транзакционные системы. Они оптимизированы для чтения множества строк и вычисления сводок, а не для частых мелких обновлений.

Типичные компромиссы:

• Актуальность: данные часто приходят батчами или микро‑батчами, а не по строке
• Обновления: частые одиночные обновления/удаления обычно медленнее или операционно сложнее
• Задержка: отличны для аналитики с задержками в секундах‑минутах; не подходят для миллисекундных пользовательских транзакций

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

Инновации исполнения запросов, ускорившие аналитику

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

Аналитические проекты Стоунбрейкера подчёркивали, что производительность запросов — это проблема исполнения не меньше, чем хранения. Это сместило фокус команд с оптимизации одиночных обращений на оптимизацию длинных сканов, соединений и агрегатов по миллионам/миллиардам строк.

Векторное исполнение (работаем пакетами, а не строка за строкой)

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

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

Проектирование, дружелюбное к памяти

Быстрые аналитические движки сосредоточены на эффективности CPU и кэша. Инновации исполнения обычно фокусируются на:

• Избегании лишней материализации (не строить большие промежуточные таблицы, если можно стримить результаты)
• Работе на сжатых данных, где возможно (меньше пропускной способности памяти, меньше передаваемых байт)
• Держании горячих данных в кэше (расположение и пакетирование, соответствующее реальным паттернам доступа CPU)

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

Где вы видите это сегодня

Современные хранилища данных и SQL‑движки — облачные хранилища, MPP‑системы и быстрые встроенные аналитические инструменты — часто по умолчанию используют векторное исполнение, операторы, осведомлённые о сжатии, и кэш‑дружественные конвейеры.

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

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

Потоковые системы: от пакетного мышления к реальным данным в реальном времени

Потоковые данные — это просто события, которые приходят непрерывно: платеж, показ товара, сенсорное чтение, лог‑строка. Каждое событие появляется в реальном времени и продолжается.

Почему пакетные базы кажутся медленными для живой работы

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

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

• Застарелые метрики (числа отстают от реальности)
• Отложенные оповещения (вы узнаёте о проблеме после ущерба)
• Ухищрения (частое опрос таблиц, постоянный перезапуск запросов)

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

Основные идеи: непрерывные запросы и окна

Непрерывный запрос — это как SQL‑запрос, который не «закрывается». Вместо единичного результата он обновляет результат по мере прихода новых событий.

Потоки бесконечны, поэтому используют окна (windows), чтобы ограничить вычисления: «последние 5 минут», «каждая минута» или «последние 1000 событий». Это позволяет считать скользящие счётчики, средние и топ‑N без переработки всего потока.

Бизнес‑примеры, где выгода очевидна

Реальное время особенно полезно, когда важна скорость реакции:

• Борьба с мошенничеством: выявление необычных трат за секунды
• Операционные оповещения: обнаружение всплесков ошибок сразу
• Живые продуктовые метрики: видеть регистрации и конверсии в реальном времени
• Видимость логистики: обновление ETA по мере сканов посылок

Нагрузочно‑ориентированная архитектура: правильный движок для задачи

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

Почему команды имеют несколько систем

Большинство современных стеков используют больше одной системы данных, потому что бизнес хочет разного рода ответы:

• OLTP‑БД (база приложений): быстрые вставки/обновления, строгая корректность, много пользователей
• Хранилище/аналитическая БД: быстрые чтения по большим объёмам, тяжёлая агрегация, длинные сканы
• Кэш/ключ‑значение: сверхбыстрые чтения для «горячих» данных (сессии, счётчики, feature flags)
• Потоковая обработка + лог: непрерывные события (клики, платежи, IoT), низколатентные пайплайны, метрики в реальном времени

Это практическое проявление «one size doesn’t fit all»: выбирают движки, соответствующие характеру работы.

Простой ориентир при выборе

Быстрый фильтр при обосновании ещё одной системы:

• Если нужны много мелких чтений/записей с транзакциями (заказы, профили пользователей) — начинайте с OLTP
• Если нужны большие запросы и агрегаты (недельная выручка, кохортный анализ) — добавляйте аналитическое хранилище
• Если нужны ответы за субсекунду при повторных запросах — вводите кэш
• Если нужны реакции в реальном времени на события (правила мошенничества, живые дашборды) — добавляйте стриминг

Как избежать раздутого парка инструментов

Несколько систем могут быть полезны, но только если у каждого есть чёткая нагрузка. Новый инструмент должен оправдать своё место сокращением затрат, латентности или риска — а не ради модного названия.

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

Как эти идеи проявляются в современной архитектуре данных

Исследовательские нити Стоунбрейкера — реляционные основы, расширяемость, колоночные хранилища, MPP‑исполнение и «правильный инструмент для задачи» — видны в стандартных формах современных платформ данных.

Привычные архитектурные паттерны (и почему они такие)

Хранилище (warehouse) отражает десятилетия работы по оптимизации SQL, колоночному хранению и параллельному исполнению. Когда вы видите быстрые дашборды на огромных таблицах, часто за этим стоят колоночные форматы, векторное исполнение и MPP.

Lakehouse заимствует идеи хранилища (схемы, статистика, кэширование, оптимизация на основе стоимости), но опирает их на открытые форматы файлов и объектное хранилище. Сдвиг «хранилище дешёвое, вычисления эластичные» — новый; однако мышление о запросах и транзакциях под ним — нет.

MPP‑аналитические системы (shared‑nothing кластеры) — прямые наследники исследований, доказавших, что SQL масштабируется через партиционирование данных, вынос вычислений к данным и аккуратное управление перемещением данных при соединениях и агрегациях.

Где сегодня применяется SQL

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

• стабильный контракт для BI‑инструментов и аналитиков
• уровень переносимости при смене движков
• поверхность для управления (views, права, аудит доступа)

Даже если исполнение происходит в разных движках (батч, интерактив, стриминг), SQL часто остаётся языком для пользователей.

Моделирование данных и управление: схемы всё ещё важны

Гибкое хранение не отменяет потребности в структуре. Понятные схемы, документированные значения и контролируемая эволюция уменьшают поломки по цепочке.

Хорошее управление — это не бюрократия, а обеспечение надёжности данных: единые определения, владение, проверки качества и контроль доступа.

Чеклист без хайпа для выбора подхода

При оценке платформ спрашивайте:

1. Соответствие нагрузке: BI‑дашборды, ad‑hoc exploration, построение признаков для ML или операционные рабочие нагрузки?
2. Требования к задержке: секунды, минуты или часы? Нужна ли 스트иминговая свежесть?
3. Форма данных: широкие логи событий (хорошо для колоночных форматов) или много точечных lookups (часто лучше в других системах)?
4. Конкурентность: сколько пользователей/запросов одновременно и насколько они предсказуемы?
5. Требования к согласованности: нужны ли строгие транзакции или допустима сходимость со временем?
6. Операционная реальность: кто будет это запускать, какие есть навыки и какова модель отказа в 2 часа ночи?

Если вендор не может простыми словами соотнести продукт с этими пунктами, «инновация» может быть в основном упаковкой.

Ключевые выводы для команд, строящих или покупающих платформы данных

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

1) Соотнесите систему с нагрузкой (не ждите, что один движок победит везде)

Прежде чем сравнивать фичи, опишите, что вам действительно нужно делать:

• Аналитика: длинные сканирования, большие агрегации, много чтений
• Транзакции: много мелких обновлений, строгая корректность, быстрый отклик
• Смешанные нагрузки: и то, и другое, но часто за счёт настройки и приоритезации
• Реальное время: непрерывный приём и инкрементальные вычисления

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

2) Проектируйте на изменение, а не на сегодняшнюю схему

Команды недооценивают, как часто меняются требования: новые типы данных, метрики, правила соответствия, новые потребители.

Выбирайте платформы и модели данных, которые делают изменения обычным делом, а не риском:

• Чёткое разделение хранения, запросов и точек расширения
• Безопасные способы эволюции схем и выката новой логики
• Измеримая производительность, которая не разваливается с органическим ростом

3) Корректность — это фича продукта

Быстрые ответы ценны, только если они правильные. При оценке спрашивайте, как система обрабатывает:

• Параллельные записи (что происходит, когда два процесса обновляют одно и то же поле?)
• Изоляцию и согласованность (какие гарантии и какие компромиссы?)
• Операционные режимы отказа (перезапуски, частичные отказы, восстановление и бэфилы)

4) Практический чеклист оценки для неспециалистов

Запустите небольшой «proof на ваших данных», а не только демо:

• Протестируйте 3–5 репрезентативных запросов и измерьте время и стоимость.
• Прокачайте пик конкуренции (утренняя пятиминутка в понедельник).
• Подтвердите своевременность данных, шаги восстановления и кто может это оперировать ежедневно.

5) Перевод архитектурных решений в доставляемый софт

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

Если вы хотите быстро прототипировать без изобретения пайплайна заново, платформа для быстрого кодинга (vibe‑coding) вроде Koder.ai может помочь поднять веб‑приложения (React), бэкенды (Go + PostgreSQL) и даже мобильные клиенты (Flutter) из диалогового рабочего процесса. Это полезно при итерации схемы, создании небольшого внутреннего «data product» или валидации реального поведения нагрузки перед долгосрочными инфраструктурными решениями.

Дальше читать (чтобы построить интуицию)

Если хотите углубиться, ищите материалы по колоночному хранению, MVCC, MPP‑исполнению и потоковой обработке. Больше объяснений публикуется в /blog.