Каждое утро Автор начинает с одного и того же ритуала: открывает мессенджер, проверяет ленту, заказывает кофе в приложении, смотрит баланс в банке. И каждый раз он ловит себя на мысли — за всем этим стоит какая-то невидимая магия. Миллионы лайков, тысячи заказов, сотни друзей в списке контактов — всё это не исчезает, не путается и находится за доли секунды.
Не в текстовых же файлах на диске это хранится, в самом деле.
Здравствуй, дорогой читатель! Сегодня Автор снимет завесу тайны и расскажет о программах, которые держат в порядке весь цифровой мир. О системах управления базами данных — СУБД. О том, как они появились, почему без них не работает ни один серьёзный сервис и как обычная коробка с рисунками помогла Илье, Алисе и Арине понять принципы хранения данных.
Внутри не будет сложных SQL-запросов или скучных схем. Будет история, аналогии и честный разбор того, что остаётся за кадром, когда вы ставите лайк.
От свалки файлов до космической скорости
1960-е: времена, когда данные лежали кучей
Представьте себе огромную комнату, где на полу валяются тысячи листков бумаги. На одних — имена клиентов, на других — их заказы, на третьих — адреса. Каждая новая программа-сотрудник приходила в эту комнату и складывала свои листки в свою кучу. Когда нужно было найти заказы Ивана, приходилось перерывать всё.
Это были файловые системы. Компьютеры хранили данные в обычных файлах — как текстовые документы на вашем рабочем столе. Но проблема была огромной: данные дублировались (адрес Ивана мог быть записан в трёх разных файлах), поиск занимал вечность, а если один файл обновляли, остальные об этом даже не узнавали.
По мнению Автора, это было похоже на попытку вести семейный бюджет, записывая траты на случайных клочках бумаги и разбрасывая их по квартире.
Конец 1960-х: первая структура — дерево от IBM
Кто-то догадался: «А давайте разложим всё как на дереве! Есть корень — например, "Клиенты". От него ветки — конкретные люди. У каждого человека свои веточки — заказы, адреса, телефоны».
Так появились иерархические СУБД. Самый известный пример — IMS от IBM. Работало быстро, но была беда: если вы вдруг решали, что у одного клиента может быть два телефона, приходилось перестраивать всё дерево. Гибкости — ноль.
1970-е: революция — таблицы и язык, который всё изменил
А потом пришёл гений по имени Эдгар Кодд. Он сидел и думал: «Почему данные должны быть деревом? Почему не таблицами?»
И предложил идею, которая взорвала мир: реляционные базы данных. Всё — в виде таблиц. Таблица «Пользователи», таблица «Заказы», таблица «Товары». Они связаны между собой, но каждая живёт своей жизнью. А для управления этим хозяйством придумали специальный язык — SQL (Structured Query Language).
Это было как изобретение алфавита после тысяч лет рисуночного письма. Любой разработчик мог написать: «Найди всех пользователей, которые заказали красные кроссовки за последний месяц», — и СУБД сама делала всю чёрную работу.
1980-е: коммерческий бум — Oracle, DB2, Microsoft SQL Server, PostgreSQL
Реляционные СУБД захватили мир. Банки, авиакомпании, склады — все переходили на таблицы. Появились гиганты вроде Oracle, IBM со своей DB2, Microsoft SQL Server. А позже — открытый PostgreSQL, который Автор особенно любит.
Эти системы умели главное: транзакции (операция «всё или ничего» — деньги списались и зачислились, и никак иначе), целостность (нельзя вставить заказ для несуществующего клиента) и безопасность (кто-то только читает, кто-то удаляет).
2000-е: интернет всё сломал (и это прекрасно)
А потом случился интернет в том виде, в котором мы его знаем. Amazon, Google, Facebook — их базы данных росли как на дрожжах. Миллиарды записей. Тысячи запросов в секунду. И классические реляционные СУБД начали задыхаться.
Им нужно было масштабироваться «вширь» — добавлять сотни дешёвых серверов вместо одного супердорогого. А традиционные SQL-базы этого не любили.
Так родились NoSQL-базы данных. Они жертвовали строгими правилами (чуть-чуть) ради бешеной скорости и горизонтального масштабирования. Появились разные виды: «ключ-значение» (быстро как молния), «документоориентированные» (хранят данные в JSON-документах), «графовые» (для социальных сетей), «колоночные» (для аналитики).
2010-е и дальше: каждый выбирает по себе
Сегодня у нас зоопарк технологий. Есть NewSQL (сочетают удобство SQL с масштабируемостью NoSQL), облачные СУБД (Amazon RDS, Google Spanner), базы данных для тайм-серий (для умных домов и метрик с датчиков). Автор радуется: теперь для каждой задачи можно выбрать идеальный инструмент.
Как это работает — взгляд через коробку с рисунками
Автор обещал простые аналогии. Давайте заглянем в гости к Илье, Алисе и Арине.
У них есть большая коробка, куда они складывают свои рисунки, записки и фотографии. Сначала они просто кидают всё в кучу. Это файловая система. Чтобы найти рисунок с домиком, приходится перерыть всё.
Илья предлагает: «Давайте разложим всё по папкам: "Рисунки", "Письма", "Фотки". А внутри каждой папки — по алфавиту, как в школе учат».
Это уже база данных. Данные организованы.
Но СУБД — это не просто папки. Это когда Илья становится диспетчером со строгими правилами:
- Права доступа. Алиса хочет взять рисунок. Илья говорит: «Ты можешь только смотреть, но не вынимать. А вот Илья может и смотреть, и класть новые, и удалять старые».
- Конфликты. Если Алиса и Илья одновременно тянутся к одному рисунку, Илья (как строгая СУБД) говорит: «Стоп! Сначала ты, потом ты». В мире IT это называется блокировками.
- Резервные копии. Арина случайно порвала рисунок. Илья не паникует. Он идёт к специальному «резервному шкафу» и достаёт копию, которую сделал вчера вечером.
- Индексы. Илья берёт листок бумаги и пишет: «"Домик" — в папке "Рисунки", третья страница. "Котик" — там же, седьмая». Это индекс. Теперь, когда Алиса просит найти рисунок котика, Илья не перебирает всё — он смотрит в список и сразу идёт в нужное место.
- Целостность. Алиса кричит: «Я хочу положить рисунок в папку "Фотки"!» Илья проверяет: «Это рисунок, а не фотография. Нельзя. Нарушаются правила».
В мире компьютеров СУБД — это программа, которая делает всё то же самое. Вы просто говорите ей на языке SQL: «Найди все заказы пользователя с id=42», и она лезет в свои индексы, блокировки, проверки и за миллисекунду выдаёт ответ. Вы не думаете о том, как именно она это делает. Вы просто получаете результат.
Какие бывают СУБД и где они живут
Автор перечислит основные виды, чтобы вы могли блеснуть познаниями на вечеринке (или хотя бы понять, почему Instagram не падает каждые пять минут).
Реляционные
Как устроены: данные в таблицах со строками и столбцами. Как огромный Excel, только умнее.
Строгие правила: нельзя положить в столбец «цена» текст, нельзя сослаться на несуществующего пользователя.
Примеры: PostgreSQL, MySQL, Microsoft SQL Server, Oracle.
Где встречаются: банки, бухгалтерия, интернет-магазины, CRM-системы. Везде, где важна точность и связи между данными.
На самом деле выше описан идеальный мир, но автор работал на языке SQL не только с реляционными СУБД. И в реляционных СУБД может не быть строгих правил. И не всегда они были схемовыми. Но сейчас это не так важно. Потому что эти примеры либо про такие нагрузки, о которых страшно даже подумать, либо эти СУБД не получили признания и уже мертвы. Самое важное, это то, что одна запись намертво связана с другой записью - это и есть реляция или отношение, связь.
Документоориентированные
Как устроены: хранят документы в формате JSON — такой удобный текстовый формат с фигурными скобками. Документ может выглядеть как угодно, строгой схемы нет.
Примеры: MongoDB (королева этого жанра).
Где встречаются: ленты новостей, каталоги товаров (где у разных товаров разный набор характеристик), логи серверов.
Ключ-значение (Key-Value)
Как устроены: максимально просто. По ключу (например, «user_42_session») получаете значение (например, «active, time=14:00»).
Скорость: молниеносная.
Примеры: Redis, MemCached.
Где встречаются: сессии пользователей, корзины товаров в онлайне, таймеры, переводы.
Колоночные
Как устроены: хранят данные не по строкам, а по столбцам. Это позволяет бешено быстро агрегировать миллионы записей.
Примеры: ClickHouse.
Где встречаются: хранилища данных для бизнес-аналитики. Когда нужно посчитать «сумму всех продаж за год по каждому товару» по миллиарду записей за секунду.
Графовые
Как устроены: узлы (люди, товары, места) и рёбра (связи между ними). «Илья дружит с Алисой» — это ребро.
Примеры: Neo4j.
Где встречаются: Автор ни разу не видел успешного применения этого типа СУБД. Но тот же Neo4j живет и развивается, значит спрос есть.
Есть и другие виды: объектные, временные (для биржевых котировок), пространственные (для карт). Но пять выше — самые популярные.
Последнее время еще набирают популярность Map-Reduce. Их назначение - это обработка очень большого объема данных, например, для обучения ИИ моделей. Автор бы не назвал их СУБД - это нечто большее, но помнить о них надо.
Зачем всё это? Почему нельзя просто файлами?
Автор слышит вопрос: «Ну а если я сам напишу программу, которая будет искать в файлах? Зачем мне СУБД?»
Ответ: попробуйте, и вы быстро поймёте, что без СУБД вы:
- Упретесь в скорость. СУБД строит индексы. Без индекса поиск среди миллиарда записей займёт минуты. С индексом — миллисекунды. Это разница между «кофе остыл» и «кофе ещё не налили».
- Потеряете данные при сбое. СУБД гарантирует транзакции. Если вы переводите деньги и в середине операции отключили свет, СУБД откатится к состоянию «до перевода». Ваша самодельная файловая система оставит половинчатый результат — деньги списались, но не зачислились. И клиент будет в ярости.
- Не справитесь с толпой пользователей. Сотни тысяч человек одновременно читают и пишут. СУБД управляет блокировками, очередями, изоляцией. Вы сойдёте с ума, пытаясь повторить это вручную.
- Нарушите целостность. СУБД не даст вставить заказ для несуществующего пользователя (внешний ключ) или поставить отрицательную цену (ограничение CHECK). Вы можете забыть написать такую проверку. СУБД — нет.
- Устанете настраивать безопасность. В СУБД вы одной командой даёте доступ только на чтение по конкретной таблице. В файловой системе это квест с правами доступа на уровне папок.
- Забудете про резервное копирование. СУБД умеет делать бэкапы на лету, не останавливая работу. Попробуйте скопировать папку с файлами, пока в неё пишут тысяча пользователей.
Заключение: мир держится на СУБД
Автор подводит черту. СУБД — это невидимый герой каждого вашего цифрового действия.
Когда вы ставите лайк — СУБД его записывает. Когда ищете дешёвые авиабилеты — СУБД за миллисекунду перебирает миллионы записей. Когда заказываете пиццу — СУБД проверяет, есть ли у вас деньги на карте, есть ли пицца в наличии, и не даёт двум курьерам взять последнюю одновременно.
Обычный пользователь не видит СУБД. И это лучший комплимент для неё — всё работает так быстро и надёжно, что вы даже не задумываетесь, как это происходит.
Подписывайтесь на канал Автора. В следующих выпусках: что такое индексы на самом деле, почему транзакции — это магия и как базы данных не теряют ваши фотографии даже при апокалипсисе. Без заумностей, с Алисой, Ильёй и Ариной.
UPD
Автор обещал честно назвать термины, которые остались за кадром, но важны для понимания. Вот они, кратко и по делу:
- Нормализация — способ организации данных в реляционных базах, чтобы избежать дублирования. В идеальной нормализованной базе адрес пользователя хранится один раз, а не в каждой таблице с его заказами.
- Денормализация — обратный процесс: специально добавляем дублирование ради скорости, чтобы не делать лишние соединения таблиц.
- ACID — четыре священных свойства любой серьёзной СУБД:
Атомарность — операция либо выполняется целиком, либо не выполняется вообще (как перевод денег).
Согласованность — данные после операции остаются в правильном состоянии (нет заказа без клиента).
Изоляция — параллельные операции не мешают друг другу (два человека не обновляют одну запись одновременно в хаотичном порядке).
Долговечность — если данные записаны, они не пропадут даже при выключении питания. - Шардирование — разбиение огромной базы на части и раскидывание этих частей по разным серверам. Когда данных столько, что один сервер не справляется.
- Репликация — постоянное копирование данных с одного сервера на другой. Чтобы если один упадёт, второй сразу подхватил.
- Кластерный индекс — особый тип индекса, который определяет физический порядок хранения данных в таблице. Как если бы вы разложили книги на полке строго по алфавиту, а не в произвольном порядке.
Эти термины Автор обязательно разберёт в следующих выпусках. А пока — пользуйтесь благами цивилизации и ставьте лайки, зная, что где-то глубоко в дата-центре СУБД кланяется вам за это.