Почему реляционные СУБД отлично подходят для стартапов: Пример из истории разработки мессенджера Kato

^[1]

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

Соответственно, технологический прогресс шел не только по направлениям увеличения мощности процессоров, объемов памяти или уменьшения размеров устройств, но и в области улучшения эффективности работы с данными. В результате появилось большое количество различных систем управления базами данных (СУБД).

В нашем продукте, мессенджере для корпоративных коммуникаций Kato ^[2], используется СУБД PostgreSQL. Сегодня мы хотели бы напомнить историю возникновения этого прекрасного инструмента и показать преимущества его использования для стартапов в области информационных технологий.

Реляционная модель и SQL

Традиционно выделяются три главных направления СУБД по различным моделям данных, на которых эти направления основаны — сетевые, иерархические, реляционные.

Реляционная модель данных, ныне самая популярная и продвинутая из трёх названных, была изначально разработана в конце 60-х годов прошлого века британским ученым, сотрудником компании IBM, Эдгаром Коддом ^[3]. В 1970 году он опубликовал первую работу по реляционной модели данных, «A Relational Model of Data for Large Shared Data Banks ^[4]».

Создатель реляционной модели данных Эдгар Кодд

Кодд предложил набор из 8 базовых операций, которые можно осуществлять над данными, и этот набор положил начало реляционной алгебре ^[5]. На основе созданной Коддом алгебры в середине 70-х годов прошлого века начал развиваться (среди многих других) язык программирования для работы с данными в реляционных базах под названием SQL, который был стандартизован в 1986 году.

Исследования в Беркли: Появление Postgres

Одной из первых систем управления реляционными базами данных стала открытая система Ingres ^[6] — она была создана исследователями из Беркли, которые заинтересовались публикациями IBM об их проекте реляционной базы данных Project R и попытались разработать свою систему. В Ingres использовался язык для составления запросов, отличный от SQL — он назывался QUEL ^[7].

Впоследствии Майкл Стоунбрейкер, ранее занимавшийся созданием Ingres, вместе со своими студентами в Беркли запустил новый проект — Post Ingres (Postgres). Новая система разрабатывалась с 1986 до 1995 года и использовала продолжателя QUEL — язык запросов POSTQUEL.

Майкл Стоунбрейкер

Позднее Стоунбрейкер основал несколько компаний, занимавшихся разработкой СУБД (примеры: Illustra ^[8], купленная компанией Informix ^[9]; StreamBase Systems ^[10]; Vertica ^[11], купленная ^[12] HP; VoltDB ^[13]).

Его студенты, участвовавшие в работе над Postgres, создали собственную версию базы данных, в которой POSTQUEL был заменен на SQL. Проект изначально назывался Postgres95, и получил свое текущее название — PostgreSQL — после передачи этой разработки Калифорнийским университетом Беркли в руки команды энтузиастов.

Проблемы СУБД: Рождение NoSQL

В конце девяностых и начале 2000-х годов на рынке СУБД сложилась ситуация, при которой существовало немалое количество популярных баз данных, однако каждая из них обладала серьезными минусами. В случае коммерческих Oracle, IBM DB2 и Microsoft SQL Server этим минусом были весьма существенные цены, а популярнейший свободный проект MySQL обладал ограниченной функциональностью (например, хранимые процедуры, триггеры и представления появились в этой СУБД лишь в 2005 году).

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

Проблемы имеющихся продуктов, использующих SQL и реляционную модель вообще, побудили энтузиастов к созданию баз данных, работающих с применением других стандартов — так родилось множество проектов, которые можно объединить в общую категорию NoSQL ^[14].

Возник целый ряд NoSQL баз данных (некоторые известные примеры: MongoDB, Redis, Riak). Развитие этого направления пошло по пути фрагментации и создания узкоспециализированных продуктов.

СУБД и стартапы

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

Постепенно, однако, выяснилось, что у СУБД из категории NoSQL есть следующее критичное (и очень неприятное) свойство — они хороши для решения только весьма узко определенных задач. Это свойство автоматически делало применение условного MongoDB в стартапе очень рискованным шагом — на начальном этапе условный MongoDB может быть идеальным выбором для решаемого круга задач, однако в момент, когда стартап несколько меняет стратегию (а так бывает почти всегда), некая другая СУБД может оказаться гораздо более подходящей для решения задач в новой постановке. Скорее всего, «переезд» на эту другую СУБД будет слишком сложной и дорогой операцией, которую начинающему бизнесу осуществить будет не под силу.

С другой стороны, во время бурного развития СУБД из категории NoSQL, разработчики традиционных реляционных СУБД также не сидели сложа руки. В частности, создатели PostgreSQL поработали над производительностью, удобством администрирования и документацией своего проекта, в результате чего в конце двухтысячных годов из «занудного и непонятного античного инструмента для пожилых бородатых, пузатых и лысых дядек» он превратился в точное, быстрое и современное оружие, необходимое в арсенале любого «хипстера от технологии».

^[15]

PostgreSQL и мессенджер Kato

Разработчики из команды Kato были заняты в различных технологических компаниях и стартапах (например, в проекте Rdio ^[16]) и на собственном опыте прочувствовали плюсы и минусы работы с многими существующими СУБД (и попутно наступили почти на все возможные грабли, связанные с построением системы с нуля). Как результат, начиная работу над своим проектом, мы выбрали именно PostgreSQL.

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

Неизменность схемы данных является одним из популярных плюсов NoSQL. Модуль hstore ^[17] (кстати, сделанный москвичами) из PostgreSQL позволяет записывать ключи и значения в колонки таблицы, что избавляет разработчиков от необходимости постоянного изменения схемы данных в процессе добавления новой функциональности продукта. При этом сохраняется возможность создания индексов.

В версии PostgreSQL 9.4 появился новый тип — JSON ^[18]. В отличии от 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 описаны в соответствующем разделе документации ^[19] проекта PostgreSQL.

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

Кольца истории

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

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

Автор: KatoProject

Источник ^[20]