Раздел 4.2. Базы данных: Революция и Эволюция (1970 — 2010)

В предыдущем разделе мы соединили мир проводами (Интернет) и дали ему интерфейс (Браузер). Но оставалась гигантская дыра. Интернет 1.0 был статичным. Это были просто цифровые брошюры.

Чтобы создать Amazon, Facebook или онлайн-банк, интернету нужна была Память. Ему нужно было место, где хранятся товары, пользователи и транзакции. И не просто хранятся, а мгновенно находятся.

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

Раздел 4.2. Базы данных: Революция и Эволюция (1970 — 2010)

В 1960-х годах данные хранились в так называемых «Навигационных базах данных» (флагманом была система IBM IMS, созданная специально для лунной программы «Аполлон», чтобы отслеживать миллионы деталей ракеты).

Представьте, что ваши данные — это гигантское генеалогическое древо.

Ствол: «Покупатели».
Ветка: «Иванов».
Лист: «Заказ №5».
Подлист: «Утюг».

Чтобы найти «все заказы утюгов», программисту нужно было написать код, который физически «ползает» по всем веткам дерева, заглядывая в каждый лист. Бизнес-проблема: Данные были жестко прибиты к структуре. Если директор банка просил: «Перенесите дату заказа из "Листа" в "Ветку"», программистам приходилось переписывать все приложения банка. Это занимало месяцы. Мир данных был хрупким.

А. Эдгар Кодд: Человек, который ненавидел хаос

Математик в стране продавцов

Эдгар «Тед» Кодд был белой вороной в корпоративной культуре IBM. Оксфордский математик, во время Второй мировой войны он был пилотом британских ВВС (RAF), а в мирное время стал фанатиком логики. Работая в исследовательской лаборатории IBM в Сан-Хосе, он с ужасом смотрел на то, как клиенты тратят миллионы долларов на поддержку баз данных IMS. Он видел в этом не «хороший бизнес», а математическое уродство.

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

В ней он предлагает революционную идею:

«Хватит думать о том, как данные лежат на диске. Это проблема машины. Человек должен думать о данных как о Таблицах».

Революция SQL

Кодд придумал Реляционную модель (от слова Relation — отношение, математический термин для таблицы).

Таблицы: Данные лежат в плоских таблицах (строки и столбцы), понятных даже бухгалтеру.
Ключи: Таблицы связаны друг с другом через уникальные ID (Primary Key / Foreign Key).
Декларативность: Это был главный прорыв. Вам не нужно писать алгоритм поиска («Иди на диск А, возьми сектор 5...»). Вы просто описываете результат.

Для этого коллеги Кодда (Дон Чемберлин и Рэй Бойс) придумали язык SEQUEL (позже сокращенный до SQL, так как торговая марка была занята). Вместо 100 строк кода на COBOL менеджер пишет одну фразу: SELECT * FROM Orders WHERE Product = 'Iron'

Предательство IBM и Рождение Oracle

Это был прорыв. Инженеры IBM были в восторге. Но руководство IBM возненавидело эту идею. Бизнес-причина: IBM зарабатывала огромные деньги на продаже своей старой иерархической базы IMS.

Логика менеджеров: «Если мы выпустим новую, простую базу данных, клиенты перестанут покупать IMS. Мы каннибализируем собственную прибыль».

IBM положила статью Кодда «под сукно». Они намеренно тормозили разработку своего реляционного проекта (System R).

Но статью в журнале Communications of the ACM прочитал другой человек. Его звали Ларри Эллисон. Эллисон не был великим ученым. Он был недоучившимся студентом, плейбоем и авантюристом, который подрабатывал написанием софта для ЦРУ (секретный проект назывался «Oracle» — Оракул). Эллисон увидел статью Кодда и понял: «IBM сошла с ума. Они опубликовали чертежи печатного станка для денег, но сами не хотят его строить. Я сделаю это за них».

Эллисон с двумя друзьями (Бобом Майнером и Эдом Оутсом) основывает компанию Software Development Laboratories (позже Oracle). Они просто берут спецификации языка SQL из статей IBM и реализуют их.

Маркетинговый трюк: Их первая версия называлась Oracle v2. Версии 1 не существовало. Эллисон понимал: «Никто не купит версию 1.0, все будут ждать патчей».

Когда IBM очнулась и наконец выпустила свою базу DB2, было поздно. Ларри Эллисон уже продал Oracle всем: банкам, правительству и авиакомпаниям. Ирония: IBM придумала технологию, которая сделала Ларри Эллисона одним из богатейших людей мира, а саму IBM в итоге вытеснила с пьедестала рынка баз данных.

Б. PostgreSQL vs MySQL: Битва за Веб

В 90-е годы, с приходом Веба, спрос на базы данных взлетел вертикально. Каждому сайту, форуму, гостевой книге и магазину нужна была память. Но Oracle стоила $50,000 на процессор плюс $100,000 за поддержку. Для студента в общежитии или стартапа в гараже это было неподъемно. На сцену вышел Open Source. Началась великая «Война Дельфина и Слона» (по логотипам баз данных).

MySQL: Скорость Дельфина

В холодной Скандинавии (Швеция и Финляндия) работали два друга — Майкл «Монти» Видениус и Дэвид Аксмарк. Им нужна была база данных для веб-сайтов. Им было плевать на «академическую чистоту», сложные транзакции и банковскую надежность. Им нужна была Скорость. Веб должен летать.

Монти написал MySQL (назвав её в честь своей дочери Мю — My).

Философия: «Веб — это чтение». На сайте люди в 90% случаев читают новости и только в 10% пишут комментарии. Значит, база должна читать данные мгновенно.
Жертва: Ради скорости они выкинули всё «лишнее». В ранних версиях MySQL не было Транзакций (если сервер падал посередине записи, данные терялись) и Внешних ключей (можно было удалить пользователя, но оставить его комментарии висеть в пустоте).
Успех: "Серьезные" архитекторы смеялись над MySQL. Но веб-разработчики влюбились. MySQL стала буквой M в легендарном стеке LAMP (Linux, Apache, MySQL, PHP). На ней были построены Google (первые версии), Facebook, Wikipedia, ВКонтакте и WordPress.

PostgreSQL: Память Слона

В солнечном Университете Беркли профессор Майкл Стоунбрейкер (живая легенда, лауреат премии Тьюринга) создал Postgres (Post-Ingres).

Философия: «База данных не имеет права терять данные. Никогда. Даже если в сервер ударит молния».
Подход: Postgres была строгой, академической. Она поддерживала сложнейшие SQL-запросы, которые MySQL даже не снились.
Проблема: В 90-е и начале 2000-х она была медленной («тяжелой»). Она создавала отдельный процесс на каждое подключение. Для простого форума это было как ездить за хлебом на танке.

Эволюция и Поворот: Долгое время MySQL доминировала в вебе. Но в 2010 году случилась катастрофа для фанатов Open Source: Oracle купила Sun Microsystems, а вместе с ней получила права на MySQL. Сообщество испугалось: «Эллисон убьет бесплатного конкурента». Разработчики начали массово мигрировать на PostgreSQL. К тому времени закон Мура сделал железо мощным, и медлительность Postgres перестала быть проблемой. А её надежность и новые функции (например, поддержка JSON, что позволило ей конкурировать с NoSQL) сделали её золотым стандартом. Сегодня Postgres — это «Oracle для бедных» (в самом лучшем смысле), база по умолчанию для любого современного стартапа.

В. CAP-теорема: Фундаментальный барьер

К середине 2000-х Amazon и Google столкнулись с проблемой, которой не было в учебниках. SQL-базы данных (Oracle, MySQL, Postgres) прекрасно работают на одном мощном сервере (Vertical Scaling). Но что, если у вас 100 миллионов пользователей? Один сервер физически не справится. Вам нужно 1000 серверов, работающих как одно целое.

А SQL плохо масштабируется на 1000 серверов. Сложно делать JOIN (объединение таблиц), если половина таблицы «Заказы» лежит на сервере в Токио, а половина таблицы «Клиенты» — в Нью-Йорке. Скорость света слишком медленная для таких операций.

Теорема Брюера (CAP)

В 2000 году профессор Эрик Брюер формулирует теорему, которая становится законом физики для распределенных систем. В любой распределенной системе (работающей по сети) вы можете гарантировать одновременно только два свойства из трех:

C (Consistency) — Согласованность. Все пользователи в мире видят одни и те же данные в один и тот же момент времени. (Если я перевел деньги, вы сразу видите их на счету).
A (Availability) — Доступность. Система отвечает на запрос всегда, даже если часть серверов упала или перегружена. (Сайт не выдает ошибку 503).
P (Partition Tolerance) — Устойчивость к разделению. Система продолжает работать, даже если кабель между дата-центрами перерезан экскаватором, и серверы Азии не видят серверов Европы.

Жестокий выбор Веба: В глобальной сети кабели рвутся постоянно (P — это данность, её нельзя выключить). Значит, инженерам приходится выбирать только между C (Правдой) и A (Доступностью).

Банк выбирает C (Consistency + Partition Tolerance): Если связь между банкоматом и центром потеряна, банкомат откажется выдавать деньги (потеряет Availability). Лучше система будет недоступна, чем допустит ошибку в балансе.
Amazon/Facebook выбирает A (Availability + Partition Tolerance): Если связь потеряна, вы все равно можете добавить товар в корзину или поставить лайк.
- Риск: Ваш друг может не увидеть лайк сразу. В корзине может оказаться товар, которого уже нет на складе.
- Выгода: Магазин никогда не закрывается. Каждая секунда простоя Amazon стоит миллионы. Это называется Eventual Consistency (Согласованность в конечном счете) — «данные станут правдивыми, когда восстановится связь».

Рождение NoSQL

Чтобы обойти ограничения SQL и CAP-теоремы, родилось движение NoSQL (Not Only SQL). Разработчики Google и Amazon сказали: «К черту сложные таблицы, схемы и связи! Они тормозят нас. Давайте хранить данные тупо, зато быстро и на 1000 серверах».

Amazon DynamoDB: Ключ-Значение. Создана для того, чтобы «Корзина покупок» работала всегда, даже в Черную пятницу, даже если половина дата-центра сгорела. Опубликованный Amazon документ «Dynamo Paper» стал библией NoSQL.
Cassandra (рождена в Facebook): Колоночная база. Создана Авинашем Лакшманом для функции Inbox Search в Facebook. Ей нужно было хранить миллиарды сообщений. У неё нет «главного» сервера (Masterless). Убейте половину кластера — она не заметит.
MongoDB: Документная база. Хранит данные как JSON-файлы.
- Сюжет: Стартапы полюбили её за гибкость. Сегодня у пользователя есть поле «Имя», завтра появилось поле «Аватарка». В SQL для этого нужно менять структуру всей таблицы (останавливать базу). В Mongo вы просто кидаете новый JSON. Это стало стандартом для быстрой разработки.

Итог раздела 4.2

Эволюция баз данных — это история компромиссов между порядком и хаосом.

Кодд дал нам Порядок (SQL), победив хаос файлов.
Эллисон (Oracle) показал, что Порядок стоит дорого.
Open Source (MySQL/Postgres) сделал Порядок бесплатным.
NoSQL пожертвовал Порядком ради Масштаба Google и Amazon.

Теперь у нас есть браузеры, чтобы смотреть, и базы данных, чтобы помнить. Но как управлять этими гигантскими системами? Не вручную же. В следующем разделе мы узнаем, как финский студент в своей спальне написал код, который уничтожил монополию Microsoft и стал фундаментом всего современного облака. Речь пойдет о Linux.