Три подхода к хранению: в чём разница и где обычно теряют деньги
Представьте простую ситуацию: вам нужно где-то хранить данные. Не абстрактные “данные”, а вполне жизненные вещи — фото с корпоративов, видео с презентаций, документы, выгрузки, бэкапы, логи, какие-то рабочие файлы команды. Сначала кажется, что задача одна: “положить и чтобы не пропало”.
А потом внезапно выясняется, что одни файлы должны открываться мгновенно, другие — просто лежать годами под архив, третьи — быть доступны сразу нескольким людям и сервисам одновременно, а четвёртые — использоваться приложением так, будто это обычный диск. И вот в этот момент “хранилище” перестаёт быть одной кнопкой и превращается в выбор подхода.
В облаке таких подходов обычно три — и они отличаются не названием, а тем, как именно к данным обращаются.
- Block Storage — это облачный “диск”. Его подключают к виртуальной машине почти так же, как вы подключили бы SSD к серверу. Приложение видит файловую систему и работает с данными на низком уровне — быстро и предсказуемо. Поэтому block выбирают там, где важны задержки и производительность: базы данных, транзакционные нагрузки, активные сервисы.
- File Storage — это “общая папка по сети”. Один файловый ресурс, к которому могут подключаться сразу несколько машин или приложений. Это удобно, когда нужно совместное использование: общий каталог для команды, папка с медиа, пользовательские загрузки, данные, которые должны видеть сразу несколько сервисов.
- Object Storage — это “склад объектов”. Там нет привычного “диска” в голове приложения: файлы хранятся как объекты с метаданными и доступны через API. Зато object storage обычно выигрывает в масштабе, долговечности и цене хранения. Это типичный дом для бэкапов, архивов, логов, медиа, больших датасетов и статического контента.
А теперь самое важное: где тут обычно теряют деньги.
- Первая ошибка — складывать всё в самый “привычный” вариант. Например, хранить бэкапы, медиа и архив на быстром block-диске просто потому, что “это же диск”. В итоге вы платите за производительность, которая почти не используется.
- Вторая ошибка — пытаться сделать “универсальную общую папку” и засунуть всё в file storage. Это удобно для совместного доступа, но не всегда выгодно и не всегда хорошо подходит под нагрузки вроде баз данных или частых мелких операций.
- Третья ошибка — ожидать от object storage поведения обычной файловой системы. Он идеален как хранилище объектов, но не создан для сценариев, где приложение хочет работать “как с диском”: постоянно дописывать кусочки, переименовывать, делать тысячи мелких операций в секунду.
Поэтому правильный выбор начинается не с “что дешевле”, а с вопроса: как ваши данные будут использоваться — как диск для приложения, как общая папка для многих участников или как масштабируемое хранилище объектов.
Дальше разберём каждый вариант отдельно. Начнём с Block Storage: почему его выбирают для VM и баз данных, и где он реально нужен, а где просто сжигает бюджет.
Block Storage: быстрый “диск” для VM, баз данных и нагрузок с IOPS
Block Storage проще всего воспринимать как обычный диск, только облачный. Вы “подключаете” его к виртуальной машине, форматируете, создаёте файловую систему — и дальше приложение работает так, будто это локальный SSD. Поэтому block storage обычно становится выбором по умолчанию, когда нужно хранение для VM, баз данных и всего, что любит предсказуемую скорость.
Почему именно он? Потому что block — это про низкий уровень доступа: чтение и запись блоками, понятное поведение, хорошая производительность и возможность тонко управлять характеристиками. Там, где приложению важно быстро читать и писать небольшие куски данных, а задержки должны быть минимальными, block чувствует себя уверенно.
В реальной жизни это выглядит так:
- Виртуальная машина должна где-то хранить операционную систему, приложения и данные — и block выступает как основной диск.
- База данных (особенно транзакционная) постоянно читает и пишет: индексы, журналы, таблицы. Ей нужен диск, который не “плывёт” по задержкам.
- Сервисы с высокой нагрузкой на ввод-вывод — например, очереди, поисковые движки, системы логирования — часто упираются не в CPU, а именно в I/O.
Здесь к месту два слова, которые часто встречаются в описаниях — IOPS и задержки. IOPS — это количество операций ввода-вывода в секунду. В переводе: насколько хорошо диск выдерживает множество мелких чтений/записей. Для баз и активных приложений это часто важнее, чем “скорость копирования одного большого файла”.
При этом block storage не обязательно “всегда быстрый” сам по себе. В облаке производительность часто выбирается классом диска и настройками: где-то вы покупаете больше IOPS, где-то — больше пропускную способность, где-то — баланс “серединка”. И вот тут начинается самая частая ошибка: люди платят за дорогой класс диска просто потому, что “лучше взять с запасом”, хотя их нагрузка вообще не упирается в диск.
Когда нужен именно Block, а когда он просто сжигает бюджет
Block storage становится идеальным выбором, когда приложению нужен “настоящий диск” с предсказуемым поведением. Самый частый признак — много мелких операций чтения/записи и чувствительность к задержкам. Базы данных, поисковые движки, очереди, сервисы с активной записью логов — всё это обычно чувствует себя лучше на block, потому что ему важна стабильная производительность на уровне I/O.
Ещё один хороший повод выбрать block — когда у вас приложение устроено “по-старому” и ожидает именно файловую систему: оно пишет временные файлы, хранит локальные состояния, работает с файлами как с частью своего жизненного цикла. В таких сценариях block — самый прямой и понятный путь, без попыток “натянуть” объектное хранилище на роль диска.
Но есть и обратная сторона: block довольно легко превращается в дорогую привычку.
- Типичный “слив бюджета” выглядит так: команда выбирает быстрый block-диск “с запасом”, а потом складывает на него всё подряд — бэкапы, архивы, медиа, выгрузки, старые логи. В итоге платят за высокие IOPS и низкие задержки… хотя эти данные почти никто не трогает. Для таких вещей block — просто самый дорогой шкаф для коробок, которые вы открываете раз в год.
- Вторая ловушка — хранить на block данные, которые нужно раздавать многим потребителям или хранить в масштабе. Например, коллекцию фотографий, видео, файлы для скачивания, датасеты. С точки зрения бизнеса это обычно “контент”, а не “диск для приложения”. И для такого контента куда логичнее объектное хранилище: дешевле, проще масштабируется, удобнее интегрируется с доставкой через CDN.
- Третья ловушка — использовать block как способ “поделиться файлами” между несколькими машинами. Да, есть варианты совместного доступа, но это уже не базовый сценарий block. Если вам нужна общая папка для нескольких сервисов, чаще естественнее и проще выглядит file storage (ведь по сути мы делаем тот же file storage, только сами).
Если свести к простой логике: block — это про “быстрый диск” для конкретной нагрузки. Как только вы начинаете использовать его как универсальный склад, он почти всегда становится неоправданно дорогим.
File Storage: общая папка по сети для команд и приложений
Представим ситуацию из жизни: у вас небольшая команда, которая делает сайт и каталог товаров. Дизайнеры регулярно подкидывают новые баннеры и изображения, контент-менеджер обновляет описания, а приложение в фоне генерирует превью и складывает результаты туда же. И всем нужно одно и то же: чтобы файлы лежали в одном месте и были доступны сразу нескольким системам — без пересылок “скинь в чат”, без копий на каждом сервере и без вечной путаницы “а какая версия последняя”.
Вот для таких задач и существует File Storage.
По сути это общая папка по сети: один файловый ресурс, который можно примонтировать к нескольким виртуальным машинам или сервисам одновременно. Для приложений это выглядит привычно — как обычная файловая система с каталогами и файлами. Вы можете создавать папки, переименовывать, менять права доступа, хранить структуру “как людям удобно”. И главное — несколько участников (людей или сервисов) видят одну и ту же реальность.
Где file storage обычно раскрывается лучше всего:
- Когда несколько экземпляров приложения должны видеть одни и те же файлы (например, пользовательские загрузки);
- Когда один сервис кладёт результаты обработки, а другой тут же их забирает (превью, отчёты, выгрузки);
- Когда команде нужна “рабочая папка”, которую видят и люди, и системы (контент, медиатека, документы проекта).
Но важно понимать, за что вы платите. File storage покупают не ради максимальных цифр производительности, а ради удобного совместного доступа. Он может быть быстрым, но если ваша задача — база данных с большим количеством мелких операций и очень чувствительными задержками, block обычно будет предсказуемее.
И ещё один момент, который часто всплывает уже после запуска: общая папка — это магнит. Как только она появляется, туда начинают складывать всё подряд. Сначала удобно. Потом внезапно оказывается, что рядом с актуальными рабочими файлами лежат старые архивы за три года, дубли, временные выгрузки и “на всякий случай не удаляем”. Стоимость растёт, структура превращается в лабиринт, а права доступа — в коллекцию случайных решений.
Поэтому file storage обычно работает лучше всего, когда у него есть ясная роль: “общее рабочее пространство” или “shared volume под конкретный сценарий”, а всё, что нужно просто хранить долго и дёшево, уезжает в объектное хранилище.
И вот как раз к нему мы сейчас и переходим: Object Storage — самый “другой” формат из трёх. Он не притворяется диском и не пытается быть папкой, зато почти всегда выигрывает в масштабе, цене и долговечности.
Object Storage: масштабируемое хранилище для файлов, бэкапов и архива
Чтобы было проще всё освоить – снова прибегнем к примерам. Представим, что у вашей компании начинается “контентная взрослая жизнь”. За пару месяцев накапливаются тысячи фотографий товаров, видео-обзоры, рекламные креативы, исходники, выгрузки аналитики, логи, бэкапы. И в какой-то момент становится очевидно: хранить это как “файлы на сервере” — путь в бесконечную уборку. Где-то кончается место, где-то всё разваливается по папкам, где-то растёт стоимость, а где-то ещё и страшно трогать: вдруг удалишь не то.
Вот здесь и появляется Object Storage — хранилище, которое не пытается быть диском или сетевой папкой. Оно работает иначе: данные хранятся как объекты (файл + метаданные), которые лежат в “контейнере” (часто его называют bucket). Доступ к ним идёт не через “смонтировали диск и пошли по папкам”, а через API: положили объект, получили его по ключу/ссылке, удалили, переложили, выдали доступ.
Звучит чуть менее привычно, зато даёт три сильные вещи, ради которых object storage и любят.
Во-первых, масштаб. Объектное хранилище рассчитано на большие объёмы и огромное количество файлов. Вам не нужно “докупать диск” и думать, как разнести данные по десятку серверов. Вы просто складываете объекты — и система переваривает рост.
Во-вторых, долговечность. Object storage часто используют как “надёжный сейф”: туда отправляют бэкапы, архивы, исходники, логи, то есть всё, что должно жить долго и не пропадать из-за случайной проблемы с одной машиной или диском.
В-третьих, экономика. Для данных, которые не требуют высокой частоты мелких операций (как у баз данных), object storage обычно оказывается дешевле и логичнее. Особенно если вы используете разные классы хранения: “горячее” для того, что часто читается, “холодное” для редких обращений, “архив” для того, что почти никогда не открывается.
И теперь важная честность: object storage не пытается заменить блоковый диск. Если приложение ожидает POSIX-файловую систему, постоянные мелкие записи и “переименовать/дописать кусочек/заблокировать файл” — объектное хранилище будет ощущаться неудобно или дорого по запросам. Существуют всякие истории типа S3FS для доступа к объектному хранилищу как к файловой системе, но такое использовать - не самый лучший вариант. Его сильная сторона — хранить и отдавать файлы как объекты: надёжно, массово и с понятной моделью доступа.
На практике типовой набор задач для object storage выглядит так:
- Медиа (фото/видео), статический контент, файлы для раздачи;
- Бэкапы, архивы, долгосрочное хранение;
- Логи, выгрузки, датасеты, “сырые” данные для аналитики;
- Промежуточные результаты обработки (когда сервисы обмениваются файлами через объектное хранилище).
И раз уж мы заговорили про экономику, дальше логично перейти к самому “денежному” месту: классы хранения и жизненный цикл данных. Именно там часто прячется основная выгода — или основной перерасход, если всё держать в “горячем” классе просто по привычке.
Горячее, холодное, архив: как классы хранения влияют на цену
В object storage деньги почти никогда не заканчиваются “внезапно”. Они заканчиваются из-за мелкой привычки: всё хранить как будто данные нужны каждую минуту. А на практике большая часть файлов живёт по одному сценарию — сначала активно используется, потом используется редко, а потом просто “лежит, потому что удалять страшно”.
И вот под этот жизненный цикл как раз придуманы классы хранения.
Если говорить без привязки к брендам, логика примерно такая:
- Горячее хранение — для данных, к которым вы обращаетесь часто и хотите быстрый доступ без сюрпризов. Типичный пример: изображения товаров и актуальные медиа на сайте, свежие выгрузки, данные для текущей обработки.
- Холодное хранение — для того, что иногда нужно достать, но не каждый день. Например, старые отчёты, медиа за прошлые кампании, бэкапы, которые нужны только “если что”.
- Архив — для данных, которые почти никогда не трогают. Это “положили и забыли”, но при необходимости можно достать — просто обычно это не мгновенно и с другими условиями по стоимости.
Где здесь ловушка? В том, что цена — это не только “сколько стоит гигабайт”. Часто меняется и стоимость операций: сколько стоит записать, прочитать, перечислить объекты, сделать запросы. Плюс у холодных и архивных классов могут быть условия вроде минимального срока хранения или стоимости “доставания” данных. Поэтому если вы положили в архив то, что на самом деле читаете каждый день, вы не сэкономили — вы просто перенесли расходы в другое место.
Зато если вы настроили всё правильно, эффект ощущается очень быстро. Самая частая выигрышная схема выглядит так: активный контент живёт в горячем классе, через некоторое время автоматически переезжает в холодный, а через ещё какое-то время — в архив. В object storage это обычно реализуется правилами жизненного цикла: вы задаёте “через N дней переместить”, “через M дней архивировать”, “через K дней удалить” — и система сама это делает.
На примере магазина это выглядит очень жизненно. Фото товаров и актуальные баннеры должны быть “горячими”. А вот исходники прошлогодней кампании, старые выгрузки и бэкапы пятимесячной давности — почти точно не обязаны жить в том же классе, что и то, что работает прямо сейчас.
Итого: классы хранения — это способ платить меньше не за счёт “урезания надёжности”, а за счёт здравого соответствия: хранить горячие данные горячо, холодные — холодно, архив — в архиве.
Заключение
Если свести всё к одному: в облаке вы выбираете не “хранилище вообще”, а модель доступа к данным — и именно от неё зависит и удобство, и стоимость.
Block storage — это быстрый “диск” для задач, где важны задержки и стабильный ввод-вывод: виртуальные машины, базы данных, активные сервисы.
File storage — это общая папка по сети, когда файлы должны одновременно видеть несколько машин или приложений.
Object storage — это масштабируемый “склад”, где удобно и выгодно хранить большие объёмы файлов, бэкапы и архив, особенно если вы используете классы хранения и правила жизненного цикла.
Самый дорогой сценарий почти всегда один и тот же: выбрать “привычное” и начать складывать туда всё подряд. Самый выгодный — выбрать хранилище под реальный сценарий и честно разделить данные на активные и “пусть лежит”.Итог простой: правильный тип хранения редко делает проект “вау, быстрее в 10 раз”, зато очень часто делает его спокойнее, дешевле и проще в поддержке.
