Исторически развитие компьютеров шло параллельно с прогрессом в области управления базами данных — это обуславливалось тем фактом, что среди задач, решаемых исследователями и практиками, огромную роль играли (и продолжают играть в данный момент) задачи обработки полученных данных, их компактного хранения и быстрейшего поиска.
Соответственно, технологический прогресс шел не только по направлениям увеличения мощности процессоров, объемов памяти или уменьшения размеров устройств, но и в области улучшения эффективности работы с данными. В результате появилось большое количество различных систем управления базами данных (СУБД).
В нашем продукте, мессенджере для корпоративных коммуникаций Kato, используется СУБД PostgreSQL. Сегодня мы хотели бы напомнить историю возникновения этого прекрасного инструмента и показать преимущества его использования для стартапов в области информационных технологий.
Реляционная модель и SQL
Традиционно выделяются три главных направления СУБД по различным моделям данных, на которых эти направления основаны — сетевые, иерархические, реляционные.
Реляционная модель данных, ныне самая популярная и продвинутая из трёх названных, была изначально разработана в конце 60-х годов прошлого века британским ученым, сотрудником компании IBM, Эдгаром Коддом. В 1970 году он опубликовал первую работу по реляционной модели данных, «A Relational Model of Data for Large Shared Data Banks».
Создатель реляционной модели данных Эдгар Кодд
Кодд предложил набор из 8 базовых операций, которые можно осуществлять над данными, и этот набор положил начало реляционной алгебре. На основе созданной Коддом алгебры в середине 70-х годов прошлого века начал развиваться (среди многих других) язык программирования для работы с данными в реляционных базах под названием SQL, который был стандартизован в 1986 году.
Исследования в Беркли: Появление Postgres
Одной из первых систем управления реляционными базами данных стала открытая система Ingres — она была создана исследователями из Беркли, которые заинтересовались публикациями IBM об их проекте реляционной базы данных Project R и попытались разработать свою систему. В Ingres использовался язык для составления запросов, отличный от SQL — он назывался QUEL.
Впоследствии Майкл Стоунбрейкер, ранее занимавшийся созданием Ingres, вместе со своими студентами в Беркли запустил новый проект — Post Ingres (Postgres). Новая система разрабатывалась с 1986 до 1995 года и использовала продолжателя QUEL — язык запросов POSTQUEL.
Майкл Стоунбрейкер
Позднее Стоунбрейкер основал несколько компаний, занимавшихся разработкой СУБД (примеры: Illustra, купленная компанией Informix; StreamBase Systems; Vertica, купленная HP; VoltDB).
Его студенты, участвовавшие в работе над Postgres, создали собственную версию базы данных, в которой POSTQUEL был заменен на SQL. Проект изначально назывался Postgres95, и получил свое текущее название — PostgreSQL — после передачи этой разработки Калифорнийским университетом Беркли в руки команды энтузиастов.
Проблемы СУБД: Рождение NoSQL
В конце девяностых и начале 2000-х годов на рынке СУБД сложилась ситуация, при которой существовало немалое количество популярных баз данных, однако каждая из них обладала серьезными минусами. В случае коммерческих Oracle, IBM DB2 и Microsoft SQL Server этим минусом были весьма существенные цены, а популярнейший свободный проект MySQL обладал ограниченной функциональностью (например, хранимые процедуры, триггеры и представления появились в этой СУБД лишь в 2005 году).
В то же время PostgreSQL, несмотря на то, что его разработчики проделали огромную по объёму и в целом очень качественную работу, не мог похвастаться высокой скоростью и простотой администрирования, что ограничивало его использование в коммерческих проектах.
Проблемы имеющихся продуктов, использующих SQL и реляционную модель вообще, побудили энтузиастов к созданию баз данных, работающих с применением других стандартов — так родилось множество проектов, которые можно объединить в общую категорию NoSQL.
Возник целый ряд NoSQL баз данных (некоторые известные примеры: MongoDB, Redis, Riak). Развитие этого направления пошло по пути фрагментации и создания узкоспециализированных продуктов.
СУБД и стартапы
Появление большого числа новых NoSQL-разработок в какой-то момент изменило отношение в стартапах к традиционным SQL-системам — они стали восприниматься создателями ИТ-проектов как чересчур сложные, старомодные и тяжёлые для работы в современных динамичных приложениях.
Постепенно, однако, выяснилось, что у СУБД из категории NoSQL есть следующее критичное (и очень неприятное) свойство — они хороши для решения только весьма узко определенных задач. Это свойство автоматически делало применение условного MongoDB в стартапе очень рискованным шагом — на начальном этапе условный MongoDB может быть идеальным выбором для решаемого круга задач, однако в момент, когда стартап несколько меняет стратегию (а так бывает почти всегда), некая другая СУБД может оказаться гораздо более подходящей для решения задач в новой постановке. Скорее всего, «переезд» на эту другую СУБД будет слишком сложной и дорогой операцией, которую начинающему бизнесу осуществить будет не под силу.
С другой стороны, во время бурного развития СУБД из категории NoSQL, разработчики традиционных реляционных СУБД также не сидели сложа руки. В частности, создатели PostgreSQL поработали над производительностью, удобством администрирования и документацией своего проекта, в результате чего в конце двухтысячных годов из «занудного и непонятного античного инструмента для пожилых бородатых, пузатых и лысых дядек» он превратился в точное, быстрое и современное оружие, необходимое в арсенале любого «хипстера от технологии».
PostgreSQL и мессенджер Kato
Разработчики из команды Kato были заняты в различных технологических компаниях и стартапах (например, в проекте Rdio) и на собственном опыте прочувствовали плюсы и минусы работы с многими существующими СУБД (и попутно наступили почти на все возможные грабли, связанные с построением системы с нуля). Как результат, начиная работу над своим проектом, мы выбрали именно PostgreSQL.
Для коммерческих проектов очень важно наличие хороших возможностей по масштабированию тех или иных аспектов. У каждого проекта эти аспекты свои — например, в Kato нам необходимо масштабировать базу истории сообщений в комнатах.
Неизменность схемы данных является одним из популярных плюсов NoSQL. Модуль hstore (кстати, сделанный москвичами) из PostgreSQL позволяет записывать ключи и значения в колонки таблицы, что избавляет разработчиков от необходимости постоянного изменения схемы данных в процессе добавления новой функциональности продукта. При этом сохраняется возможность создания индексов.
В версии PostgreSQL 9.4 появился новый тип — JSON. В отличии от hstore, тип JSON поддерживает вложенные структуры, что делает PostgreSQL удобным средством для работы с документами. Также важно, что для типа jsonb можно создавать GIN-индексы, что дает возможность быстрого поиска по JSON-объектам.
Внедрение hstore и типа JSON сделало возможным создание баз даных в стиле NoSQL внутри таблиц PostgreSQL, что позволяет одновременно использовать плюсы NoSQL и SQL.
Приведём несколько типовых операций для иллюстрации возможностей модуля hstore.
Создаем hstore extension и таблицу с колонкой типа hstore:
Добавляем запись hstore, где два ключа — ‘a’ со значением ‘hello’ и ‘b’ со значением ‘world’:
Смотрим значение ключа ‘a’:
Узнаём, существует ли ключи ‘a’ и ‘c’:
Меняем значение ключа ‘b’:
Все операции с типом hstore описаны в соответствующем разделе документации проекта PostgreSQL.
В мессенджере Kato таблицы hstore используются для хранения настроек и атрибутов различных объектов: аккаунтов, комнат, команд и организаций.
Кольца истории
История идет кругами, и очень часто фраза «все новое — это хорошо забытое старое» является верной — многие современные тенденции в области построения СУБД и работы с данными были осмыслены и предвосхищены создателями реляционной модели и разработчиками SQL.
PostgreSQL является каноническим примером проекта, который постоянно вбирает в себя результаты исследований ведущих мировых специалистов. В итоге эта СУБД выступает в роли своеобразного универсального конструктора, и стартапы, используя его детали, могут очень быстро создавать работающие коммерческие продукты, не боясь оказаться в тупике из-за неожиданного расширения номенклатуры решаемых задач.
Автор: KatoProject
