Max Home IndustryИсторические воспоминания о проекте Postgres и его влиянии на индустрию СУБД позволяют понять ключевые особенности объектно-реляционной базы данных, задуманной Майком Стоунбрейкером.
Эссе «Взгляд назад на Postgres», свободно доступное в виде pdf-файла на arXiv.org, также является частью только что выпущенной книги «Заставить базы данных работать — прагматическая мудрость Майкла Стоунбрейкера». Он исходит от Джозефа М. Хеллерштейна, видного исследователя проекта Калифорнийского университета в Беркли Постгрес, который возглавлял аналитический центр Stonebraker с середины 1980-х до середины 1990-х годов, и проводит нас в великолепном путешествии по эволюции Проект Postgres. Во время этого путешествия Хеллерштайн останавливается на основных этапах своей работы, чтобы подробно рассказать о своем дальновидном мышлении, заложившем основы технологий, формирующих индустрию баз данных сегодня, спустя десятилетия после зарождения проекта.
В самом начале статьи есть ссылка на еще один проект Беркли, который я не могу оставить незамеченным. Это ссылка на Ingres, колыбель систем реляционных баз данных, которую я использую до сих пор.
Не только Postgres находился под сильным влиянием проекта Ingres 1970-х, но и начал свою жизнь как его ответвление. Диаграмма «Генеалогия реляционных баз данных», которая визуализирует историю реляционных баз данных, показывает, что Ingres была самой первой реляционной СУБД и что примерно в 1980 году Postgres возникла как простая ее ветвь. В конце концов, все дело в названии; Postgres для Post-Ingres, то есть выходящий за рамки возможностей Ingres.
С коммерческой точки зрения дела у Ingres пошли не так хорошо, как у Postgres. Сегодня Postgres занимает 4-е место в рейтинге самых популярных RDMB на StackOverflow и 1-е место среди приложений с открытым исходным кодом. Напротив, Ingres, несмотря на то, что внес свой вклад в большой успех своего преемника, примечателен своим отсутствием.
Майк Стоунбрейкер, начавший с Ingres, придумал видение объектно-реляционной базы данных, которое он реализовал позже, когда начал работать над Postgres. Давайте рассмотрим инновационные идеи, которые сформировали это видение. Поддержка ADT в системе баз данных В основе понятия объектно-реляционной базы данных лежала поддержка ADT или абстрактных типов данных, которые выходили за рамки традиционных типов данных, обрабатываемых базой данных. Это были сложные объекты или данные, которые должны были храниться в виде вложенных пакетов в разительный контраст с классическим сглаживанием данных реляционной модели для удаления дублирования. Это началось как попытка удовлетворить потребности приложений САПР, которые используют такие типы данных, как многоугольники, прямоугольники или даже полностью раздутые объекты, такие как механизмы компоновки схем. сегодня это JSON, JSONB или XML. Хранение таких данных было лишь одной частью истории; другая заключалась в том, чтобы также разрешить выполнение декларативных запросов к ним. В то время никто не догнал эту идею, но до тех пор, пока намного позже по линии.
Эта схема была дополнительно расширена, позволив программистам объявлять свои собственные определяемые пользователем типы и определяемые пользователем функции для работы с такими типами.
Между тем, «стеки больших данных 2000-х годов, в том числе феномен MapReduce, вызвавший такую изжогу у Стоунбрейкера и ДеВитта, — это повторная реализация идеи Postgres о пользовательском коде, размещенном в среде запросов».
Расширяемые методы доступа для новых типов данных Еще одним нововведением были индексы B-Tree, с которыми сегодня все знакомы, а также индексы R-Tree, которые позволяли выполнять запросы двухмерного диапазона к данным. Эти достижения заложили основу расширяемости Postgres, что частично отражено сегодня в индексах и интерфейсах Gist, которые используются в знаменитой географической информационной системе PostGIS.
Активные базы данных и системы правил Правила или триггеры, впервые появившиеся в Ingres, были еще одной конструкцией, популяризированной Postgres, которая нашла свое применение во всех основных механизмах баз данных. Подробнее об этом можно прочитать в моей статье «Подключение к внешнему миру с помощью Perl и событий базы данных», в которой подробно рассматриваются правила, события базы данных и хранимые процедуры в современных Ingres.
Хранение и восстановление, ориентированное на журнал Не любя схемы упреждающей записи, Stonebraker «объединил первичное хранилище и исторический журнал в единое простое дисковое представление», что не только упростило восстановление, но и позволило путешествовать во времени, то есть запускать запросы «как некоторого времени настенных часов, чтобы получить доступ к версиям данных, которые были зафиксированы в то время «. В то время как запросы на управление версиями и путешествия во времени никогда не получали особого внимания внутри проекта, они, наконец, были заменены схемой упреждающей записи, как и остальная поставщики сделали это, тем не менее, он заложил основы для MVCC, как это было испытано на уровне изоляции моментальных снимков Oracle.
Поддержка мультипроцессоров. Совместное использование памяти и процессоров XPRSS для поддержки оптимизации параллельных запросов было еще одной новинкой, созданной Postgres. Хотя, вероятно, единственным слабым местом Postgres является то, что он не может масштабироваться до параллельной архитектуры кластеров без общего доступа, статья Стоунбрейкера о «Case for Shared Nothing» подпитала технологии, лежащие в основе Gamma, Terradata и эпохи больших данных как Но благодаря расширяемости Postgres возникли такие продукты, как кластер баз данных Citus, PostgresForest или Postgres-xc, которые основаны на обычном Postgres и делают его способным понимать и выполнять параллельные запросы как распределенную базу данных без совместного использования.
Поддержка разнообразных языковых моделей Несоответствие импеданса между объектно-ориентированными языками программирования и декларативной реляционной моделью было и остается одной из самых острых проблем компьютерной индустрии. , полностью обходя объектно-ориентированные базы данных. Мало того, что сегодня все поставщики поддерживают эту схему, но еще одна студентка этого плодотворного проекта, Марго Зельцер, представила понятие хранилищ ключевых значений, относящееся к движению NoSQL.
Открытый исходный код Postgres стал открытым исходным кодом, поэтому открыт для внесения вкладов, как только он вырвался за пределы лаборатории Беркли. Именно это свойство в конечном итоге позволило ему превратиться в плавильный котел новейших и величайших идей; и этот шаг очень скоро принес свои дивиденды. После того, как двое студентов представили в движок вариант SQL вместо приличного языка запросов Postquel (QUEL принадлежал Ingres), команда отвлеклась другими делами. не только периферийный вклад, но и улучшение самого ядра. С тех пор сообщество росло.
Коммерческие адаптации «PostgreSQL долгое время был привлекательной отправной точкой для создания коммерческих систем баз данных, учитывая его разрешительную лицензию с открытым исходным кодом, надежную кодовую базу, гибкость и широту функциональности».
В результате многие продукты основаны на нем или даже являются его вилками.
Greenplum был первой попыткой предложить параллельную горизонтально масштабируемую версию PostgreSQL без совместного использования ресурсов.
EnterpriseDB была основана в 2004 году как компания с открытым исходным кодом, которая продает PostgreSQL как в оригинальном, так и в расширенном варианте с соответствующими услугами для корпоративных клиентов.
ParAccel улучшил оптимизатор Postgres новой эвристикой для запросов с большим количеством объединений. В 2011 году Amazon инвестировал в ParAccel, а в 2012 году анонсировал AWS Redshift, размещенное хранилище данных как услугу в общедоступном облаке на основе технологии ParAccel.
CitusDB была основана в 2010 году, чтобы предложить параллельную реализацию PostgreSQL без совместного использования ресурсов. Хотя он начинался как форк PostgreSQL, с 2016 года CitusDB реализован через общедоступные API-интерфейсы расширений PostgreSQL и может быть установлен в обычную установку PostgreSQL.
Извлеченные уроки Уроки, извлеченные из курса и истории Postgres, заключаются в том, что для того, чтобы продукт стал успешным, он, прежде всего, должен быть расширяемым:
«Благодаря расширяемости в качестве архитектурного ядра можно проявить творческий подход и перестать так сильно беспокоиться о дисциплине: вы можете попробовать множество расширений и позволить сильным добиться успеха. При хорошем исполнении« вторая система »не обречена; она выигрывает от уверенности , любимые проекты и амбиции, развивавшиеся во время первой системы «.
Во-вторых, понять, что, несмотря на то, что «один размер» не подходит для всех задач, архитектура базы данных общего назначения, как и любая другая технология общего назначения, может подойти большинству.
И, наконец, успех, который приходит с открытым исходным кодом для всего, что «сделай что-то важное и освободи это».