Pull to refresh
0

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

Reading time 6 min
Views 26K
image

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

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

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

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


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

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

image

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

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

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


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

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

image

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

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

image

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

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


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

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

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

image

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


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

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

image

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

В версии PostgreSQL 9.2 появился новый тип — JSON. В отличии от hstore, тип JSON поддерживает вложенные структуры, что делает PostgreSQL удобным средством для работы с документами. Также важно, что для типа jsonb можно создавать GIN-индексы, что дает возможность быстрого поиска по JSON-объектам.

Внедрение hstore и типа JSON сделало возможным создание баз даных в стиле NoSQL внутри таблиц PostgreSQL, что позволяет одновременно использовать плюсы NoSQL и SQL.

Приведём несколько типовых операций для иллюстрации возможностей модуля hstore.

Создаем hstore extension и таблицу с колонкой типа hstore:

postgres=# create extension hstore;
WARNING:  => is deprecated as an operator name
DETAIL:    This name may be disallowed altogether in future versions of QL.
CREATE EXTENSION
postgres=# create table hstore_test (data hstore);
CREATE TABLE

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

postgres=# insert into hstore_test values (hstore(array['a', 'hello', 'b', 'world']));
INSERT 0 1
postgres=#

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

postgres=# SELECT data->'a' FROM hstore_test;
 ?column?
----------
 hello
(1 row)
postgres=# ▄

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

postgres=# select data ? 'a', data ? 'c' from hstore_test;
 ?column? | ?column?
----------+--------------
 t        | f
(1 row)


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

postgres=# update hstore_test set data = data || ('b' => 'world!');
UPDATE 1
postgres=# select data->'b' from hstore_test;
 ?column?
--------------
 world!
(1 row)

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

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

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


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

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

Articles

Information

Website
kato.im
Registered
Employees
11–30 employees
Location
США