Раздел 5.5. NoSQL и Big Data: Когда SQL сломался (2005 — 2015)

В период с 2005 по 2015 год Интернет пережил «подростковый возраст». Он перестал быть набором аккуратных библиотек и превратился в шумную, хаотичную вечеринку. Социальные сети, лайки, чекины, комментарии, логи сенсоров — данные лились рекой. И вдруг выяснилось, что старый добрый SQL, на котором держался мир 30 лет, стал узким местом. Он был слишком строгим, слишком медленным и слишком дорогим для новой реальности.

Это история о том, как инженеры восстали против диктатуры Таблиц и создали NoSQL (Not Only SQL).

Раздел 5.5. NoSQL и Big Data: Когда SQL сломался (2005 — 2015)

А. Дилемма масштаба: Смирительная рубашка SQL

Проблема строгой схемы (Schema Rigidity)

Представьте, что вы — инженер Facebook в 2008 году. У вас есть таблица Users на 500 миллионов строк. Вам приходит продукт-менеджер и говорит: «Мы запускаем новую фичу — "Отчество". Срочно добавь колонку MiddleName в таблицу пользователей».

В мире классического SQL (MySQL, Oracle, PostgreSQL того времени) это делается командой ALTER TABLE.

• На маленькой базе (интернет-магазин носков) это занимает миллисекунды.
• На таблице в 500 миллионов строк база данных говорит: «Окей, я должна физически переписать все 500 миллионов записей на диске, добавив в каждую пустое поле. Чтобы данные не разъехались, я блокирую таблицу на запись. Никто не может зарегистрироваться, никто не может обновить профиль, пока я не закончу».

На таком объеме это может занять 4–6 часов. Бизнес-вердикт: Остановить регистрацию в Facebook на 6 часов ради добавления колонки? Невозможно. Это потеря миллионов долларов и репутации. Стартапам нужна была гибкость: «Пиши что хочешь, разберемся потом».

Проблема Вертикального масштабирования

SQL-базы любят жить на одном сервере. Это гарантирует их надежность (ACID). Если база тормозит, вы покупаете сервер помощнее (Vertical Scaling). Но к 2008 году у Google и Facebook закончились «серверы помощнее». Они уперлись в физический потолок производительности процессоров Intel. Единственным выходом было размазать базу данных по тысяче дешевых серверов (Horizontal Scaling или Шардинг). А SQL ненавидит распределенность. Делать JOIN (объединение таблиц), когда одна таблица в Техасе, а другая в Ирландии — это техническое самоубийство из-за задержек сети.

Решение: Ломаем правила (ACID vs BASE)

Инженеры поняли: чтобы выжить под цунами данных, нужно отказаться от священных правил банковского софта — ACID (Атомарность, Согласованность, Изоляция, Долговечность). Они сказали: «К черту транзакции! К черту связи между таблицами! Нам нужна скорость записи и гибкость. Если один лайк из миллиона потеряется — никто не умрет».

Так родилась философия BASE (Basically Available, Soft state, Eventual consistency) — «Базовая доступность и согласованность в конечном счете». Началась эпоха NoSQL. Это был «Дикий Запад» баз данных.

Б. Зоопарк решений

Как только оковы SQL пали, появилось множество специализированных баз данных. Каждая решала свою узкую задачу, жертвуя чем-то другим.

1. Cassandra: Рожденная в аду Facebook

Сюжет: 2008 год. Facebook запускает новую функцию — Inbox Search (поиск по личным сообщениям). Им нужно хранить миллиарды входящих сообщений и позволять искать по ним мгновенно. MySQL не справляется с записью (диски перегреваются от количества операций ввода-вывода). Два инженера, Авинаш Лакшман (один из авторов Amazon Dynamo) и Прашант Малик, получают задачу: «Сделайте базу, которая никогда не падает и пишет с пулеметной скоростью».

Они создают Apache Cassandra.

• Вдохновение: Они взяли архитектуру распределения данных у Amazon (Dynamo) и модель данных у Google (BigTable). Получился «монстр Франкенштейна», который оказался бессмертным.

Техническая магия: Masterless Architecture В обычных базах (MySQL) есть Master (Главный), который пишет, и Slaves (Рабы), которые читают. Если Master умирает, наступает паника: система останавливается, чтобы выбрать нового главного. Сайт лежит 5–10 минут. У Cassandra нет главного. Все узлы равны (Peer-to-Peer).

• Серверы общаются через протокол Gossip (Сплетни). Каждую секунду сервер шепчет соседу: «Я жив, а вот сервер №5 что-то молчит, наверное, умер».
• Устойчивость: Вы можете зайти в дата-центр с дробовиком, расстрелять половину серверов, и Cassandra продолжит работать, просто перенаправив запросы на выжившие узлы.

Использование: Сегодня Apple хранит в Cassandra более 100 петабайт данных iCloud. Netflix хранит там историю ваших просмотров. Это идеальная база для записи (write-heavy).

2. MongoDB: Мечта стартапера

В 2007 году Дуайт Мерриман и Элиот Горовиц (бывшие основатели рекламного гиганта DoubleClick) строили новый стартап. И они задолбались. Каждый раз, когда им нужно было поменять что-то в приложении, им приходилось бороться с базой данных. Данные в коде (Java/Python) были Объектами (гибкими), а в базе — Таблицами (жесткими). Им приходилось писать кучу кода-переходника (ORM).

Они решили создать базу для разработчиков, а не для администраторов. Они назвали её MongoDB (от сленгового слова Humongous — огромный).

Техническая суть: JSON-документы Вместо таблиц MongoDB хранит Документы (в формате BSON/JSON).

• Вчера: { "name": "Vasya", "age": 20 }
• Сегодня: { "name": "Petya", "age": 25, "hobby": "lego", "avatar": "img.jpg" } В одной «коллекции» могут лежать документы с абсолютно разной структурой. Схемы нет (Schemaless).

Бизнес-эффект (MEAN Stack): MongoDB стала стандартом для стартапов. Вместе с Node.js она образовала стек MEAN (Mongo, Express, Angular, Node).

• Почему? Потому что JavaScript везде. Данные в браузере — JSON. Данные на сервере — JSON. Данные в базе — JSON. Не нужно ничего конвертировать. Это ускорило разработку (Time-to-Market) в разы.

Драма «Web Scale»: У MongoDB была плохая репутация среди инженеров. В ранних версиях (до 3.0) ради скорости она по умолчанию работала в режиме «Fire and Forget» (выстрелил и забыл). Драйвер говорил приложению «Сохранено!», даже не дождавшись подтверждения от жесткого диска. Хакеры смеялись над Mongo, создавая вирусные мультики про «Web Scale», где данные улетают в трубу /dev/null.

• Итог: MongoDB повзрослела, добавила транзакции, но стереотип «быстро, но ненадежно» остался в фольклоре. Тем не менее, скорость разработки победила страх потери данных для большинства стартапов.

3. Redis: Итальянский хакер и Скорость света

В 2009 году сицилийский разработчик Сальваторе Санфилиппо (известный под ником antirez) пытался запустить свой стартап в Италии — анализатор логов в реальном времени. MySQL не справлялась. Ему нужно было обновлять счетчики на странице в реальном времени для тысяч пользователей. Жесткий диск был слишком медленным физически (механическая головка не успевала двигаться).

Сальваторе подумал: «А зачем вообще писать на диск? Оперативная память (RAM) дешевеет. Давайте держать базу данных полностью в памяти!». Он написал Redis (Remote Dictionary Server).

Техническая суть: Redis — это не просто кэш (как Memcached). Это сервер структур данных. Обычная база умеет хранить только строки и числа. Redis умеет хранить:

• Списки (лента твитов).
• Множества (список друзей).
• Хэш-таблицы (профиль пользователя).
• Сортированные множества (таблица лидеров в игре).

И всё это работает в оперативной памяти. Время отклика — наносекунды.

Использование: Redis стал «швейцарским ножом» интернета.

• Twitter: Использует его для формирования вашей ленты (Timeline).
• Игровые компании: Используют для таблиц лидеров (Leaderboards).
• StackOverflow: Использует для кэширования ответов.
• Личность: Сальваторе долгое время разрабатывал Redis в одиночку, отказываясь превращать его в корпоративного монстра с платными функциями. Это сделало Redis «самой любимой базой данных» среди разработчиков 5 лет подряд (по опросам Stack Overflow).

Shutterstock

Explore

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

К 2015 году монополия SQL пала. Мы перешли от мышления «One Size Fits All» (Oracle для всего) к концепции Polyglot Persistence (Многоязычное хранение).

Современное приложение (например, Uber) устроено так:

1. Ваша корзина или текущая поездка лежит в Redis (нужна скорость).
2. Ваш каталог товаров или меню — в MongoDB (нужна гибкость).
3. Ваши лайки, логи и история поездок — в Cassandra (нужен бесконечный размер и бессмертие).
4. А ваши финансовые транзакции (оплата картой)... все еще лежат в PostgreSQL или Oracle (потому что с деньгами не шутят, и там нужен старый добрый ACID).

Инфраструктура готова. Данные собраны в огромные озера (Data Lakes). Но что с ними делать? Как найти смысл в петабайтах JSON-файлов? В финальном модуле мы подключим к этим данным Искусственный Интеллект.