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

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 (доданий у версії PostgreSQL 9.4) можна створювати 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 описані у відповідному розділі документації проекту PostgreSQL.

В месенджері Kato таблиці hstore використовуються для зберігання налаштувань і атрибутів різних об'єктів: акаунтів, кімнат, команд та організацій.

Кільця історії

Історія йде по колу, і дуже часто фраза «все нове — це добре забуте старе» є вірною — багато сучасні тенденції в області побудови СУБД і роботи з даними були осмислені і передбачені творцями реляційної моделі та розробниками SQL.

PostgreSQL є канонічним прикладом проекту, який постійно вбирає в себе результати досліджень провідних світових фахівців. У підсумку ця СУБД виступає в ролі своєрідного універсального конструктора, і стартапи, використовуючи його деталі, можуть дуже швидко створювати працюють комерційні продукти, не боячись опинитися у глухому куті через несподіваного розширення номенклатури розв'язуваних завдань.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.