15 января 2015 в 13:04

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

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 является каноническим примером проекта, который постоянно вбирает в себя результаты исследований ведущих мировых специалистов. В итоге эта СУБД выступает в роли своеобразного универсального конструктора, и стартапы, используя его детали, могут очень быстро создавать работающие коммерческие продукты, не боясь оказаться в тупике из-за неожиданного расширения номенклатуры решаемых задач.
Автор: @KatoProject
Kato.im
рейтинг 33,95

Комментарии (20)

  • 0
    Интересный пост, спасибо. Стоунбрейкер вызывает восхищение, конечно — столько проектов и такие результаты.
  • +1
    Сейчас прилично сервисов по подборке комбинаций технологий для стартапов, но вот реальным опытом (на русском особенно) мало кто делится. Буду ждать подобных тем в вашем блоге, спасибо!
    • +2
      Мы подумаем, что можно в таком духе еще сделать.
    • 0
      подскажите, пожалуйста, пару таких сервисов
  • 0
    Это всё хорошо конечно, но как же бенчмарки?
  • +5
    PostgreSQL считается постреляционной системой. И действительно весьма хорош.
  • +1
    Не очень понял, при чем тут стартап? Да, конкретному проекту Като подошла традиционная SQL база PostgreSQL. Отлично, но это, ИМХО, отнюдь не повод утверждать, что «реляционные СУБД отлично подходят для стартапов». Это как сказать, что PHP для стартапов лучше Ruby.
    • +2
      Стартапы часто меняют стратегию — это значит, что им лучше пользоваться гибкими инструментами (а не модными и хорошо подходящими для узких сегментов задач). Если говорить о СУБД, то здесь PostgreSQL, на наш взгляд, больше подходит для создания и масштабирования новых ИТ-проектов.

      Естественно, это только наше мнение, а не истина в последней инстанции).
      • 0
        Это очень хорошее и правильное мнение.

        Современный Постгрес позволяет сочетать строгость схемы там, где это очень-очень желательно (условная табличка users с нужными ограничениями целостности) и гибкость там, где схема должна часто меняться — как в вашем примере с сообщениями. А главное, всё это со строгой реализацией ACID.

        Статья отличная, только хотелось бы побольше «техники», но это чисто моя хотелка.

        А вы в итоге уже используете 9.4 и jsonb или в бою пока только hstore?
        • 0
          Пока что только hstore, но планируем опробовать jsonb в скором времени.
  • +1
    Поддержка JSON была и в 9.2, в 9.4 появился JSONB, поддержка индексов и расширенный набор функций.
    • 0
      Точно, вы правы.
  • +1
    Согласен с автором, некоторое время назад начал проект с MongoDB, теперь подумываю вернуться к старому-доброму Postgres. С реляционной СУБД можно делать всё, что угодно – а NoSQL накладывает свои ограничения, которые могут помешать реализации новых фич в продукте, не предусмотренных на этапе начального планирования. К тому же согласно бенчмаркам Postgres обходит Mongo в производительности.
  • +3
    Ждал увлекательный рассказ про гибкость реляционной модели, а получил экскурс в историю и описание какого-то костыля к PostgreSQL.

    Те же запросы в менее реляционной базе выглядят куда более наглядно.

    Создаём класс и свойство:

    create class hstore_test
    create property hstore_test.data embeddedmap string
    

    Создаём докумет:

    insert into hstore_test content { "data" : { "a" : "hello" , "b" : "world" } }
    

    Обновляем вложенное значение:

    update hstore_test set data.b = 'world!'
    

    Читаем вложенное значение:

    select data.b from hstore_test
    

    • 0
      а что это за менее реляционная база?

      а как по вашему мог бы выглядеть увлекательный рассказ про гибкость реляционной модели (в современных реалиях, т.е. с освещением JSON и т.п.)? что он должен содержать?
      • 0
        OrientDB

        Что-то типа: у нас были такие-то условия и мы решили сделать так-то, вдруг условия поменялись кардинально, но мы так-то просто адаптировали к ним, не переколбашивая капитально всю базу и архитектуру приложения.
  • 0
    А есть ли для postgres master-master репликация простая в настройке? В интернете часто встречаю статьи про танцы с бубнами. Причем желательно вставлять данные в оба мастера и чтобы это работало между 2-мя ЦОДами, пусть не быстро но стабильно.
    Ну и еще вопрос в догонку ) Вот есть у меня несколько таблиц (штук 5) которые джоинятся чтобы получить итоговый результат. В одной из таблиц штук 15 столбцов и по каждому столбцу индекс (т.к. хотим сортировать по любому столбцу). Теперь вопрос: сколько максимально записей можно хранить в такой таблице на хорошем выделенном серваке с ssd дисками, 256г оперативки и т.д. Чтобы база хоть как-то шевелилась. Ну приблизительно порядок хотябы. Подойдет ответ в стиле «более 100 млн не рекомендуется, возможны тормоза...». Спасибо!
  • 0
    то есть у вас postgres используется как для хранения так и для поиска по сообщениям?
    рассматривали вы  elasticsearch и другие подобые системы? если да, то почему не взяли в использование?
    • 0
      Да, как для хранения, так и для поиска.

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

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разное