Предлагаем вашему вниманию перевод статьи Джозефа Хеллерштейна «Looking Back at Postgres», опубликованной в соответствии с международной лицензией Creative Commons «С указанием авторства» версии 4.0 (CC-BY 4.0). Авторы оставляют за собой право распространять эту работу на личных и корпоративных веб-сайтах с надлежащей ссылкой на источник.
Перевод выполнен Еленой Индрупской. От себя добавлю, что «программист, который отчаянно хотел построить систему с многоверсионностью» — судя по всему, Вадим Михеев, ну а «добровольцев из России», переписавших GiST, мы все хорошо знаем.
Это воспоминание о проекте Postgres, выполняемом в Калифорнийском университете в Беркли и возглавляемом Майком Стоунбрейкером (Mike Stonebraker) с середины 1980-х до середины 1990-х годов. В качестве одного из многих личных и исторических воспоминаний, эта статья была запрошена для книги [Bro19], посвященной награждению Стоунбрейкера премией Тьюринга. Поэтому в центре внимания статьи — руководящая роль Стоунбрейкера и его мысли о дизайне. Но Стоунбрейкер никогда не был программистом и не мешал своей команде разработчиков. Кодовая база Postgres была работой команды блестящих студентов и эпизодически—штатных университетских программистов, которые имели немного больше опыта (и только немного большую зарплату), чем студенты. Мне посчастливилось присоединиться к этой команде в качестве студента в последние годы проекта. Я получил полезный материал для этой статьи от некоторых более старших студентов, занятых в проекте, но любые ошибки или упущения являются моими. Если вы заметили какие-либо из них, пожалуйста, свяжитесь со мной, и я постараюсь их исправить.
Postgres был самым амбициозным проектом Майкла Стоунбрейкера — его серьезной попыткой создать универсальную систему баз данных. Продолжаясь десятилетие, проект породил больше статей, кандидатов наук, профессоров и компаний, чем какая-либо еще деятельность Стоунбрейкера. Проект также охватывал больше технической области, чем любая другая система, которую он построил. Несмотря на риск, присущий такому масштабу, Postgres также стал самым успешным программным артефактом, который вышел из исследовательских групп Стоунбрейкера, и его основным вкладом в открытый исходный код. Это пример «второй системы» [Bro75], которая имела успех. На момент написания статьи, т. е. более тридцати лет с начала проекта, система PostgreSQL с открытым исходным кодом является в мире самой популярной независимой системой баз данных с открытым исходным кодом и четвертой по популярности системой баз данных. Между тем компании, созданные из Postgres, произвели в общей сложности более 2,6 млрд. долл. США (в стоимости приобретения). По любым меркам видение Postgres Стоунбрейкера имело огромный продолжительный резонанс.
Стоунбрейкер имел огромный успех в начале карьеры с исследовательским проектом Ingres в Беркли [SHWK76] и последующим стартапом, который он основал вместе с Ларри Роу (Larry Rowe) и Юджином Вонгом (Eugene Wong): Relational Technology, Inc. (RTI).
По мере развития RTI в начале 1980-х годов Стоунбрейкер начал работать над поддержкой в СУБД типов данных, выходящих за рамки традиционных строк и столбцов исходной реляционной модели Кодда (Edgar Frank Codd). Мотивирующим примером в то время была потребность поддержки базами данных инструментов автоматизированного проектирования (САПР) для микроэлектронной промышленности. В статье 1983 г. Стоунбрейкер и студенты Брэд Рубенштейн (Brad Rubenstein) и Антонин Гуттман (Antonin Guttman) объяснили, насколько эта отрасль нуждается в поддержке «новых типов данных, таких как многоугольники, прямоугольники, текстовые строки и т. д.», «эффективного пространственного поиска», «сложных ограничений целостности», а также «проектных иерархий и множественных представлений» в одних и тех же физических конструкциях [SRG83]. Имея такую мотивацию, группа начала работу над индексированием (в том числе с помощью R-деревьев Гуттмана для пространственного индексирования [Gut84]) и над добавлением абстрактных типов данных (АТД) в систему реляционных баз данных. В то время АТД были популярной новой конструкцией языков программирования, которая была впервые введена Барбарой Лисков (Barbara Liskov), впоследствии лауреатом премии Тьюринга, и исследована в прикладном программировании баз данных новым сотрудником Стоунбрейкера — Ларри Роу. В статье в SIGMOD Record в 1983 г. [OFS83] Стоунбрейкер и студенты Джеймс Онг (James Ong) и Деннис Фогг (Dennis Fogg) описывают исследование этого понятия в расширении Ingres, названном ADT-Ingres, в которое были включены многие концепции представления, изученные более глубоко и с лучшей системной поддержкой в Postgres.
Как следует из названия, Postgres это «Post-Ingres»: система, предназначенная для того, чтобы взять то, что могла делать Ingres, и выйти за ее рамки. Отличительным признаком Postgres было введение того, что он в конечном итоге назвал объектно-реляционными свойствами базы данных: поддержка концепции объектно-ориентированного программирования в модели данных и декларативного языка запросов системы баз данных. Но Стоунбрейкер также задумал решить в Postgres ряд других независимых от объектно-ориентированной поддержки технологических проблем, таких как правила активной базы данных, версионные данные, третичное хранилище и параллелизм.
Две статьи были написаны по дизайну Postgres: описание раннего дизайна в SIGMOD 1986 г. [SR86] и промежуточное описание в CACM 1991 г. [SK91]. Исследовательский проект Postgres постепенно «сошел на нет» в 1992 году с основанием Стоунбрейкером стартапа Illustra, в котором участвовали Стоунбрейкер, ведущий аспирант Вэй Хонг и позже ставший главным программистом Джефф Мередит (Jeff Meredith). В списке, приведенном ниже, возможности, упомянутые в статье 1986 года, отмечены звездочкой*, а возможности из статьи 1991 года, которых не было в статье 1986 года, — крестиком†. За другие задачи, перечисленные ниже, брались в системе и исследовательской литературе, но их нет ни в одной спецификации дизайна. Многие из этих тем рассматривались в Postgres задолго до того, как они были изучены или заново изобретены другими. Во многих случаях Postgres слишком опередил свое время, и интерес к темам вспыхнул позже, уже под современным углом зрения.
Мы кратко обсудим вклад Postgres по каждой из этих позиций в его связи с последующими работами в области вычислений.
Четко сформулированной целью Postgres была поддержка новых объектно-реляционных свойств: расширение технологии баз данных, чтобы обеспечить преимущества как реляционной обработки запросов, так и объектно-ориентированного программирования. Со временем объектно-реляционная концепция, впервые появившиеся в Postgres, стала стандартной функциональностью в большинстве современных систем баз данных.
Довольно часто данные представляются в виде вложенных сущностей или «объектов». Классическим примером является заказ на покупку, который имеет вложенный набор продуктов, их количеств и цен. Религия реляционного моделирования диктовала, что такие данные должны быть реструктурированы и сохранены в формате без вложенности, используя несколько плоских таблиц объектов (заказы, продукты) с соединяющими их плоскими таблицами отношений (продукт_в_заказе). Типичная причина такого уплощения заключается в том, что оно уменьшает дублирование данных (т. к. продукт избыточно описывается во многих заказах на покупку), что, в свою очередь, позволяет избежать сложности или ошибок при обновлении всех избыточных копий. Но в некоторых случаях вы хотите сохранить вложенное представление, потому что это естественно для приложения (например, механизм компоновки схемы в САПР), а обновления редки. Этот спор о моделировании данных по крайней мере так же стар, как и реляционная модель.
Ключевым подходом Postgres было «усидеть на двух стульях» с точки зрения моделирования данных: Postgres сохранил таблицы как «самый внешний» тип данных, но позволил столбцам иметь «сложные» типы, включая вложенные кортежи или таблицы. Одна из его малораспространенных реализаций, впервые исследованная в прототипе ADT-Ingres, заключалась в том, чтобы разрешить задавать столбец табличного типа декларативно, как определение запроса: «Quel как тип данных» [SAHR84] (Quel — язык запросов Ingres. — Прим. пер.).
«Постреляционная» тема поддержки как декларативных запросов, так и вложенных данных вновь возникала на протяжении многих лет, часто порождаемая спорами о том, что лучше. Во времена Postgres в 1980-х и 1990-х годах некоторые группы, занимающиеся объектно-ориентированными базами данных, подхватили эту идею и развили ее в стандартный язык OQL, который затем перестал использоваться.
На рубеже тысячелетий декларативные запросы к вложенным объектам стали навязчивой идеей исследований для сегмента сообщества разработчиков баз данных в виде баз данных XML. Получившийся в результате язык XQuery (во главе с Доном Чемберлином (Don Chamberlin) — персоной SQL) обязан поддержке сложных объектов языку Postquel из Postgres. XQuery получил широкое распространение и использование в промышленности, но никогда не был популярен у пользователей. Сегодня эти концепции вновь рассматриваются в проектах языков запросов для модели данных JSON, популярной в браузерных приложениях. Как и OQL, в группах, которые первоначально отвергали декларативные запросы в пользу программирования, ориентированного на разработчиков (движение «NoSQL»), эти языки часто возникают как запоздалое дополнение исключительно из желания добавить запросы обратно в системы. В то же время по мере роста Postgres с годами (и перехода от языка запросов Postquel к версиям SQL, которые отвечают многим из рассматриваемых целей), он включил поддержку вложенных данных, таких как XML и JSON, в СУБД общего назначения, не требуя какого-либо значительного перепроектирования. Споры протекают с переменным успехом, а подход Postgres к расширению реляционной структуры с помощью расширений для вложенных данных не раз показал себя естественным конечным состоянием для всех сторон после того, как аргументы утихают.
В дополнение к предложению вложенных типов Postgres выдвинул идею ввести непрозрачные, расширяемые АТД, которые хранятся в базе данных, но не интерпретируются ядром. В принципе, это всегда было частью реляционной модели Кодда: целые числа и строки были традиционными, но на самом деле реляционная модель охватывает любые атомарные типы данных с предикатами. Задача состояла в том, чтобы обеспечить такую математическую гибкость и в программном обеспечении. Чтобы использовать запросы, которые интерпретируют эти объекты и манипулируют ими, прикладной программист должен иметь возможность регистрировать в системе определяемые пользователем функции (user-defined functions — UDF) для этих типов и вызывать эти функции в запросах. Также желательно, чтобы определяемые пользователем агрегатные (user-defined aggregate — UDA) функции суммировали коллекции этих объектов в запросах. Система баз данных Postgres была новаторской, всесторонне поддерживая эти возможности.
Зачем помещать такую функциональность в СУБД, а не в высокоуровневые приложения? Типичным ответом на этот вопрос было значительное преимущество в производительности кода, помещенного к данным, перед «вытягиванием» данных к коду. Postgres показал, что это вполне естественно в рамках реляционной среды: потребовались лишь небольшие изменения в каталоге реляционных метаданных и были созданы механизмы вызова стороннего кода, но синтаксис запросов, семантика и системная архитектура работали просто и элегантно.
Postgres немного опередил свое время в исследовании этой функциональности. В частности, в то время сообщество исследователей баз данных не особенно беспокоилось о последствиях для безопасности при загрузке небезопасного кода на сервер. Это стало восприниматься как проблема, когда технологию заметили в индустрии. Стоунбрейкер вывел на рынок Postgres в своем стартапе Illustra, который был приобретен Informix в значительной степени за его способность поддерживать пакеты расширений DataBlade, в том числе UDF. Informix с технологией, основанной на Postgres, и сильным предложением параллельных баз данных стала значительной угрозой Oracle. Oracle инвестировала значительные средства в негативный маркетинг рисков, связанных со способностью Informix запускать «незащищенный» пользовательский C-код. Некоторые относят гибель Informix к этой кампании, хотя финансовые махинации Informix (и последующее федеральное обвинение его тогдашнего генерального директора), безусловно, представляли собой более серьезные проблемы. Теперь, десятилетия спустя, все основные поставщики баз данных поддерживают выполнение пользовательских функций на одном или более языках, используя новые технологии защиты от сбоев сервера или повреждения данных.
Между тем, технологические стеки больших данных 2000-х годов, включая феномен MapReduce, который «много крови попортил» Стоунбрейкеру и ДеВитту (David DeWitt) [DS08], являются повторной реализацией идеи Postgres — пользовательского кода, размещенного в рамках запроса. Представляется, что MapReduce во многом сочетает идеи разработки программного обеспечения от Postgres с идеями параллелизма от таких систем, как Gamma и Teradata, с некоторыми незначительными инновациями вокруг перезапуска в процессе выполнения запроса для рабочих нагрузок с экстремальной масштабируемостью. Стартапы на базе Postgres, Greenplum и Aster, примерно в 2007 году показали, что распараллеливание Postgres может привести к чему-то гораздо более функциональному и практичному, чем MapReduce, для большинства клиентов, но в 2008 году рынок все еще не был готов к этой технологии. К настоящему времени, в 2018 году, почти каждый стек больших данных в основном обслуживает рабочую нагрузку параллельного SQL с UDF, что очень похоже на дизайн, который Стоунбрейкер с командой впервые использовали в Postgres.
Реляционные базы данных развивались примерно в то же время, что и B-деревья, в начале 1970-х годов, и B-деревья помогли дать импульс мечте Кодда о «независимости от физического хранения данных»: индексирование B-деревьями обеспечивает уровень косвенности, который адаптивно реорганизует физическое хранилище, не требуя изменения приложений. Основным ограничением B-деревьев и связанных с ними структур было то, что они поддерживают только поиск по равенству и запросы одномерного диапазона. А что делать, если у вас есть запросы 2-мерного диапазона, типичные для картографии и приложений САПР? Эта проблема была известна во время Postgres, и R-дерево [Gut84], разработанное Антонином Гуттманом в группе Стоунбрейкера, было одним из самых успешных новых индексов, разработанных для решения этой проблемы на практике. Тем не менее, изобретение индексной структуры не решает для комплексных систем задачу поддержки в СУБД многомерных диапазонов. Возникает много вопросов. Можете ли вы легко добавить метод доступа, такой как R-деревья, в свою СУБД? Можете ли вы научить оптимизатор понимать, что указанный метод доступа будет полезен для определенных запросов? Вы можете добиться корректности восстановления и одновременного доступа? Это был очень смелый пункт программы действий Postgres: проблема архитектуры программного обеспечения, затрагивающая большую часть ядра базы данных, от оптимизатора до уровня хранения, а также системы журналирования и восстановления. R-деревья в Postgres стали мощной движущей силой и основным примером элегантной расширяемости уровня метода доступа и его интеграции в оптимизатор запросов. Postgres показал, способом непрозрачных АТД, как зарегистрировать абстрактно описанный метод доступа (в данном случае R-дерево), и как оптимизатор запросов может распознать абстрактный предикат выборки (в данном случае выбор диапазона) и сопоставить его с этим абстрактно описанным методом доступа. Вопросам управления одновременным доступом было уделено меньше внимания в первоначальной работе: отсутствие одномерного упорядочения ключей сделало в данном случае блокировку, применяемую в B-деревьях, неприменимой.
Многообещающие возможности расширяемых методов доступа Postgres вдохновили один из моих первых исследовательских проектов в конце аспирантуры: обобщенные деревья поиска (Generalized Search Trees—GiST) [HNP95] и последующую концепцию теории индексируемости [HKM+02]. Я реализовал GiST в Postgres в течение семестра после получения докторской степени, что сделало добавление новой логики индексирования в Postgres еще проще. В диссертации Марселя Корнакера из Беркли (Marcel Kornacker) решены сложные задачи восстановления и одновременного доступа, поставленные расширяемым «шаблонным» типом индекса GiST [KMH97].
Сегодня PostgreSQL выгодно сочетает оригинальную программную архитектуру расширяемых методов доступа (она имеет индексы B-tree, GiST, SP-GiST и Gin) с расширяемостью и интенсивным конкурентным доступом интерфейса обобщенного дерева поиска (GiST). Индексы GiST поддерживают популярную гео-информационную систему PostGIS на базе PostgreSQL. Индексы Gin обеспечивают внутреннюю поддержку индексирования текста в PostgreSQL.
В традиционной оптимизации запросов задача состояла в том, чтобы свести к минимуму объем потока кортежей (и, следовательно, операций ввода-вывода), создаваемых при обработке запроса. Это означало, что операторы, которые фильтруют кортежи (выборка), хороши в начале плана запроса, в то время как операторы, которые могут генерировать новые кортежи (соединение), должны быть выполнены позже. В результате оптимизаторы запросов будут «выталкивать» операторы выборки ниже соединений и упорядочивать их произвольно, сосредотачиваясь вместо этого на умной оптимизации соединений и обращений к диску. UDF изменили подход: если у вас в операторах выборки дорогостоящие UDF, порядок выполнения UDF может иметь решающее значение для оптимизации производительности. Более того, если UDF в операторе выборки действительно занимает много времени, возможно, выборку следует выполнять после соединений (т. е. выполнить «подтягивание» выборки вверх — selection «pullup»). Учет этих факторов усложнил пространство поиска для оптимизатора. Я взял эту проблему как первую сложную задачу в аспирантуре, и кончилось тем, что она стала предметом моей магистерской работы со Стоунбрейкером в Беркли и моей кандидатской в Висконсине под руководством Джеффа Нотона (Jeff Naughton), но при постоянной помощи советами от Стоунбрейкера. СУБД Postgres была первой, которая сохраняла стоимость и избирательность пользовательских функций в каталоге базы данных. Мы подошли к задаче оптимизации, придумав оптимальный порядок операций выборки, а затем оптимальное чередование операций выборки вдоль ветвей каждого дерева соединений, рассматриваемого при поиске плана. Это позволило оптимизатору поддерживать архитектуру классического динамического программирования System R с небольшой дополнительной стоимостью сортировки для правильного упорядочения дорогостоящих операторов выборки.
Когда я поступил в аспирантуру, это была одна из трех тем, которые Стоунбрейкер написал на доске в своем кабинете как варианты для выбора темы моей диссертации. Кажется, второй темой было индексирование функций, а третьей я не помню.
Оптимизация дорогостоящих функций была отключена в деревьях исходного кода PostgreSQL на ранней стадии в значительной степени потому, что в то время не было убедительных вариантов использования дорогостоящих пользовательских функций. Примеры, которые мы использовали, вращались вокруг обработки изображений и, наконец, в 2018 году они становятся востребованными задачами обработки данных. Конечно, сегодня, в эпоху больших данных и рабочих нагрузок машинного обучения, дорогостоящие функции стали довольно распространенным явлением, и я ожидаю, что эта проблема вернется на передний план. В очередной раз отметим, что Postgres сильно опередил свое время.
По иронии судьбы, код, написанный мною в аспирантуре, был полностью удален из дерева исходных текстов PostgreSQL молодым программистом по имени Нил Конвей (Neil Conway), который несколько лет спустя начал делать кандидатскую диссертацию под моим руководством в Калифорнийском университете в Беркли и теперь является одним из «кандидатских внуков» Стоунбрейкера.
Проект Postgres начался на исходе интереса сообщества искусственного интеллекта к программированию на основе правил как способу представления знаний в экспертных системах. Такой ход мысли не привел к успеху: многие считают, что это вызвало широко обсуждаемую «зиму искусственного интеллекта», которая продолжалась на протяжении 1990-х годов.
Однако программирование на основе правил сохранялось в сообществе разработчиков баз данных в двух формах. Первая — теоретическая работа вокруг декларативного логического программирования с использованием Datalog. Она была «костью в горле» для Стоунбрейкера: он, казалось, действительно ненавидел эту тему и хлестко критиковал ее в нескольких докладах сообщества на протяжении многих лет.
Datalog выжил как математическая основа для декларативных языков и со временем нашел применение в различных областях информатики, включающих программно-конфигурируемые сети и компиляторы. Datalog — это декларативное построение запросов «на стероидах» как вполне выразительная модель программирования. В конце концов я был вовлечен в это, как в естественный вариант дизайна, и следовал этому в различных прикладных настройках за пределами традиционных систем баз данных.
Второй круг вопросов, связанных с правилами баз данных, был практической работой над тем, что в конечном итоге было названо активными базами данных и триггерами баз данных, которые развились в стандартную функциональность реляционных СУБД. Стоунбрейкер в свойственной ему манере проголосовал ногами за работу над более практическим вариантом.
Работа Стоунбрейкера над правилами баз данных началась с кандидатской работы Эрика Хэнсона (Eric Hanson), которая первоначально делалась для Ingres, но быстро переместилась в новый проект Postgres. Она была расширена в кандидатской работе Спироса Потамианоса (Spyros Potamianos) над PRS2: Postgres Rules System 2. Темой в обеих реализациях была возможность реализовать правила двумя различными способами. Один из них — трактовать правила как перезапись запросов. Это напоминает работу над перезаписью представлений, что впервые сделал Стоунбрейкер в Ingres. В этом сценарии логика правила «при условии выполнить действие» преобразуется в «при запросе перезаписать его и выполнить вместо исходного». Например, запрос типа «добавить новую строку к списку наград Майка» может быть переписан как «повысить зарплату Майка на 10%». Другой способ состоял в том, чтобы реализовать более естественное «при условии выполнить действие», проверяя условия на уровне строк с помощью блокировок внутри базы данных. При обнаружении таких блокировок результатом было не ожидание (как в традиционном управлении одновременным доступом), а выполнение соответствующего действия.
Код для правил уровня строк в PRS2 был, как печально известно, сложным. Небольшим поиском в архивах Postgres в Беркли был обнаружен следующий комментарий (вероятно, Спироса Потамианоса) к исходному коду Postgres версии 3.1 примерно 1991 года (дается в переводе):
В итоге для реализации правил в Postgres ни метод перезаписи запросов, ни метод блокировки на уровне строк не были объявлены «победителями» — оба были сохранены в выпущенной системе. В конце концов код всех правил был забракован и переписан в PostgreSQL, но текущий исходный код по-прежнему сохраняет оба понятия триггеров на уровне операторов и на уровне строк.
Системы правил Postgres в свое время имели очень большое влияние и шли «ноздря в ноздрю» с исследованиями по проектам IBM Starburst и MCC HiPAC. Сегодня триггеры являются частью стандарта SQL и реализованы в движках многих основных баз данных. Однако они используются с некоторой осторожностью. Одна из проблем заключается в том, что наработки, о которых говорилось, так и не преодолели негативных моментов, которые привели к «зиме искусственного интеллекта»: взаимодействия в нагромождении правил могут стать неприемлемо запутанными, даже когда набор правил растет незначительно. Кроме того, на практике по-прежнему выполнение триггеров обычно занимает относительно много времени, поэтому внедряемые базы данных, которые должны работать быстро, как правило, избегают использования триггеров. Однако была некоторая кустарщина в смежных областях, таких как поддержка материализованных представлений, обработка сложных событий и потоковые запросы, каждая из которых в некотором роде является расширениями идей, исследованных в системах правил Postgres.
Стоунбрейкер описал свой дизайн системы хранения Postgres таким образом:
Xранилище Postgres объединило понятия основного хранилища и журналирования исторической информации в единое простое дисковое представление. В своей основе идея заключалась в том, чтобы хранить каждую запись в базе данных в связанном списке версий, помеченных идентификаторами транзакций, — в некотором смысле это «журнал как данные» или «данные как журнал» в зависимости от вашей точки зрения. Единственные дополнительные метаданные, которые необходимы, — это список идентификаторов завершенных транзакций и времени их фиксации. Этот подход значительно упрощает восстановление, так как нет «перевода» из журнального представления обратно в основное представление. Он также делает возможными темпоральные запросы: вы можете выполнять запросы по состоянию на некоторый момент времени и получать доступ к версиям данных, которые были зафиксированы в это время. Первоначальный дизайн системы хранения Postgres, который выглядит так, как будто Стоунбрейкер описал его в одном творческом сеансе мозгового штурма, рассматривал ряд проблем эффективности и оптимизации базовой схемы наряду с грубым анализом того, как может повести себя производительность [Sto87]. Итоговая реализация в Postgres была несколько проще.
Мнение Стоунбрейкера о «радикальной простоте» транзакционного хранилища было глубоко противоположно принятым в сообществе в то время, когда поставщики баз данных выделяли себя, инвестируя значительные средства в алгоритмы высокопроизводительной обработки транзакций. В то время победители сравнительных тестов достигали высокой производительности и возможности восстановления благодаря хорошо оптимизированным системам ведения журнала упреждающей записи. После того, как они получили хорошо работающие журналы упреждающей записи, поставщики также начали нововведения следующего этапа, такие как транзакционная репликация на основе доставки журнала, что было трудно осуществить в Postgres. В итоге система хранения Postgres так и не отличилась в производительности. Версионность и темпоральные запросы были позже удалены из PostgreSQL и заменены использованием журнала упреждающей записи.
К сожалению, PostgreSQL все еще не особенно быстро обрабатывает транзакции: использование в нем журнала упреждающей записи несколько половинчато. Как ни странно, команда PostgreSQL сохранила много служебной информации, хранимой вместе с кортежами в Postgres, для обеспечения многоверсионности, что никогда не было целью проекта Postgres в Беркли. Результатом является система хранения, которая может эмулировать изоляцию снимков (snapshot isolation) Oracle с изрядным объемом дополнительных накладных расходов ввода-вывода, но которая не следует первоначальной мысли Стоунбрейкера о темпоральных запросах или простом восстановлении.
Майк Олсон (Mike Olson) отмечает, что его первоначальное намерение состояло в том, чтобы заменить реализацию B-дерева Postgres своей собственной реализацией B-дерева из проекта Berkeley DB, который разрабатывался в Беркли в эпоху Postgres. Но Олсон так и не нашел на это времени. Когда годы спустя Berkeley DB получила поддержку транзакций в Sleepycat Corp., Олсон попытался убедить (тогдашнее) сообщество PostgreSQL использовать его для восстановления вместо хранилища «без перезаписи». Они отказались: в проекте был программист, который отчаянно хотел построить систему с многоверсионностью (MVCC), и поскольку он был готов выполнить работу, он выиграл спор.
Медленно работающее хранилище PostgreSQL не является внутренне присущим системе. В Greenplum ветка PostgreSQL в качестве интересной альтернативы интегрировала высокопроизводительное сжатое хранилище. Оно было разработано Мэттом МакКлином (Matt McCline)—ветераном команды Джима Грея (Jim Gray) в компании Tandem. Оно также не поддерживало темпоральных запросов.
Но возможность темпоральных запросов была интересной и оставалась уникальной. Более того, кредо Стоунбрейкера в отношении разработки простого программного обеспечения для восстановления данных сегодня имеет отголоски как в контексте систем NoSQL (которые выбирают репликацию, а не WAL), так и в базах данных основной памяти (MMDB — main memory databases, которые часто используют многоверсионность и сжатые журналы фиксации). Идея версионных реляционных баз данных и темпоральных запросов сегодня все еще отнесена к эзотерике, появляясь в случайных исследовательских прототипах и небольших проектах с открытым исходным кодом. Это идея, которая созрела для возвращения в нашу эпоху дешевого хранения и непрерывных потоков данных.
В середине проекта Postgres Стоунбрейкер подписался в качестве одного из руководителей на большой грант по научному направлению «цифровая земля» под названием Project Sequoia. Часть грантового предложения заключалась в обработке беспрецедентных объемов цифровых спутниковых изображений, требующих до 100 терабайт памяти, т. е. намного большего объема данных, чем в то время было бы разумно хранить на магнитных дисках. В основе предлагаемого решения было исследовать идею создания СУБД (а именно Postgres), облегчающей доступ к полуавтономному «третичному» хранилищу, предоставляемому роботизированными накопителями с автоматической сменой дисков для управления библиотеками оптических дисков или лент.
Из этого вытекало несколько разных исследований. Одним из них была файловая система Inversion — попытка предоставить абстракцию файловой системы UNIX над реляционной СУБД. В обзорной статье для Sequoia Стоунбрейкер описал это в своем обычном стиле свысока как «простое упражнение» [Sto95]. На самом деле Майк Олсон, студент Стоунбрейкера (и последующий основатель компании Cloudera), был занят этим в течение нескольких лет, да и конечный результат не был вполне однозначным [Ols93] и не выжил на практике.
На несколько лет позже Inversion Билл Гейтс «бился с теми же ветряными мельницами» в WinFS — попытке воссоздать наиболее широко используемую в мире файловую систему над серверной частью реляционной базы данных. WinFS поставлялась в разработческих версиях Windows, но так и не вышла на рынок. Гейтс позже назвал это своим самым большим в Microsoft разочарованием.
Другим основным направлением исследований на этом фронте было включение третичного хранилища в стек более типичных реляционных баз данных, что было предметом кандидатской диссертации Суниты Сараваги (Sunita Sarawagi). Основной темой было изменение масштаба, в котором вы мыслите управление пространством (т. е. данными в хранилище и иерархии памяти) и временем (координация планирования запросов и кеша для минимизации нежелательных операций ввода-вывода). Одной из ключевых проблем в этой работе было хранение больших многомерных массивов в третичном хранилище и извлечение их, что перекликается с работами в области многомерного индексирования. Основные идеи включали разбиение массива на порции и хранение вместе порций, которые выбираются вместе, а также репликацию порций, чтобы указанная порция данных могла иметь нескольких физических «соседей». Вторая проблема — подумать о том, как диск становится кешем для третичного хранилища. Наконец, оптимизация запросов и планирование должны были учитывать длительное время загрузки данных из третичного хранилища и важность попаданий (hits) кеша диска. Это влияет как на план, выбираемый оптимизатором запросов, так и на время, на которое этот план намечен к выполнению.
Роботы на лентах и оптических дисках в настоящее время широко не используются. Но проблемы третичного хранилища очень распространены в облаке, которое в 2018 году имеет глубокую иерархию хранения: от присоединенных твердотельных дисков к услугам надежного дископодобного хранилища (например, AWS EBS), к архивному хранилищу (например, в AWS S3), к глубокому хранилищу (например, AWS Glacier). Сегодня эти уровни хранения по-прежнему относительно обособлены, и рассуждения о сквозном хранилище, охватывающем эти уровни, практически не поддерживаются базой данных. Я не удивлюсь, если вопросы, исследованные на этом фронте в Postgres, будут пересмотрены в ближайшее время.
Стоунбрейкер никогда не создавал большую параллельную систему баз данных, но он руководил многими стимулирующими дискуссиями в этой области. Его статья «Case for Shared Nothing» (Случай для систем без разделяемых ресурсов) [Sto86] задокументировал крупномодульные архитектурные решения в этой области. Он популяризировал терминологию, используемую в отрасли, и озадачил поддержкой архитектур без совместно используемых ресурсов, таких как Gamma и Teradata, которые были заново открыты в 2000-х годах сообществом работающих над большими данными.
По иронии судьбы, самым существенным вкладом Стоунбрейкера в область параллельных баз данных была архитектура «общей памяти» под названием XPRS, что означало «eXtended Postgres on RAID and Sprite». В начале 1990-х годов XPRS была «лигой справедливости» систем Беркли: она объединяет в сокращенном виде систему Postgres Стоунбрейкера, распределенную ОС Sprite Джона Остерхаута (John Ousterhout) и архитектуру RAID-хранилищ Дейва Паттерсона (Dave Patterson) и Рэнди Каца (Randy Katz). Как и для многих межфакультетских работ, выполнение проекта XPRS фактически определялось аспирантами, которые работали над ним. Оказалось, что основной вклад внес Вэй Хонг, который написал свою кандидатскую диссертацию по оптимизации параллельных запросов в XPRS. Таким образом, основным вкладом XPRS в литературу и индустрию была оптимизация параллельных запросов без существенного рассмотрения проблем, связанных с RAID или Sprite.
Из этих трех проектов огромное влияние на дальнейшее оказали Postgres и RAID. Sprite лучше всего помнят по кандидатской диссертации Менделя Розенблюма (Mendel Rosenblum) о файловых системах с журнальной структурой (Log Structured File Systems — LFS), которая не имела ничего примечательно общего с распределенными операционными системами. Все три проекта содержали новые идеи для дискового хранения, помимо видоизменения отдельных копий по месту. LFS и менеджер хранилища Postgres довольно похожи новым отношением к журналу как к основному хранилищу и необходимостью дорогостоящей фоновой реорганизации. Однажды я осторожно прощупывал Стоунбрейкера на предмет соперничества LFS и Postgres или академических «жареных фактов» об их взаимоотношениях, но я так и не узнал от него ничего интересного. Возможно, в то время в Беркли кто-то «мутил воду».
В принципе, параллелизм «взрывает» пространство планов оптимизатора запросов, умножая традиционные варианты выбора, сделанные во время оптимизации запросов (доступ к данным, алгоритмы соединений, порядок соединений), на все возможные способы распараллеливания каждого варианта выбора. Основная идея названного Стоунбрейкером «оптимизатора Вэя Хонга» заключалась в том, чтобы разбить проблему на две: запустить традиционный оптимизатор запросов в духе System R для одного узла, а затем «распараллелить» получившийся план, запланировав степень параллелизма и размещение каждого оператора, исходя из представления данных и конфигурации системы. Этот подход эвристичен, но в нем параллелизм наращивает стоимость традиционной оптимизации запросов аддитивно, а не мультипликативно.
Хотя оптимизатор Вэя Хонга был разработан в контексте Postgres, он стал стандартным подходом для многих оптимизаторов параллельных запросов в отрасли.
Среди интересов Стоунбрейкера, неоднократно возобновляющихся со времен Ingres, был интерфейс прикладного программирования (API) системы баз данных. В свои лекции из серии Database Systems (Системы баз данных) он часто включал язык GEM Карло Заниоло (Carlo Zaniolo) как тему, которую важно понять поборникам систем баз данных. Этот интерес к языку, несомненно, привел его к партнерству с Ларри Роу в Postgres, что, в свою очередь, глубоко повлияло на дизайн модели данных Postgres и ее объектно-реляционный подход. Их работа была сосредоточена в основном на приложениях для работы с большим объемом данных из коммерческой сферы, включающих как обработку деловой информации, так и новые приложения, такие как САПР/АСУП и ГИС.
Одной из проблем, которая была навязана в то время Стоунбрейкеру, была идея «спрятать» границы между конструкциями языка программирования и хранилищем базы данных. Различные конкурирующие исследовательские проекты и компании, исследующие объектно-ориентированные базы данных (Object-Oriented Databases — OODB), были нацелены на так называемую «потерю соответствия» между императивными объектно-ориентированными языками программирования, такими как Smalltalk, C++ и Java, и декларативной реляционной моделью. Идея OODB состояла в том, чтобы сделать объекты языка программирования при желании помечаемыми как «постоянные» и автоматически обрабатываемыми встроенной СУБД. Postgres поддерживал хранение вложенных объектов и абстрактных типов данных, но его интерфейс, основанный на декларативных запросах в реляционном стиле, предполагал неестественные для программиста обращения к базе данных (требовал от него использования декларативных запросов), которые к тому же были дорогостоящими (требовали синтаксического разбора и оптимизации). Чтобы конкурировать с поставщиками OODB, Postgres предоставил так называемый интерфейс «быстрого пути» (Fast Path): по сути API C/C++ к внутреннему устройству хранения базы данных. Это позволило Postgres иметь среднюю производительность по академическим тестам OODB, но так никогда и не решило задачи позволить программистам на разных языках избежать проблемы потери соответствия. Вместо этого Стоунбрейкер навесил на модель Postgres ярлык «объектно-реляционной» и просто обошел стороной применение объектно-ориентированных баз как невыгодный рынок (zero-billion dollar market). Сегодня практически все коммерческие системы реляционных баз данных являются «объектно-реляционными» системами баз данных.
Это оказалось разумным решением. Сегодня ни один из продуктов OODB не существует в своей задуманной форме, и идея «постоянных объектов» в языках программирования была большей частью отброшена. В отличие от этого, широко распространено использование слоев объектно-реляционного отображения (object-relational mapping — ORM, подпитываемое ранними работами, такими как Java Hibernate и Ruby on Rails), что позволяет относительно гладко «подгонять» декларативные базы данных почти под любой императивный объектно-ориентированный язык программирования в качестве библиотек. Этот подход на уровне приложения отличается как от OODB, так и от объектно-реляционных баз данных по Стоунбрейкеру. Кроме того, легковесные хранилища «ключ-значение» также успешно используются как в бестранзакционной, так и в транзакционной форме. Их первооткрывателем была аспирантка Стоунбрейкера Марго Зельцер (Margo Seltzer), которая работала над базой данных Berkeley DB в рамках своей кандидатской диссертации в то же время, что и группа Postgres, что предвосхитило рост таких распределенных NoSQL-хранилищ «ключ-значение», как Dynamo, MongoDB и Cassandra.
Postgres всегда был проектом с открытым исходным кодом с равномерными релизами, но вначале длительное время он был нацелен на использование в исследованиях, а не в производстве.
Поскольку исследовательский проект Postgres сворачивался, два студента Стоунбрейкера Эндрю Ю (Andrew Yu) и Джолли Чен (Jolly Chen) модифицировали синтаксический анализатор системы, чтобы заменить оригинальный язык Postquel расширяемым вариантом SQL. Первым релизом Postgres, поддерживающим SQL, был Postgres95, а следующий был назван PostgreSQL.
Группа разработчиков открытого исходного кода заинтересовалась PostgreSQL и «приняла» его даже тогда, как интересы остальной части команды Беркли изменились. Группа основных разработчиков PostgreSQL со временем остается относительно стабильной, и проект с открытым исходным кодом стал высокоразвитым. Вначале усилия были сосредоточены на стабильности кода и функциональности, видимой пользователю, но со временем сообщество разработчиков программного обеспечения с открытым исходным кодом значительно изменило и усовершенствовало ядро системы, от оптимизатора до методов доступа и основной системы транзакций и хранения. С середины 1990-х годов очень небольшая часть внутренних составляющих PostgreSQL исходила от академической группы в Беркли. Последним ее вкладом, возможно, была моя реализация GiST во второй половине 1990-х годов, но даже она была существенно переписана и очищена добровольцами из сообщества открытого исходного кода (в данном случае из России). Часть сообщества открытого исходного кода, что работает над PostgreSQL, заслуживает величайшей похвалы за осуществление упорядоченного процесса, который на протяжении десятилетий служил созданию в высшей степени эффективного и долгосрочного проекта.
Хотя многое изменилось за 25 лет, базовая архитектура PostgreSQL остается очень похожей на университетские релизы Postgres начала 1990-х годов, и разработчикам, знакомым с текущим исходным кодом PostgreSQL, будет нетрудно читать исходный код Postgres 3.1 (1991 г.). Все, от структуры каталогов исходного кода до структур процессов и структур данных, остается удивительно похожим. Код из команды Postgres в Беркли имел отличный костяк.
Сегодня PostgreSQL, без сомнения, является самой высокопроизводительной СУБД с открытым исходным кодом, причем она поддерживает функциональность, которая часто отсутствуют в коммерческих продуктах. Она также является (по словам одного влиятельного рейтингового сайта) наиболее популярной в мире широко используемой независимой СУБД с открытым кодом, и ее влияние продолжает расти: в 2017 и 2018 годах она была базой данных с самой быстро растущей популярностью в мире [DE19c]. PostgreSQL используется в самых разных отраслях промышленности и задачах, что неудивительно, учитывая ее нацеленность на широкие возможности.
По данным DB-Engines, PostgreSQL сегодня является четвертой по популярности СУБД в мире, после Oracle, MySQL и MS SQL Server, причем все три предлагаются конкретными компаниями (MySQL был приобретен Oracle много лет назад) [DE19a]. Правила ранжирования обсуждаются в описании методологии ранжирования DB-Engines [DE19b].
Heroku — облачный провайдер SaaS, который теперь является частью Salesforce. Postgres был внедрен в Heroku в 2010 году в качестве базы данных по умолчанию для своей платформы. Heroku выбрал Postgres за надежность в работе. С поддержкой со стороны Heroku более крупные платформы разработки приложений, такие как Ruby on Rails и Python for Django, стали рекомендовать Postgres в качестве базы данных по умолчанию.
Сегодня PostgreSQL поддерживает инфраструктуру расширений, которая позволяет легко добавлять дополнительные возможности в систему через пользовательские функции и связанные с ним модификации. Теперь есть экосистема расширений PostgreSQL, сродни концепции llustra пакетов расширений DataBlade, но с открытым исходным кодом. Наиболее интересные расширения включают, например, библиотеку Apache MADlib для машинного обучения в интерфейсе SQL и библиотеку Citus для параллельного выполнения запросов.
Одним из наиболее интересных приложений с открытым исходным кодом, построенных над Postgres, является географическая информационная система PostGIS, использующая многие возможности Postgres, которые первоначально вдохновили Стоунбрейкера начать проект.
PostgreSQL уже давно является привлекательной отправной точкой для создания коммерческих систем баз данных, учитывая его использование по «всепозволяющей» лицензии на программное обеспечение с открытым исходным кодом, надежный код, гибкость и широкую функциональности. Суммируя стоимости приобретения, перечисленные ниже, видим, что от Postgres получилось более 2,6 млрд. долларов стоимости приобретения.
Обратите внимание, что это мера в долларах реальных финансовых операций и гораздо более существенная, чем значения, которые часто используются в сфере высоких технологий. Цифры в миллиардах часто используются для описания оценочной стоимости пакетов акций, но часто завышаются в 10 раз или более по сравнению с нынешней стоимостью в надежде на ее будущее значение. Доллары сделки приобретения компании измеряют ее фактическую рыночную стоимость на момент приобретения. Будет справедливым сказать, что Postgres создала более 2,6 миллиардов долларов реальной коммерческой стоимости.
Многие коммерческие усилия, связанные с PostgreSQL, были направлены на то, что, вероятно, является ее основным ограничением: возможность масштабирования до параллельной архитектуры без разделения ресурсов.
Распараллеливание PostgreSQL требует изрядной работы, но в высшей степени выполнимо небольшой опытной командой. Сегодня, отраслевые ветки открытого исходного кода PostgreSQL, такие как Greenplum и CitusDB, предоставляют такую возможность. Жаль, что PostgreSQL не был правильно распараллелен в открытом исходном коде намного раньше. Если бы в начале 2000-х годов PostgreSQL был расширен в открытом исходном коде поддержкой архитектуры без разделения ресурсов, вполне возможно, что направление больших данных с открытым исходным кодом развивалось бы совсем по-другому и более эффективно.
Вы можете извлечь множество уроков из успеха Postgres, некоторые из которых бросают вызов общепринятому мнению.
Урок высшего порядка, который я извлекаю, состоит в том, что Postgres бросил вызов «синдрому второй системы» (Second System Effect) по Фреду Бруксу (Fred Brooks) [Bro75]. Брукс утверждал, что дизайнеры вслед за успешной первой системой часто создают вторую, которая терпит неудачу из-за перегрузки возможностями и идеями. Postgres был второй системой Стоунбрейкера, и она, безусловно, была полна возможностей и идей. Система также успешно прототипировала многие идеи, при этом поставляя программную инфраструктуру, которая довела многие идеи до успешного завершения. Это не было случайностью — в своей основе Postgres был разработан с возможностью расширяемости, и этот дизайн был хорошо продуманным. С расширяемостью в качестве стержня архитектуры появилась возможность быть творческими и меньше беспокоиться о рамках: вы можете пробовать разные расширения, и пусть победит сильнейший. Сделанная хорошо, «вторая система» не обречена. Она выигрывает от доверия, любимых проектов и устремлений, сложившихся во время пользования первой системой. Это ранний архитектурный урок от более «серверно-ориентированной» школы разработки баз данных, которая бросает вызов устоявшемуся представлению «компонентно-ориентированной» школы разработки операционных систем.
Другой урок заключается в том, что акцент на универсальности, «один размер подходит всем», может быть выигрышным подходом как для исследований, так и для практики. Однако Стоунбрейкер времен МТИ (В 2001 году Стоунбрейкер занял должность профессора информатики в Массачусетском технологическом институте (МТИ). — Прим. пер.) наделал много шума в мире баз данных в начале 2000-х годов тезисом «один размер не всем подходит». Под этим знаменем он запустил флотилию важных проектов и стартапов, но ни один не мог тягаться размахом с Postgres. Кажется, что Стоунбрейкер времен Беркли бросает вызов более позднему опыту Стоунбрейкера времен МТИ, и я в этом не вижу проблем.
Как сказал Эмерсон (Ralph Waldo Emerson), «глупая последовательность — пугало мелких умишек».
Конечно, есть мудрость в девизе «один размер не всем подходит» (всегда можно найти скромные рынки для нестандартных решений), но успех системы, являющейся визитной карточкой Стоунбрейкера времен Беркли, далеко за пределами ее первоначальных целей, показывает, что подавляющее большинство проблем с базами данных вполне решаемы с помощью хорошей архитектуры общего назначения. Кроме того, проектирование этой архитектуры само по себе является технологической задачей и достижением. В конце концов, как и в большинстве научных и технических дебатов, есть не только один хороший способ что-то сделать. У обоих Стоунбрейкеров есть, чему научить нас. Но по натуре я все же поклонник более широкой программы, которую принял Стоунбрейкер времен Беркли.
Последний урок, который я извлекаю из Postgres, — это непредсказуемый потенциал, который может быть заложен в исследуемом вами открытом исходном коде. В своей Тьюринговской лекции Стоунбрейкер говорит об «интуитивной прозорливости» системы PostgreSQL, которая успешно развивается в открытом исходном коде, в основном благодаря людям не из окружения Стоунбрейкера. Вот цитата, которая звучит удивительно скромно:
Я благодарен моим старым приятелям по Postgres Вэю Хонгу, Джеффу Мередиту и Майку Олсону за их воспоминания и информацию, а также Крейгу Керстиенсу (Craig Kerstiens) за его вклад в современный PostgreSQL.
Перевод выполнен Еленой Индрупской. От себя добавлю, что «программист, который отчаянно хотел построить систему с многоверсионностью» — судя по всему, Вадим Михеев, ну а «добровольцев из России», переписавших GiST, мы все хорошо знаем.
Аннотация
Это воспоминание о проекте Postgres, выполняемом в Калифорнийском университете в Беркли и возглавляемом Майком Стоунбрейкером (Mike Stonebraker) с середины 1980-х до середины 1990-х годов. В качестве одного из многих личных и исторических воспоминаний, эта статья была запрошена для книги [Bro19], посвященной награждению Стоунбрейкера премией Тьюринга. Поэтому в центре внимания статьи — руководящая роль Стоунбрейкера и его мысли о дизайне. Но Стоунбрейкер никогда не был программистом и не мешал своей команде разработчиков. Кодовая база Postgres была работой команды блестящих студентов и эпизодически—штатных университетских программистов, которые имели немного больше опыта (и только немного большую зарплату), чем студенты. Мне посчастливилось присоединиться к этой команде в качестве студента в последние годы проекта. Я получил полезный материал для этой статьи от некоторых более старших студентов, занятых в проекте, но любые ошибки или упущения являются моими. Если вы заметили какие-либо из них, пожалуйста, свяжитесь со мной, и я постараюсь их исправить.
1. Введение
Postgres был самым амбициозным проектом Майкла Стоунбрейкера — его серьезной попыткой создать универсальную систему баз данных. Продолжаясь десятилетие, проект породил больше статей, кандидатов наук, профессоров и компаний, чем какая-либо еще деятельность Стоунбрейкера. Проект также охватывал больше технической области, чем любая другая система, которую он построил. Несмотря на риск, присущий такому масштабу, Postgres также стал самым успешным программным артефактом, который вышел из исследовательских групп Стоунбрейкера, и его основным вкладом в открытый исходный код. Это пример «второй системы» [Bro75], которая имела успех. На момент написания статьи, т. е. более тридцати лет с начала проекта, система PostgreSQL с открытым исходным кодом является в мире самой популярной независимой системой баз данных с открытым исходным кодом и четвертой по популярности системой баз данных. Между тем компании, созданные из Postgres, произвели в общей сложности более 2,6 млрд. долл. США (в стоимости приобретения). По любым меркам видение Postgres Стоунбрейкера имело огромный продолжительный резонанс.
1.1. Предыстория
Стоунбрейкер имел огромный успех в начале карьеры с исследовательским проектом Ingres в Беркли [SHWK76] и последующим стартапом, который он основал вместе с Ларри Роу (Larry Rowe) и Юджином Вонгом (Eugene Wong): Relational Technology, Inc. (RTI).
По мере развития RTI в начале 1980-х годов Стоунбрейкер начал работать над поддержкой в СУБД типов данных, выходящих за рамки традиционных строк и столбцов исходной реляционной модели Кодда (Edgar Frank Codd). Мотивирующим примером в то время была потребность поддержки базами данных инструментов автоматизированного проектирования (САПР) для микроэлектронной промышленности. В статье 1983 г. Стоунбрейкер и студенты Брэд Рубенштейн (Brad Rubenstein) и Антонин Гуттман (Antonin Guttman) объяснили, насколько эта отрасль нуждается в поддержке «новых типов данных, таких как многоугольники, прямоугольники, текстовые строки и т. д.», «эффективного пространственного поиска», «сложных ограничений целостности», а также «проектных иерархий и множественных представлений» в одних и тех же физических конструкциях [SRG83]. Имея такую мотивацию, группа начала работу над индексированием (в том числе с помощью R-деревьев Гуттмана для пространственного индексирования [Gut84]) и над добавлением абстрактных типов данных (АТД) в систему реляционных баз данных. В то время АТД были популярной новой конструкцией языков программирования, которая была впервые введена Барбарой Лисков (Barbara Liskov), впоследствии лауреатом премии Тьюринга, и исследована в прикладном программировании баз данных новым сотрудником Стоунбрейкера — Ларри Роу. В статье в SIGMOD Record в 1983 г. [OFS83] Стоунбрейкер и студенты Джеймс Онг (James Ong) и Деннис Фогг (Dennis Fogg) описывают исследование этого понятия в расширении Ingres, названном ADT-Ingres, в которое были включены многие концепции представления, изученные более глубоко и с лучшей системной поддержкой в Postgres.
2. Postgres: общие сведения
Как следует из названия, Postgres это «Post-Ingres»: система, предназначенная для того, чтобы взять то, что могла делать Ingres, и выйти за ее рамки. Отличительным признаком Postgres было введение того, что он в конечном итоге назвал объектно-реляционными свойствами базы данных: поддержка концепции объектно-ориентированного программирования в модели данных и декларативного языка запросов системы баз данных. Но Стоунбрейкер также задумал решить в Postgres ряд других независимых от объектно-ориентированной поддержки технологических проблем, таких как правила активной базы данных, версионные данные, третичное хранилище и параллелизм.
Две статьи были написаны по дизайну Postgres: описание раннего дизайна в SIGMOD 1986 г. [SR86] и промежуточное описание в CACM 1991 г. [SK91]. Исследовательский проект Postgres постепенно «сошел на нет» в 1992 году с основанием Стоунбрейкером стартапа Illustra, в котором участвовали Стоунбрейкер, ведущий аспирант Вэй Хонг и позже ставший главным программистом Джефф Мередит (Jeff Meredith). В списке, приведенном ниже, возможности, упомянутые в статье 1986 года, отмечены звездочкой*, а возможности из статьи 1991 года, которых не было в статье 1986 года, — крестиком†. За другие задачи, перечисленные ниже, брались в системе и исследовательской литературе, но их нет ни в одной спецификации дизайна. Многие из этих тем рассматривались в Postgres задолго до того, как они были изучены или заново изобретены другими. Во многих случаях Postgres слишком опередил свое время, и интерес к темам вспыхнул позже, уже под современным углом зрения.
- Поддержка АТД в системе баз данных
- Сложные объекты (т. е. вложенные данные или данные не первой нормальной формы (non-first-normal form — NF2))*
- Пользовательские абстрактные типы данных и функции*
- Расширяемые методы доступа для новых типов данных*
- Оптимизированная обработка запросов с дорогостоящими пользовательскими функциями
- Активные базы данных и системы правил (триггеры, предупреждения)*
- Правила, реализованные в виде перезаписи запроса†
- Правила, реализованные как триггеры уровня записи†
- Хранение и восстановление на основе журнала
- Код восстановления с уменьшенной сложностью, рассматривающий журнал как данные*, использование энергонезависимой памяти для состояния фиксации†
- Хранилище без перезаписи и темпоральные запросы†
- Поддержка новых технологий глубокого хранения данных, в особенности оптических дисков*
- Поддержка мультипроцессоров и специализированных процессоров*
- Поддержка различных языковых моделей
- Минимальные изменения реляционной модели и поддержка декларативных запросов*
- Доступ к «быстрому пути» из внутренних API в обход языка запросов†
- Многоязычность†
Мы кратко обсудим вклад Postgres по каждой из этих позиций в его связи с последующими работами в области вычислений.
2.1. Поддержка АТД в системе баз данных
Четко сформулированной целью Postgres была поддержка новых объектно-реляционных свойств: расширение технологии баз данных, чтобы обеспечить преимущества как реляционной обработки запросов, так и объектно-ориентированного программирования. Со временем объектно-реляционная концепция, впервые появившиеся в Postgres, стала стандартной функциональностью в большинстве современных систем баз данных.
2.1.1. Сложные объекты
Довольно часто данные представляются в виде вложенных сущностей или «объектов». Классическим примером является заказ на покупку, который имеет вложенный набор продуктов, их количеств и цен. Религия реляционного моделирования диктовала, что такие данные должны быть реструктурированы и сохранены в формате без вложенности, используя несколько плоских таблиц объектов (заказы, продукты) с соединяющими их плоскими таблицами отношений (продукт_в_заказе). Типичная причина такого уплощения заключается в том, что оно уменьшает дублирование данных (т. к. продукт избыточно описывается во многих заказах на покупку), что, в свою очередь, позволяет избежать сложности или ошибок при обновлении всех избыточных копий. Но в некоторых случаях вы хотите сохранить вложенное представление, потому что это естественно для приложения (например, механизм компоновки схемы в САПР), а обновления редки. Этот спор о моделировании данных по крайней мере так же стар, как и реляционная модель.
Ключевым подходом Postgres было «усидеть на двух стульях» с точки зрения моделирования данных: Postgres сохранил таблицы как «самый внешний» тип данных, но позволил столбцам иметь «сложные» типы, включая вложенные кортежи или таблицы. Одна из его малораспространенных реализаций, впервые исследованная в прототипе ADT-Ingres, заключалась в том, чтобы разрешить задавать столбец табличного типа декларативно, как определение запроса: «Quel как тип данных» [SAHR84] (Quel — язык запросов Ingres. — Прим. пер.).
«Постреляционная» тема поддержки как декларативных запросов, так и вложенных данных вновь возникала на протяжении многих лет, часто порождаемая спорами о том, что лучше. Во времена Postgres в 1980-х и 1990-х годах некоторые группы, занимающиеся объектно-ориентированными базами данных, подхватили эту идею и развили ее в стандартный язык OQL, который затем перестал использоваться.
На рубеже тысячелетий декларативные запросы к вложенным объектам стали навязчивой идеей исследований для сегмента сообщества разработчиков баз данных в виде баз данных XML. Получившийся в результате язык XQuery (во главе с Доном Чемберлином (Don Chamberlin) — персоной SQL) обязан поддержке сложных объектов языку Postquel из Postgres. XQuery получил широкое распространение и использование в промышленности, но никогда не был популярен у пользователей. Сегодня эти концепции вновь рассматриваются в проектах языков запросов для модели данных JSON, популярной в браузерных приложениях. Как и OQL, в группах, которые первоначально отвергали декларативные запросы в пользу программирования, ориентированного на разработчиков (движение «NoSQL»), эти языки часто возникают как запоздалое дополнение исключительно из желания добавить запросы обратно в системы. В то же время по мере роста Postgres с годами (и перехода от языка запросов Postquel к версиям SQL, которые отвечают многим из рассматриваемых целей), он включил поддержку вложенных данных, таких как XML и JSON, в СУБД общего назначения, не требуя какого-либо значительного перепроектирования. Споры протекают с переменным успехом, а подход Postgres к расширению реляционной структуры с помощью расширений для вложенных данных не раз показал себя естественным конечным состоянием для всех сторон после того, как аргументы утихают.
2.1.2. Пользовательские абстрактные типы данных и функции
В дополнение к предложению вложенных типов Postgres выдвинул идею ввести непрозрачные, расширяемые АТД, которые хранятся в базе данных, но не интерпретируются ядром. В принципе, это всегда было частью реляционной модели Кодда: целые числа и строки были традиционными, но на самом деле реляционная модель охватывает любые атомарные типы данных с предикатами. Задача состояла в том, чтобы обеспечить такую математическую гибкость и в программном обеспечении. Чтобы использовать запросы, которые интерпретируют эти объекты и манипулируют ими, прикладной программист должен иметь возможность регистрировать в системе определяемые пользователем функции (user-defined functions — UDF) для этих типов и вызывать эти функции в запросах. Также желательно, чтобы определяемые пользователем агрегатные (user-defined aggregate — UDA) функции суммировали коллекции этих объектов в запросах. Система баз данных Postgres была новаторской, всесторонне поддерживая эти возможности.
Зачем помещать такую функциональность в СУБД, а не в высокоуровневые приложения? Типичным ответом на этот вопрос было значительное преимущество в производительности кода, помещенного к данным, перед «вытягиванием» данных к коду. Postgres показал, что это вполне естественно в рамках реляционной среды: потребовались лишь небольшие изменения в каталоге реляционных метаданных и были созданы механизмы вызова стороннего кода, но синтаксис запросов, семантика и системная архитектура работали просто и элегантно.
Postgres немного опередил свое время в исследовании этой функциональности. В частности, в то время сообщество исследователей баз данных не особенно беспокоилось о последствиях для безопасности при загрузке небезопасного кода на сервер. Это стало восприниматься как проблема, когда технологию заметили в индустрии. Стоунбрейкер вывел на рынок Postgres в своем стартапе Illustra, который был приобретен Informix в значительной степени за его способность поддерживать пакеты расширений DataBlade, в том числе UDF. Informix с технологией, основанной на Postgres, и сильным предложением параллельных баз данных стала значительной угрозой Oracle. Oracle инвестировала значительные средства в негативный маркетинг рисков, связанных со способностью Informix запускать «незащищенный» пользовательский C-код. Некоторые относят гибель Informix к этой кампании, хотя финансовые махинации Informix (и последующее федеральное обвинение его тогдашнего генерального директора), безусловно, представляли собой более серьезные проблемы. Теперь, десятилетия спустя, все основные поставщики баз данных поддерживают выполнение пользовательских функций на одном или более языках, используя новые технологии защиты от сбоев сервера или повреждения данных.
Между тем, технологические стеки больших данных 2000-х годов, включая феномен MapReduce, который «много крови попортил» Стоунбрейкеру и ДеВитту (David DeWitt) [DS08], являются повторной реализацией идеи Postgres — пользовательского кода, размещенного в рамках запроса. Представляется, что MapReduce во многом сочетает идеи разработки программного обеспечения от Postgres с идеями параллелизма от таких систем, как Gamma и Teradata, с некоторыми незначительными инновациями вокруг перезапуска в процессе выполнения запроса для рабочих нагрузок с экстремальной масштабируемостью. Стартапы на базе Postgres, Greenplum и Aster, примерно в 2007 году показали, что распараллеливание Postgres может привести к чему-то гораздо более функциональному и практичному, чем MapReduce, для большинства клиентов, но в 2008 году рынок все еще не был готов к этой технологии. К настоящему времени, в 2018 году, почти каждый стек больших данных в основном обслуживает рабочую нагрузку параллельного SQL с UDF, что очень похоже на дизайн, который Стоунбрейкер с командой впервые использовали в Postgres.
2.1.3. Расширяемые методы доступа для новых типов данных
Реляционные базы данных развивались примерно в то же время, что и B-деревья, в начале 1970-х годов, и B-деревья помогли дать импульс мечте Кодда о «независимости от физического хранения данных»: индексирование B-деревьями обеспечивает уровень косвенности, который адаптивно реорганизует физическое хранилище, не требуя изменения приложений. Основным ограничением B-деревьев и связанных с ними структур было то, что они поддерживают только поиск по равенству и запросы одномерного диапазона. А что делать, если у вас есть запросы 2-мерного диапазона, типичные для картографии и приложений САПР? Эта проблема была известна во время Postgres, и R-дерево [Gut84], разработанное Антонином Гуттманом в группе Стоунбрейкера, было одним из самых успешных новых индексов, разработанных для решения этой проблемы на практике. Тем не менее, изобретение индексной структуры не решает для комплексных систем задачу поддержки в СУБД многомерных диапазонов. Возникает много вопросов. Можете ли вы легко добавить метод доступа, такой как R-деревья, в свою СУБД? Можете ли вы научить оптимизатор понимать, что указанный метод доступа будет полезен для определенных запросов? Вы можете добиться корректности восстановления и одновременного доступа? Это был очень смелый пункт программы действий Postgres: проблема архитектуры программного обеспечения, затрагивающая большую часть ядра базы данных, от оптимизатора до уровня хранения, а также системы журналирования и восстановления. R-деревья в Postgres стали мощной движущей силой и основным примером элегантной расширяемости уровня метода доступа и его интеграции в оптимизатор запросов. Postgres показал, способом непрозрачных АТД, как зарегистрировать абстрактно описанный метод доступа (в данном случае R-дерево), и как оптимизатор запросов может распознать абстрактный предикат выборки (в данном случае выбор диапазона) и сопоставить его с этим абстрактно описанным методом доступа. Вопросам управления одновременным доступом было уделено меньше внимания в первоначальной работе: отсутствие одномерного упорядочения ключей сделало в данном случае блокировку, применяемую в B-деревьях, неприменимой.
Многообещающие возможности расширяемых методов доступа Postgres вдохновили один из моих первых исследовательских проектов в конце аспирантуры: обобщенные деревья поиска (Generalized Search Trees—GiST) [HNP95] и последующую концепцию теории индексируемости [HKM+02]. Я реализовал GiST в Postgres в течение семестра после получения докторской степени, что сделало добавление новой логики индексирования в Postgres еще проще. В диссертации Марселя Корнакера из Беркли (Marcel Kornacker) решены сложные задачи восстановления и одновременного доступа, поставленные расширяемым «шаблонным» типом индекса GiST [KMH97].
Сегодня PostgreSQL выгодно сочетает оригинальную программную архитектуру расширяемых методов доступа (она имеет индексы B-tree, GiST, SP-GiST и Gin) с расширяемостью и интенсивным конкурентным доступом интерфейса обобщенного дерева поиска (GiST). Индексы GiST поддерживают популярную гео-информационную систему PostGIS на базе PostgreSQL. Индексы Gin обеспечивают внутреннюю поддержку индексирования текста в PostgreSQL.
2.1.4. Оптимизатор обработки запросов с дорогостоящими UDF
В традиционной оптимизации запросов задача состояла в том, чтобы свести к минимуму объем потока кортежей (и, следовательно, операций ввода-вывода), создаваемых при обработке запроса. Это означало, что операторы, которые фильтруют кортежи (выборка), хороши в начале плана запроса, в то время как операторы, которые могут генерировать новые кортежи (соединение), должны быть выполнены позже. В результате оптимизаторы запросов будут «выталкивать» операторы выборки ниже соединений и упорядочивать их произвольно, сосредотачиваясь вместо этого на умной оптимизации соединений и обращений к диску. UDF изменили подход: если у вас в операторах выборки дорогостоящие UDF, порядок выполнения UDF может иметь решающее значение для оптимизации производительности. Более того, если UDF в операторе выборки действительно занимает много времени, возможно, выборку следует выполнять после соединений (т. е. выполнить «подтягивание» выборки вверх — selection «pullup»). Учет этих факторов усложнил пространство поиска для оптимизатора. Я взял эту проблему как первую сложную задачу в аспирантуре, и кончилось тем, что она стала предметом моей магистерской работы со Стоунбрейкером в Беркли и моей кандидатской в Висконсине под руководством Джеффа Нотона (Jeff Naughton), но при постоянной помощи советами от Стоунбрейкера. СУБД Postgres была первой, которая сохраняла стоимость и избирательность пользовательских функций в каталоге базы данных. Мы подошли к задаче оптимизации, придумав оптимальный порядок операций выборки, а затем оптимальное чередование операций выборки вдоль ветвей каждого дерева соединений, рассматриваемого при поиске плана. Это позволило оптимизатору поддерживать архитектуру классического динамического программирования System R с небольшой дополнительной стоимостью сортировки для правильного упорядочения дорогостоящих операторов выборки.
Когда я поступил в аспирантуру, это была одна из трех тем, которые Стоунбрейкер написал на доске в своем кабинете как варианты для выбора темы моей диссертации. Кажется, второй темой было индексирование функций, а третьей я не помню.
Оптимизация дорогостоящих функций была отключена в деревьях исходного кода PostgreSQL на ранней стадии в значительной степени потому, что в то время не было убедительных вариантов использования дорогостоящих пользовательских функций. Примеры, которые мы использовали, вращались вокруг обработки изображений и, наконец, в 2018 году они становятся востребованными задачами обработки данных. Конечно, сегодня, в эпоху больших данных и рабочих нагрузок машинного обучения, дорогостоящие функции стали довольно распространенным явлением, и я ожидаю, что эта проблема вернется на передний план. В очередной раз отметим, что Postgres сильно опередил свое время.
По иронии судьбы, код, написанный мною в аспирантуре, был полностью удален из дерева исходных текстов PostgreSQL молодым программистом по имени Нил Конвей (Neil Conway), который несколько лет спустя начал делать кандидатскую диссертацию под моим руководством в Калифорнийском университете в Беркли и теперь является одним из «кандидатских внуков» Стоунбрейкера.
2.2. Активные базы данных и системы правил
Проект Postgres начался на исходе интереса сообщества искусственного интеллекта к программированию на основе правил как способу представления знаний в экспертных системах. Такой ход мысли не привел к успеху: многие считают, что это вызвало широко обсуждаемую «зиму искусственного интеллекта», которая продолжалась на протяжении 1990-х годов.
Однако программирование на основе правил сохранялось в сообществе разработчиков баз данных в двух формах. Первая — теоретическая работа вокруг декларативного логического программирования с использованием Datalog. Она была «костью в горле» для Стоунбрейкера: он, казалось, действительно ненавидел эту тему и хлестко критиковал ее в нескольких докладах сообщества на протяжении многих лет.
Datalog выжил как математическая основа для декларативных языков и со временем нашел применение в различных областях информатики, включающих программно-конфигурируемые сети и компиляторы. Datalog — это декларативное построение запросов «на стероидах» как вполне выразительная модель программирования. В конце концов я был вовлечен в это, как в естественный вариант дизайна, и следовал этому в различных прикладных настройках за пределами традиционных систем баз данных.
Второй круг вопросов, связанных с правилами баз данных, был практической работой над тем, что в конечном итоге было названо активными базами данных и триггерами баз данных, которые развились в стандартную функциональность реляционных СУБД. Стоунбрейкер в свойственной ему манере проголосовал ногами за работу над более практическим вариантом.
Работа Стоунбрейкера над правилами баз данных началась с кандидатской работы Эрика Хэнсона (Eric Hanson), которая первоначально делалась для Ingres, но быстро переместилась в новый проект Postgres. Она была расширена в кандидатской работе Спироса Потамианоса (Spyros Potamianos) над PRS2: Postgres Rules System 2. Темой в обеих реализациях была возможность реализовать правила двумя различными способами. Один из них — трактовать правила как перезапись запросов. Это напоминает работу над перезаписью представлений, что впервые сделал Стоунбрейкер в Ingres. В этом сценарии логика правила «при условии выполнить действие» преобразуется в «при запросе перезаписать его и выполнить вместо исходного». Например, запрос типа «добавить новую строку к списку наград Майка» может быть переписан как «повысить зарплату Майка на 10%». Другой способ состоял в том, чтобы реализовать более естественное «при условии выполнить действие», проверяя условия на уровне строк с помощью блокировок внутри базы данных. При обнаружении таких блокировок результатом было не ожидание (как в традиционном управлении одновременным доступом), а выполнение соответствующего действия.
Код для правил уровня строк в PRS2 был, как печально известно, сложным. Небольшим поиском в архивах Postgres в Беркли был обнаружен следующий комментарий (вероятно, Спироса Потамианоса) к исходному коду Postgres версии 3.1 примерно 1991 года (дается в переводе):
* О П И С А Н И Е: * Сделай глубоооокий вдох и прочти. Если ты не можешь не влезать в нижеследующий * код (т. е. если босс не вынудил тебя добровольно делать это * "грязное" дело) избегай этого любой ценой. Попробуй делать что-то менее опасное * для твоего (психического) здоровья. Иди домой и посмотри фильмы ужасов по телевизору. * Почитай немного Лавкрафта. Пойди служить в армию. Иди и проведи несколько ночей * в народном парке. Соверши самоубийство... * Что, продолжаешь читать, неужели? Хорошо, тогда ты заслуживаешь того, что получил. * Добро пожаловать в мрачный лабиринт системы правил уровня кортежей, мой * бедный коллега...
В итоге для реализации правил в Postgres ни метод перезаписи запросов, ни метод блокировки на уровне строк не были объявлены «победителями» — оба были сохранены в выпущенной системе. В конце концов код всех правил был забракован и переписан в PostgreSQL, но текущий исходный код по-прежнему сохраняет оба понятия триггеров на уровне операторов и на уровне строк.
Системы правил Postgres в свое время имели очень большое влияние и шли «ноздря в ноздрю» с исследованиями по проектам IBM Starburst и MCC HiPAC. Сегодня триггеры являются частью стандарта SQL и реализованы в движках многих основных баз данных. Однако они используются с некоторой осторожностью. Одна из проблем заключается в том, что наработки, о которых говорилось, так и не преодолели негативных моментов, которые привели к «зиме искусственного интеллекта»: взаимодействия в нагромождении правил могут стать неприемлемо запутанными, даже когда набор правил растет незначительно. Кроме того, на практике по-прежнему выполнение триггеров обычно занимает относительно много времени, поэтому внедряемые базы данных, которые должны работать быстро, как правило, избегают использования триггеров. Однако была некоторая кустарщина в смежных областях, таких как поддержка материализованных представлений, обработка сложных событий и потоковые запросы, каждая из которых в некотором роде является расширениями идей, исследованных в системах правил Postgres.
2.3. Xранение и восстановление на основе журнала
Стоунбрейкер описал свой дизайн системы хранения Postgres таким образом:
Обдумывая систему хранения Postgres, мы руководствовались миссионерским рвением сделать что-то необычное. Все современные коммерческие системы используют менеджер хранилища с журналом упреждающей записи (write-ahead log — WAL), и мы чувствовали, что эта технология хорошо понятна. Более того, оригинальный прототип Ingres 1970-х годов использовал аналогичный менеджер хранилища, и у нас не было желания делать другую реализацию. [SK91]Хотя это выглядит, как чистая интеллектуальная неугомонность, были и технологические основания для этой работы. На протяжении многих лет Стоунбрейкер неоднократно выражал неприязнь к сложным схемам ведения журнала упреждающей записи, впервые разработанным в IBM и Tandem для восстановления баз данных. Одно из его основных возражений основано на интуиции разработчика программного обеспечения: никто не должен полагаться на что-то столь сложное, особенно для функциональности, которая будет использоваться только в редких, критических сценариях после сбоя.
Xранилище Postgres объединило понятия основного хранилища и журналирования исторической информации в единое простое дисковое представление. В своей основе идея заключалась в том, чтобы хранить каждую запись в базе данных в связанном списке версий, помеченных идентификаторами транзакций, — в некотором смысле это «журнал как данные» или «данные как журнал» в зависимости от вашей точки зрения. Единственные дополнительные метаданные, которые необходимы, — это список идентификаторов завершенных транзакций и времени их фиксации. Этот подход значительно упрощает восстановление, так как нет «перевода» из журнального представления обратно в основное представление. Он также делает возможными темпоральные запросы: вы можете выполнять запросы по состоянию на некоторый момент времени и получать доступ к версиям данных, которые были зафиксированы в это время. Первоначальный дизайн системы хранения Postgres, который выглядит так, как будто Стоунбрейкер описал его в одном творческом сеансе мозгового штурма, рассматривал ряд проблем эффективности и оптимизации базовой схемы наряду с грубым анализом того, как может повести себя производительность [Sto87]. Итоговая реализация в Postgres была несколько проще.
Мнение Стоунбрейкера о «радикальной простоте» транзакционного хранилища было глубоко противоположно принятым в сообществе в то время, когда поставщики баз данных выделяли себя, инвестируя значительные средства в алгоритмы высокопроизводительной обработки транзакций. В то время победители сравнительных тестов достигали высокой производительности и возможности восстановления благодаря хорошо оптимизированным системам ведения журнала упреждающей записи. После того, как они получили хорошо работающие журналы упреждающей записи, поставщики также начали нововведения следующего этапа, такие как транзакционная репликация на основе доставки журнала, что было трудно осуществить в Postgres. В итоге система хранения Postgres так и не отличилась в производительности. Версионность и темпоральные запросы были позже удалены из PostgreSQL и заменены использованием журнала упреждающей записи.
К сожалению, PostgreSQL все еще не особенно быстро обрабатывает транзакции: использование в нем журнала упреждающей записи несколько половинчато. Как ни странно, команда PostgreSQL сохранила много служебной информации, хранимой вместе с кортежами в Postgres, для обеспечения многоверсионности, что никогда не было целью проекта Postgres в Беркли. Результатом является система хранения, которая может эмулировать изоляцию снимков (snapshot isolation) Oracle с изрядным объемом дополнительных накладных расходов ввода-вывода, но которая не следует первоначальной мысли Стоунбрейкера о темпоральных запросах или простом восстановлении.
Майк Олсон (Mike Olson) отмечает, что его первоначальное намерение состояло в том, чтобы заменить реализацию B-дерева Postgres своей собственной реализацией B-дерева из проекта Berkeley DB, который разрабатывался в Беркли в эпоху Postgres. Но Олсон так и не нашел на это времени. Когда годы спустя Berkeley DB получила поддержку транзакций в Sleepycat Corp., Олсон попытался убедить (тогдашнее) сообщество PostgreSQL использовать его для восстановления вместо хранилища «без перезаписи». Они отказались: в проекте был программист, который отчаянно хотел построить систему с многоверсионностью (MVCC), и поскольку он был готов выполнить работу, он выиграл спор.
Медленно работающее хранилище PostgreSQL не является внутренне присущим системе. В Greenplum ветка PostgreSQL в качестве интересной альтернативы интегрировала высокопроизводительное сжатое хранилище. Оно было разработано Мэттом МакКлином (Matt McCline)—ветераном команды Джима Грея (Jim Gray) в компании Tandem. Оно также не поддерживало темпоральных запросов.
Но возможность темпоральных запросов была интересной и оставалась уникальной. Более того, кредо Стоунбрейкера в отношении разработки простого программного обеспечения для восстановления данных сегодня имеет отголоски как в контексте систем NoSQL (которые выбирают репликацию, а не WAL), так и в базах данных основной памяти (MMDB — main memory databases, которые часто используют многоверсионность и сжатые журналы фиксации). Идея версионных реляционных баз данных и темпоральных запросов сегодня все еще отнесена к эзотерике, появляясь в случайных исследовательских прототипах и небольших проектах с открытым исходным кодом. Это идея, которая созрела для возвращения в нашу эпоху дешевого хранения и непрерывных потоков данных.
2.4. Запросы к данным на носителях с новыми технологиями глубокого хранения
В середине проекта Postgres Стоунбрейкер подписался в качестве одного из руководителей на большой грант по научному направлению «цифровая земля» под названием Project Sequoia. Часть грантового предложения заключалась в обработке беспрецедентных объемов цифровых спутниковых изображений, требующих до 100 терабайт памяти, т. е. намного большего объема данных, чем в то время было бы разумно хранить на магнитных дисках. В основе предлагаемого решения было исследовать идею создания СУБД (а именно Postgres), облегчающей доступ к полуавтономному «третичному» хранилищу, предоставляемому роботизированными накопителями с автоматической сменой дисков для управления библиотеками оптических дисков или лент.
Из этого вытекало несколько разных исследований. Одним из них была файловая система Inversion — попытка предоставить абстракцию файловой системы UNIX над реляционной СУБД. В обзорной статье для Sequoia Стоунбрейкер описал это в своем обычном стиле свысока как «простое упражнение» [Sto95]. На самом деле Майк Олсон, студент Стоунбрейкера (и последующий основатель компании Cloudera), был занят этим в течение нескольких лет, да и конечный результат не был вполне однозначным [Ols93] и не выжил на практике.
На несколько лет позже Inversion Билл Гейтс «бился с теми же ветряными мельницами» в WinFS — попытке воссоздать наиболее широко используемую в мире файловую систему над серверной частью реляционной базы данных. WinFS поставлялась в разработческих версиях Windows, но так и не вышла на рынок. Гейтс позже назвал это своим самым большим в Microsoft разочарованием.
Другим основным направлением исследований на этом фронте было включение третичного хранилища в стек более типичных реляционных баз данных, что было предметом кандидатской диссертации Суниты Сараваги (Sunita Sarawagi). Основной темой было изменение масштаба, в котором вы мыслите управление пространством (т. е. данными в хранилище и иерархии памяти) и временем (координация планирования запросов и кеша для минимизации нежелательных операций ввода-вывода). Одной из ключевых проблем в этой работе было хранение больших многомерных массивов в третичном хранилище и извлечение их, что перекликается с работами в области многомерного индексирования. Основные идеи включали разбиение массива на порции и хранение вместе порций, которые выбираются вместе, а также репликацию порций, чтобы указанная порция данных могла иметь нескольких физических «соседей». Вторая проблема — подумать о том, как диск становится кешем для третичного хранилища. Наконец, оптимизация запросов и планирование должны были учитывать длительное время загрузки данных из третичного хранилища и важность попаданий (hits) кеша диска. Это влияет как на план, выбираемый оптимизатором запросов, так и на время, на которое этот план намечен к выполнению.
Роботы на лентах и оптических дисках в настоящее время широко не используются. Но проблемы третичного хранилища очень распространены в облаке, которое в 2018 году имеет глубокую иерархию хранения: от присоединенных твердотельных дисков к услугам надежного дископодобного хранилища (например, AWS EBS), к архивному хранилищу (например, в AWS S3), к глубокому хранилищу (например, AWS Glacier). Сегодня эти уровни хранения по-прежнему относительно обособлены, и рассуждения о сквозном хранилище, охватывающем эти уровни, практически не поддерживаются базой данных. Я не удивлюсь, если вопросы, исследованные на этом фронте в Postgres, будут пересмотрены в ближайшее время.
2.5. Поддержка мультипроцессоров: XPRS
Стоунбрейкер никогда не создавал большую параллельную систему баз данных, но он руководил многими стимулирующими дискуссиями в этой области. Его статья «Case for Shared Nothing» (Случай для систем без разделяемых ресурсов) [Sto86] задокументировал крупномодульные архитектурные решения в этой области. Он популяризировал терминологию, используемую в отрасли, и озадачил поддержкой архитектур без совместно используемых ресурсов, таких как Gamma и Teradata, которые были заново открыты в 2000-х годах сообществом работающих над большими данными.
По иронии судьбы, самым существенным вкладом Стоунбрейкера в область параллельных баз данных была архитектура «общей памяти» под названием XPRS, что означало «eXtended Postgres on RAID and Sprite». В начале 1990-х годов XPRS была «лигой справедливости» систем Беркли: она объединяет в сокращенном виде систему Postgres Стоунбрейкера, распределенную ОС Sprite Джона Остерхаута (John Ousterhout) и архитектуру RAID-хранилищ Дейва Паттерсона (Dave Patterson) и Рэнди Каца (Randy Katz). Как и для многих межфакультетских работ, выполнение проекта XPRS фактически определялось аспирантами, которые работали над ним. Оказалось, что основной вклад внес Вэй Хонг, который написал свою кандидатскую диссертацию по оптимизации параллельных запросов в XPRS. Таким образом, основным вкладом XPRS в литературу и индустрию была оптимизация параллельных запросов без существенного рассмотрения проблем, связанных с RAID или Sprite.
Из этих трех проектов огромное влияние на дальнейшее оказали Postgres и RAID. Sprite лучше всего помнят по кандидатской диссертации Менделя Розенблюма (Mendel Rosenblum) о файловых системах с журнальной структурой (Log Structured File Systems — LFS), которая не имела ничего примечательно общего с распределенными операционными системами. Все три проекта содержали новые идеи для дискового хранения, помимо видоизменения отдельных копий по месту. LFS и менеджер хранилища Postgres довольно похожи новым отношением к журналу как к основному хранилищу и необходимостью дорогостоящей фоновой реорганизации. Однажды я осторожно прощупывал Стоунбрейкера на предмет соперничества LFS и Postgres или академических «жареных фактов» об их взаимоотношениях, но я так и не узнал от него ничего интересного. Возможно, в то время в Беркли кто-то «мутил воду».
В принципе, параллелизм «взрывает» пространство планов оптимизатора запросов, умножая традиционные варианты выбора, сделанные во время оптимизации запросов (доступ к данным, алгоритмы соединений, порядок соединений), на все возможные способы распараллеливания каждого варианта выбора. Основная идея названного Стоунбрейкером «оптимизатора Вэя Хонга» заключалась в том, чтобы разбить проблему на две: запустить традиционный оптимизатор запросов в духе System R для одного узла, а затем «распараллелить» получившийся план, запланировав степень параллелизма и размещение каждого оператора, исходя из представления данных и конфигурации системы. Этот подход эвристичен, но в нем параллелизм наращивает стоимость традиционной оптимизации запросов аддитивно, а не мультипликативно.
Хотя оптимизатор Вэя Хонга был разработан в контексте Postgres, он стал стандартным подходом для многих оптимизаторов параллельных запросов в отрасли.
2.6. Поддержка различных языковых моделей
Среди интересов Стоунбрейкера, неоднократно возобновляющихся со времен Ingres, был интерфейс прикладного программирования (API) системы баз данных. В свои лекции из серии Database Systems (Системы баз данных) он часто включал язык GEM Карло Заниоло (Carlo Zaniolo) как тему, которую важно понять поборникам систем баз данных. Этот интерес к языку, несомненно, привел его к партнерству с Ларри Роу в Postgres, что, в свою очередь, глубоко повлияло на дизайн модели данных Postgres и ее объектно-реляционный подход. Их работа была сосредоточена в основном на приложениях для работы с большим объемом данных из коммерческой сферы, включающих как обработку деловой информации, так и новые приложения, такие как САПР/АСУП и ГИС.
Одной из проблем, которая была навязана в то время Стоунбрейкеру, была идея «спрятать» границы между конструкциями языка программирования и хранилищем базы данных. Различные конкурирующие исследовательские проекты и компании, исследующие объектно-ориентированные базы данных (Object-Oriented Databases — OODB), были нацелены на так называемую «потерю соответствия» между императивными объектно-ориентированными языками программирования, такими как Smalltalk, C++ и Java, и декларативной реляционной моделью. Идея OODB состояла в том, чтобы сделать объекты языка программирования при желании помечаемыми как «постоянные» и автоматически обрабатываемыми встроенной СУБД. Postgres поддерживал хранение вложенных объектов и абстрактных типов данных, но его интерфейс, основанный на декларативных запросах в реляционном стиле, предполагал неестественные для программиста обращения к базе данных (требовал от него использования декларативных запросов), которые к тому же были дорогостоящими (требовали синтаксического разбора и оптимизации). Чтобы конкурировать с поставщиками OODB, Postgres предоставил так называемый интерфейс «быстрого пути» (Fast Path): по сути API C/C++ к внутреннему устройству хранения базы данных. Это позволило Postgres иметь среднюю производительность по академическим тестам OODB, но так никогда и не решило задачи позволить программистам на разных языках избежать проблемы потери соответствия. Вместо этого Стоунбрейкер навесил на модель Postgres ярлык «объектно-реляционной» и просто обошел стороной применение объектно-ориентированных баз как невыгодный рынок (zero-billion dollar market). Сегодня практически все коммерческие системы реляционных баз данных являются «объектно-реляционными» системами баз данных.
Это оказалось разумным решением. Сегодня ни один из продуктов OODB не существует в своей задуманной форме, и идея «постоянных объектов» в языках программирования была большей частью отброшена. В отличие от этого, широко распространено использование слоев объектно-реляционного отображения (object-relational mapping — ORM, подпитываемое ранними работами, такими как Java Hibernate и Ruby on Rails), что позволяет относительно гладко «подгонять» декларативные базы данных почти под любой императивный объектно-ориентированный язык программирования в качестве библиотек. Этот подход на уровне приложения отличается как от OODB, так и от объектно-реляционных баз данных по Стоунбрейкеру. Кроме того, легковесные хранилища «ключ-значение» также успешно используются как в бестранзакционной, так и в транзакционной форме. Их первооткрывателем была аспирантка Стоунбрейкера Марго Зельцер (Margo Seltzer), которая работала над базой данных Berkeley DB в рамках своей кандидатской диссертации в то же время, что и группа Postgres, что предвосхитило рост таких распределенных NoSQL-хранилищ «ключ-значение», как Dynamo, MongoDB и Cassandra.
3. Влияние на программное обеспечение
3.1. Открытый исходный код
Postgres всегда был проектом с открытым исходным кодом с равномерными релизами, но вначале длительное время он был нацелен на использование в исследованиях, а не в производстве.
Поскольку исследовательский проект Postgres сворачивался, два студента Стоунбрейкера Эндрю Ю (Andrew Yu) и Джолли Чен (Jolly Chen) модифицировали синтаксический анализатор системы, чтобы заменить оригинальный язык Postquel расширяемым вариантом SQL. Первым релизом Postgres, поддерживающим SQL, был Postgres95, а следующий был назван PostgreSQL.
Группа разработчиков открытого исходного кода заинтересовалась PostgreSQL и «приняла» его даже тогда, как интересы остальной части команды Беркли изменились. Группа основных разработчиков PostgreSQL со временем остается относительно стабильной, и проект с открытым исходным кодом стал высокоразвитым. Вначале усилия были сосредоточены на стабильности кода и функциональности, видимой пользователю, но со временем сообщество разработчиков программного обеспечения с открытым исходным кодом значительно изменило и усовершенствовало ядро системы, от оптимизатора до методов доступа и основной системы транзакций и хранения. С середины 1990-х годов очень небольшая часть внутренних составляющих PostgreSQL исходила от академической группы в Беркли. Последним ее вкладом, возможно, была моя реализация GiST во второй половине 1990-х годов, но даже она была существенно переписана и очищена добровольцами из сообщества открытого исходного кода (в данном случае из России). Часть сообщества открытого исходного кода, что работает над PostgreSQL, заслуживает величайшей похвалы за осуществление упорядоченного процесса, который на протяжении десятилетий служил созданию в высшей степени эффективного и долгосрочного проекта.
Хотя многое изменилось за 25 лет, базовая архитектура PostgreSQL остается очень похожей на университетские релизы Postgres начала 1990-х годов, и разработчикам, знакомым с текущим исходным кодом PostgreSQL, будет нетрудно читать исходный код Postgres 3.1 (1991 г.). Все, от структуры каталогов исходного кода до структур процессов и структур данных, остается удивительно похожим. Код из команды Postgres в Беркли имел отличный костяк.
Сегодня PostgreSQL, без сомнения, является самой высокопроизводительной СУБД с открытым исходным кодом, причем она поддерживает функциональность, которая часто отсутствуют в коммерческих продуктах. Она также является (по словам одного влиятельного рейтингового сайта) наиболее популярной в мире широко используемой независимой СУБД с открытым кодом, и ее влияние продолжает расти: в 2017 и 2018 годах она была базой данных с самой быстро растущей популярностью в мире [DE19c]. PostgreSQL используется в самых разных отраслях промышленности и задачах, что неудивительно, учитывая ее нацеленность на широкие возможности.
По данным DB-Engines, PostgreSQL сегодня является четвертой по популярности СУБД в мире, после Oracle, MySQL и MS SQL Server, причем все три предлагаются конкретными компаниями (MySQL был приобретен Oracle много лет назад) [DE19a]. Правила ранжирования обсуждаются в описании методологии ранжирования DB-Engines [DE19b].
Heroku — облачный провайдер SaaS, который теперь является частью Salesforce. Postgres был внедрен в Heroku в 2010 году в качестве базы данных по умолчанию для своей платформы. Heroku выбрал Postgres за надежность в работе. С поддержкой со стороны Heroku более крупные платформы разработки приложений, такие как Ruby on Rails и Python for Django, стали рекомендовать Postgres в качестве базы данных по умолчанию.
Сегодня PostgreSQL поддерживает инфраструктуру расширений, которая позволяет легко добавлять дополнительные возможности в систему через пользовательские функции и связанные с ним модификации. Теперь есть экосистема расширений PostgreSQL, сродни концепции llustra пакетов расширений DataBlade, но с открытым исходным кодом. Наиболее интересные расширения включают, например, библиотеку Apache MADlib для машинного обучения в интерфейсе SQL и библиотеку Citus для параллельного выполнения запросов.
Одним из наиболее интересных приложений с открытым исходным кодом, построенных над Postgres, является географическая информационная система PostGIS, использующая многие возможности Postgres, которые первоначально вдохновили Стоунбрейкера начать проект.
3.2. Коммерческое внедрение
PostgreSQL уже давно является привлекательной отправной точкой для создания коммерческих систем баз данных, учитывая его использование по «всепозволяющей» лицензии на программное обеспечение с открытым исходным кодом, надежный код, гибкость и широкую функциональности. Суммируя стоимости приобретения, перечисленные ниже, видим, что от Postgres получилось более 2,6 млрд. долларов стоимости приобретения.
Обратите внимание, что это мера в долларах реальных финансовых операций и гораздо более существенная, чем значения, которые часто используются в сфере высоких технологий. Цифры в миллиардах часто используются для описания оценочной стоимости пакетов акций, но часто завышаются в 10 раз или более по сравнению с нынешней стоимостью в надежде на ее будущее значение. Доллары сделки приобретения компании измеряют ее фактическую рыночную стоимость на момент приобретения. Будет справедливым сказать, что Postgres создала более 2,6 миллиардов долларов реальной коммерческой стоимости.
Многие коммерческие усилия, связанные с PostgreSQL, были направлены на то, что, вероятно, является ее основным ограничением: возможность масштабирования до параллельной архитектуры без разделения ресурсов.
Распараллеливание PostgreSQL требует изрядной работы, но в высшей степени выполнимо небольшой опытной командой. Сегодня, отраслевые ветки открытого исходного кода PostgreSQL, такие как Greenplum и CitusDB, предоставляют такую возможность. Жаль, что PostgreSQL не был правильно распараллелен в открытом исходном коде намного раньше. Если бы в начале 2000-х годов PostgreSQL был расширен в открытом исходном коде поддержкой архитектуры без разделения ресурсов, вполне возможно, что направление больших данных с открытым исходным кодом развивалось бы совсем по-другому и более эффективно.
- Illustra была вторым крупным стартапом Стоунбрейкера, основанным в 1992 году для коммерциализации Postgres, поскольку компания RTI вывела Ingres на рынок.
Illustra было фактически третьим именем, предложенным для компании. Продолжая тему живописи, заданную названием Ingres, Illustra изначально называлась Miro. Из-за проблем с товарными знаками название было изменено на Montage, но оно также столкнулось с проблемами товарных знаков.
Команда основателей включала кое-кого из ядра команды Postgres, в том числе недавнего выпускника аспирантуры Вэя Хонга и тогдашнего главного программиста Джеффа Мередита, а также выпускников из Ingres Паулу Хоторн (Paula Hawthorn) и Майкла Убелла (Michael Ubell). Магистрант из Postgres Майк Олсон присоединился вскоре после основания, а я занимался в Illustra оптимизацией дорогостоящих функций в рамках моей кандидатской работы. В Illustra велись три основные работы: расширить SQL92 для поддержки пользовательских типов и функций, такой как в Postquel, сделать кодовую базу Postgres достаточно надежной для коммерческого использования и стимулировать рынок расширяемых серверов баз данных примерами расширений DataBlade — специализированными подключаемыми компонентами типов данных и функций. Illustra была приобретена Informix в 1997 году по оценочной стоимости 400 млн. долл. США [Mon96], а ее архитектура DataBlade была интегрирована в более устоявшийся код обработки запросов Informix как Informix Universal Server.
- Netezza была стартапом, основанным в 1999 году, который разветвил код PostgreSQL для создания высокопроизводительного механизма параллельной обработки запросов на заказном оборудовании на основе FPGA. Netezza была довольно успешной независимой компанией, которая провела первую публичную продажу акций в 2007 году. В конечном итоге она был приобретена IBM за 1,7 млрд. долл. США [IBM10].
- Greenplum предприняла первую попытку предложить параллельную горизонтально масштабирующуюся версию PostgreSQL без разделения ресурсов. Основанная в 2003 году, Greenplum ответвилась от публичного дистрибутива PostgreSQL, но в значительной степени сохранила API PostgreSQL, включая API для пользовательских функций. В дополнение к распараллеливанию, Greenplum расширила PostgreSQL альтернативным высокопроизводительным сжатым колоночным хранилищем и оптимизатором параллельных запросов, основанных на правилах, под названием Orca. Greenplum была приобретена EMC в 2010 году за 300 млн. долл. [Mal10], а в 2012 году EMC включила Greenplum в свою дочернюю компанию Pivotal. В 2015 году Pivotal решила снова выпускать Greenplum и Orca с открытым исходным кодом. Одним из достижений Greenplum по оптимизации Postgres API была библиотека MADlib для машинного обучения в SQL [HRS+12]. MADlib живет сегодня как проект Apache. Еще одним интересным проектом с открытым исходным кодом, основанным на Greenplum, является Apache HAWQ, разработка компании Pivotal, которая запускает «верхнюю половину» Greenplum (т. е. обработчик параллельных запросов и интерфейсы прикладного программирования расширяемости PostgreSQL) над хранилищами больших данных, такими как файловая система Hadoop.
- EnterpriseDB был создан в 2004 году как бизнес, основанный на ПО с открытым исходным кодом и продающий PostgreSQL как в базовом, так и в расширенном варианте и оказывающий связанные с этим услуги корпоративным клиентам. Ключевой особенностью улучшенного EnterpriseDB Advanced Server является совместимость базы данных с Oracle, обеспечивающая миграцию приложений из Oracle.
- Компания Aster Data была основана в 2005 году двумя студентами Стэнфорда, чтобы создать параллельный движок для аналитики. Ее основной одноузловой движок был основан на PostgreSQL. Aster сосредоточилась на запросах к графам и на пакетах аналитики на основе пользовательских функций, которые можно было запрограммировать с помощью интерфейса SQL или MapReduce. Aster Data была приобретена компанией Teradata в 2011 году за 263 млн. долл. [Sho11]. Хотя Teradata никогда не интегрировала Aster в свой основной движок параллельных баз данных, она по-прежнему поддерживает Aster как автономный продукт для вариантов использования за пределами основного рынка хранилищ данных Teradata.
- Компания ParAccel была основана в 2006 году, продавая параллельную версию PostgreSQL с колоночным хранилищем без разделения ресурсов. ParAccel расширила оптимизатор Postgres новыми эвристиками для запросов с большим количеством соединений. В 2011 году Amazon инвестировала в ParAccel, а в 2012 году анонсировала AWS Redshift — хранилище данных как сервис с размещением в публичном облаке на основе технологии ParAccel. В 2013 году ParAccel была приобретена компанией Actian (которая также приобрела Ingres) за нераскрытую сумму сделки, что означает, что это не было материальными затратами для Actian. Между тем предложение AWS Redshift имело огромный успех для Amazon — в течение многих лет это был самый быстрорастущий сервис хранилищ данных Amazon, и многие считают, что он готов вывести из бизнеса давно существующие продукты для хранилищ данных, такие как Teradata и Oracle Exadata. В этом смысле Postgres может достичь своего окончательного доминирования в облаке.
- Компания CitusDB (CitusDB — имя СУБД; компания называется Citus Data. — Прим. пер.) была основана в 2010 году, чтобы предложить параллельную реализацию PostgreSQL без разделения ресурсов. Хотя она начиналась как ветвь PostgreSQL, с 2016 года CitusDB реализована через открытый API расширений PostgreSQL и может быть инсталлирована в базовую установку PostgreSQL. С 2016 года расширения CitusDB доступны в открытом исходном коде.
4. Уроки
Вы можете извлечь множество уроков из успеха Postgres, некоторые из которых бросают вызов общепринятому мнению.
Урок высшего порядка, который я извлекаю, состоит в том, что Postgres бросил вызов «синдрому второй системы» (Second System Effect) по Фреду Бруксу (Fred Brooks) [Bro75]. Брукс утверждал, что дизайнеры вслед за успешной первой системой часто создают вторую, которая терпит неудачу из-за перегрузки возможностями и идеями. Postgres был второй системой Стоунбрейкера, и она, безусловно, была полна возможностей и идей. Система также успешно прототипировала многие идеи, при этом поставляя программную инфраструктуру, которая довела многие идеи до успешного завершения. Это не было случайностью — в своей основе Postgres был разработан с возможностью расширяемости, и этот дизайн был хорошо продуманным. С расширяемостью в качестве стержня архитектуры появилась возможность быть творческими и меньше беспокоиться о рамках: вы можете пробовать разные расширения, и пусть победит сильнейший. Сделанная хорошо, «вторая система» не обречена. Она выигрывает от доверия, любимых проектов и устремлений, сложившихся во время пользования первой системой. Это ранний архитектурный урок от более «серверно-ориентированной» школы разработки баз данных, которая бросает вызов устоявшемуся представлению «компонентно-ориентированной» школы разработки операционных систем.
Другой урок заключается в том, что акцент на универсальности, «один размер подходит всем», может быть выигрышным подходом как для исследований, так и для практики. Однако Стоунбрейкер времен МТИ (В 2001 году Стоунбрейкер занял должность профессора информатики в Массачусетском технологическом институте (МТИ). — Прим. пер.) наделал много шума в мире баз данных в начале 2000-х годов тезисом «один размер не всем подходит». Под этим знаменем он запустил флотилию важных проектов и стартапов, но ни один не мог тягаться размахом с Postgres. Кажется, что Стоунбрейкер времен Беркли бросает вызов более позднему опыту Стоунбрейкера времен МТИ, и я в этом не вижу проблем.
Как сказал Эмерсон (Ralph Waldo Emerson), «глупая последовательность — пугало мелких умишек».
Конечно, есть мудрость в девизе «один размер не всем подходит» (всегда можно найти скромные рынки для нестандартных решений), но успех системы, являющейся визитной карточкой Стоунбрейкера времен Беркли, далеко за пределами ее первоначальных целей, показывает, что подавляющее большинство проблем с базами данных вполне решаемы с помощью хорошей архитектуры общего назначения. Кроме того, проектирование этой архитектуры само по себе является технологической задачей и достижением. В конце концов, как и в большинстве научных и технических дебатов, есть не только один хороший способ что-то сделать. У обоих Стоунбрейкеров есть, чему научить нас. Но по натуре я все же поклонник более широкой программы, которую принял Стоунбрейкер времен Беркли.
Последний урок, который я извлекаю из Postgres, — это непредсказуемый потенциал, который может быть заложен в исследуемом вами открытом исходном коде. В своей Тьюринговской лекции Стоунбрейкер говорит об «интуитивной прозорливости» системы PostgreSQL, которая успешно развивается в открытом исходном коде, в основном благодаря людям не из окружения Стоунбрейкера. Вот цитата, которая звучит удивительно скромно:
Команда добровольцев, подхвативших проект, ни один из которых не имеет ничего общего со мной или Беркли, присматривает за этой системой с открытым исходным кодом с 1995 года. Система Postgres, которую вы получаете из интернета, является результатом работы этой команды. Это открытый исходный код в лучшем виде, и я просто хочу упомянуть, что не имею ничего общего с этим и с этим группой людей, перед которыми мы все в огромном долгу. [Sto14]Я уверен, что все мы, кто написал открытый исходный код, хотели бы, чтобы такая «интуитивная прозорливость» пришла к нам. Но дело не только в «интуитивной прозорливости». Источник удачи коренится, несомненно, в устремлениях, широте и проницательности Стоунбрейкера в проекте и в команде, которую он курировал при создании прототипа Postgres. Если в этом есть какой-то урок, он может быть таким: «сделай что-то важное и отпусти это на волю». Мне кажется (учась у Стоунбрейкера), вы не можете пропустить ни одной части этого урока.
5. Благодарности
Я благодарен моим старым приятелям по Postgres Вэю Хонгу, Джеффу Мередиту и Майку Олсону за их воспоминания и информацию, а также Крейгу Керстиенсу (Craig Kerstiens) за его вклад в современный PostgreSQL.
Литература
- [Bro75] Frederick P Brooks. The mythical man-month, 1975.
- [Bro19] Michael L. Brodie, editor. Making Databases Work. Morgan & Claypool, 2019.
- [DE19a] DB-Engines. DB-Engines ranking, 2019. db-engines.com/en/ranking. (Last accessed January 4, 2019).
- [DE19b] DB-Engines. Method of calculating the scores of the DB-Engines ranking, 2019. db-engines.com/en/ranking_definition (Last accessed January 4, 2019).
- [DE19c] DB-Engines. PostgreSQL is the DBMS of the year 2018, January 2019. db-engines.com/en/blog_post/79 (Last accessed January 4, 2019).
- [DS08] David DeWitt and Michael Stonebraker. Mapreduce: A major step backwards. The Database Column, 1:23, 2008.
- [Gut84] Antonin Guttman. R-trees: A dynamic index structure for spatial searching. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD ’84, pages 47–57, New York, NY, USA, 1984. ACM.
- [HKM+02] Joseph M. Hellerstein, Elias Koutsoupias, Daniel P. Miranker, Christos H. Papadimitriou, and Vasilis Samoladas. On a model of indexability and its bounds for range queries. J. ACM, 49(1):35–55, January 2002.
- [HNP95] Joseph M. Hellerstein, Jeffrey F. Naughton, and Avi Pfeffer. Generalized search trees for database systems. In Proceedings of the 21th International Conference on Very Large Data Bases, VLDB ’95, pages 562–573, San Francisco, CA, USA, 1995. Morgan Kaufmann Publishers Inc.
- [HRS+12] Joseph M Hellerstein, Christoper Re, Florian Schoppmann, Daisy Zhe Wang, Eugene Fratkin, Aleksander Gorajek, Kee Siong Ng, Caleb Welton, Xixuan Feng, Kun Li, et al. The MADlib analytics library: or MAD skills, the SQL. Proceedings of the VLDB Endowment, 5(12):1700–1711, 2012.
- [IBM10] IBM to acquire Netezza, September 2010. www-03.ibm.com/press/us/en/pressrelease/32514.wss#release (Last accessed January 22, 2018).
- [KMH97] Marcel Kornacker, C. Mohan, and Joseph M. Hellerstein. Concurrency and recovery in generalized search trees. In Proceedings of the 1997 ACM SIGMOD International Conference on Management of Data, SIGMOD ’97, pages 62–72, New York, NY, USA, 1997. ACM.
- [Mal10] Om Malik. Big Data = Big Money: EMC Buys Greenplum. In GigaOm, July 2010. gigaom.com/2010/07/06/emc-buys-greenplum.
- [Mon96] John Monroe. Informix acquires illustra for complex data management. In Federal Computer Week, January 1996.
- [OFS83] James Ong, Dennis Fogg, and Michael Stonebraker. Implementation of data abstraction in the relational database system ingres. ACM Sigmod Record, 14(1):1–14, 1983.
- [Ols93] Michael A. Olson. The design and implementation of the inversion file system. 1993.
- [SAHR84] Michael Stonebraker, Erika Anderson, Eric Hanson, and Brad Rubenstein. Quel as a data type. In Proceedings of the 1984 ACM SIGMOD International Conference on Management of Data, SIGMOD ’84, pages 208–214, New York, NY, USA, 1984. ACM.
- [Sho11] Erick Shonfeld. Big pay day for big data. teradata buys aster data for $263 million. In TechCrunch, May 2011. techcrunch.com/2011/03/03/teradata-buys-aster-data-263-million (Last accessed January 22, 2018).
- [SHWK76] Michael Stonebraker, Gerald Held, Eugene Wong, and Peter Kreps. The design and implementation of ingres. ACM Transactions on Database Systems (TODS), 1(3):189–222, 1976.
- [SK91] Michael Stonebraker and Greg Kemnitz. The postgres next generation database management system. Commun. ACM, 34(10):78–92, October 1991.
- [SR86] Michael Stonebraker and Lawrence A. Rowe. The design of postgres. In Proceedings of the 1986 ACM SIGMOD International Conference on Management of Data, SIGMOD ’86, pages 340–355, New York, NY, USA, 1986. ACM.
- [SRG83] M Stonebraker, B Rubenstein, and A Guttman. Application of abstract data types and abstract indices to cad bases. IEEE Trans, on Software Engineering, 1983.
- [Sto86] Michael Stonebraker. The case for shared nothing. IEEE Database Eng. Bull., 9(1):4–9, 1986.
- [Sto87] Michael Stonebraker. The design of the postgres storage system. In Proceedings of the 13th International Conference on Very Large Data Bases, VLDB ’87, pages 289–300, San Francisco, CA, USA, 1987. Morgan Kaufmann Publishers Inc.
- [Sto95] Michael Stonebraker. An overview of the sequoia 2000 project. Digital Technical Journal, 7(3):39–49, 1995.
- [Sto14] Michael Stonebraker. The land sharks are on the squawk box, 2014. www.acm.org/turing-lecture-stonebraker (Last accessed January 4, 2019).