- PVSM.RU - http://www.pvsm.ru -

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

image [1]

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

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

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

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

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

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

image

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

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

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

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

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

image

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

Позднее Стоунбрейкер основал несколько компаний, занимавшихся разработкой СУБД (примеры: 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].

image

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

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

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

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

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

image [15]

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

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

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

image

Неизменность схемы данных является одним из популярных плюсов 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:

image

Добавляем запись hstore, где два ключа — ‘a’ со значением ‘hello’ и ‘b’ со значением ‘world’:

image

Смотрим значение ключа ‘a’:

image

Узнаём, существует ли ключи ‘a’ и ‘c’:

image

Меняем значение ключа ‘b’:

image

Все операции с типом hstore описаны в соответствующем разделе документации [19] проекта PostgreSQL.

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

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

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

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

Автор: KatoProject

Источник [20]


Сайт-источник PVSM.RU: http://www.pvsm.ru

Путь до страницы источника: http://www.pvsm.ru/postgresql/79665

Ссылки в тексте:

[1] Image: http://habrahabr.ru/company/kato/blog/247961/

[2] Kato: https://kato.im/

[3] Эдгаром Коддом: https://ru.wikipedia.org/wiki/%D0%9A%D0%BE%D0%B4%D0%B4,_%D0%AD%D0%B4%D0%B3%D0%B0%D1%80

[4] A Relational Model of Data for Large Shared Data Banks: http://www.seas.upenn.edu/~zives/03f/cis550/codd.pdf

[5] реляционной алгебре: https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%B0%D0%BB%D0%B3%D0%B5%D0%B1%D1%80%D0%B0

[6] Ingres: https://en.wikipedia.org/wiki/Ingres_(database)

[7] QUEL: https://en.wikipedia.org/wiki/QUEL_query_languages

[8] Illustra: https://en.wikipedia.org/wiki/Illustra

[9] купленная компанией Informix: http://fcw.com/Articles/1996/01/07/Informix-acquires-Illustra-for-complex-data-management.aspx

[10] StreamBase Systems: https://en.wikipedia.org/wiki/StreamBase_Systems

[11] Vertica: https://en.wikipedia.org/wiki/Vertica

[12] купленная: http://h30261.www3.hp.com/phoenix.zhtml?c=71087&p=irol-newsarticle&ID=1528593

[13] VoltDB: https://en.wikipedia.org/wiki/VoltDB

[14] NoSQL: https://en.wikipedia.org/wiki/NoSQL

[15] Image: http://i.imgur.com/NO5OeY9.png

[16] Rdio: http://www.rdio.com/

[17] hstore: http://www.postgresql.org/docs/9.1/static/hstore.html

[18] JSON: http://www.postgresql.org/docs/devel/static/datatype-json.html

[19] разделе документации: http://www.postgresql.org/docs/9.4/static/hstore.html

[20] Источник: http://habrahabr.ru/post/247961/