Blob и объектное хранилище

Три формы хранения: блок, файл, объект

Через десять минут ты поймёшь, почему блобы в базе ломаются структурно, какая из трёх форм хранения это решает — и что отвечать, когда кто-то предлагает грузить файлы прямо в Postgres.

Хранение бывает в трёх абстракциях, и они не взаимозаменяемы:

• Блочное хранилище (AWS EBS, сырой SSD/том) — отдаёт сырые блоки фиксированного размера; ОС кладёт сверху файловую систему. Цепляется к одной машине за раз, низкая задержка, на нём живут файлы данных твоей базы. Думай «диск».
• Файловое хранилище (NFS, AWS EFS) — общая иерархическая файловая система (каталоги, пути, POSIX-семантика), которую несколько машин монтируют разом. Думай «сетевой диск».
• Объектное хранилище (AWS S3, Cloudflare R2, Google Cloud Storage) — плоское пространство имён объектов: каждый — непрозрачный блоб плюс метаданные, адресуемый ключом (строкой вроде users/42/avatar.jpg), читается и пишется по HTTP. Нет файловой системы, нет частичной правки на месте — ты PUT-ишь объект целиком и GET-ишь объект целиком (или диапазон байтов). Думай «бесконечно большое, долговечное HTTP key-value хранилище для файлов».

Определяющее свойство объектного хранилища — оно не привязано к машине. Это сервис, который ты вызываешь по сети, он масштабируется до практически безграничной ёмкости, и провайдер сам реплицирует каждый объект по множеству дисков и площадок. Ровно это делает его правильным домом для пользовательских загрузок, логов, бэкапов, артефактов сборки и статики — «больших, в основном неизменяемых байтов» системы. Когда видишь вопрос «где хранить эти файлы?», блок, файл и объект дают три совершенно разных ответа — и выбор не того варианта приводит ровно к инженеру из вступления.

Почему блобы никогда не кладут в базу

Ошибка из вступления — одна из самых частых в junior backend-дизайне, и причины её провала структурны, а не случайны:

• Бэкапы и восстановления раздуваются. Бэкап базы теперь включает каждый байт каждого файла. Схема в 5 ГБ становится бэкапом в 5 ТБ, восстановление длится часами, а point-in-time recovery становится непрактичным — ровно когда он нужен больше всего.
• Буфер-кеш отравлен. База кеширует горячие страницы в RAM, чтобы запросы были быстрыми. Крупные блобы вытесняют страницы индекса и строк, которые реально важны, так что твои структурированные запросы тормозят, потому что кеш забит байтами картинок, читаемыми один раз.
• Раздувание репликации и WAL. Каждый insert/update гонит блоб в поток репликации, взвинчивая лаг и трафик. Картинка в мегабайт становится мегабайтом WAL (write-ahead log — журнал предзаписи, хранит каждое изменение перед применением) на запись.
• Голодание пула соединений. Стриминг крупного блоба держит драгоценное соединение к БД на всю передачу; горстка параллельных скачиваний исчерпывает пул (вспомни 04-data-distribution — stateful-уровень там, где масштабирование болит).

Правило прямое: базы — для маленьких, структурированных, часто запрашиваемых данных; объектные хранилища — для крупных непрозрачных байтов. Их смешение делает базу плохой в её работе. Немногие исключения (крошечные блобы до нескольких КБ или настоящая нужда в транзакционной согласованности строки и байтов) реальны, но узки — и даже тогда сначала измеряют.

Долговечный паттерн: метаданные в БД, байты в объектном хранилище

Паттерн, к которому сходится каждая зрелая система, чисто разделяет две вещи. Байты живут в объектном хранилище под ключом. Метаданные — владелец, имя файла, content-type, размер, ключ объекта, метка времени загрузки, поле status — живут маленькой строкой в твоей реляционной базе, где их дёшево запрашивать, джойнить и проверять права. Строка указывает на объект; она его не содержит.

Это даёт лучшее из обоих: можно гнать SELECT * FROM files WHERE owner_id = 42 ORDER BY created_at по быстрой индексированной таблице, а потом вручить клиенту ключ объекта, чтобы он забрал байты напрямую. Твой запрос «покажи мои фото» не касается ни единого байта картинки. Контроль доступа, поиск и связи живут в базе, где им место; твои терабайты байтов живут там, где место терабайтам.

Долговечность против доступности: разные «девятки»

Объектные хранилища рекламируют зашкаливающую долговечность (durability) — S3 спроектирован на 99,999999999% (одиннадцать девяток) годовой долговечности объектов. Люди путают это с доступностью (availability), но это разные гарантии о разных сбоях:

• Долговечность — вероятность того, что твои байты всё ещё существуют и не повреждены — провайдер достигает её, реплицируя каждый объект по множеству дисков и площадок (идея из 04-data-distribution/01-replication, применённая к байтам). Одиннадцать девяток означают, что статистически ты потеряешь один объект из десятков миллионов за миллионы лет.
• Доступность — вероятность того, что ты достанешь байты прямо сейчас — обычно число пониже (например, ~99,9%), потому что сбой региона может сделать совершенно долговечные данные временно недостижимыми.

Следствие для дизайна: долговечность защищает от потери данных; она не защищает от падения региона. Если тебе нужно читать байты во время сбоя региона, нужна межрегиональная репликация поверх встроенной долговечности — отдельный платный выбор. Не читай «одиннадцать девяток» как «всегда достижимо».

Lifecycle и тиринг: платить меньше за холодные байты

Не все байты одинаково горячи. Фото смотрят постоянно первую неделю, потом почти никогда; лог запрашивают месяц, потом держат лишь ради комплаенса. Объектные хранилища выставляют классы хранения (storage classes) в разных точках цена/задержка — горячий стандартный тир, тиры нечастого доступа и глубокие холодные архивные тиры, которые куда дешевле за ГБ, но берут больше (и добавляют задержку, иногда минуты или часы) за извлечение. Lifecycle-политика автоматизирует переезд: «объекты старше 30 дней → нечастый доступ; старше 365 дней → архив; старше 7 лет → удалить». Ты объявляешь правило один раз, и провайдер двигает байты между тирами по расписанию, так что стоимость следует за тем, насколько данные реально холодны. Senior-ход — задавать lifecycle-правила на этапе дизайна: хранилище, которое только дорожает, — медленная течь, а сюрпризы извлечения из архива («нам нужны эти 2 ТБ сегодня») — провал планирования, а не платформы.