Объектное хранилище против файловой системы: когда что

MAATRIX

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

Две разные модели хранения данных

Файловая система — это иерархия: корень, директории, вложенные директории, файлы с именами внутри них. Путь к файлу — это навигация по дереву: /var/www/app/uploads/2026/09/photo.jpg. Операционная система хранит эту иерархию в виде метаданных (inode на Linux, MFT на Windows) и даёт приложениям низкоуровневые примитивы: открыть файл дескриптором, прочитать N байт со смещения X, записать в середину файла, дозаписать в конец, удалить, переименовать. Это API, спроектированный для локального доступа — процесс на той же машине, что и диск, работает с байтами напрямую через системные вызовы вроде open(), read(), pwrite(), fsync().

Объектное хранилище устроено иначе. Пространство имён плоское — нет вложенных директорий в классическом смысле, хотя многие клиенты и консоли (включая MinIO) рисуют псевдо-папки, просто разбивая ключ объекта по символу / для удобства навигации. На деле объект «bucket-name/2026/09/photo.jpg» — это просто строка-ключ в одном общем пространстве, а не путь по дереву каталогов. Доступ идёт не через файловые системные вызовы, а через HTTP API: GET /bucket/key отдаёт объект целиком, PUT /bucket/key кладёт его целиком, DELETE /bucket/key удаляет. Это протокол, спроектированный для распределённого доступа по сети — с самого начала расчёт был на то, что клиент и хранилище физически разнесены, могут быть в разных дата-центрах, и обращение идёт через привычные HTTP-примитивы, которые одинаково работают что из соседней стойки, что через интернет.

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

Объект как неделимая единица — что это значит на практике

Ключевое поведенческое отличие: в файловой системе вы можете открыть файл и переписать 100 байт где-то в середине, не трогая остальное. Базы данных этим активно пользуются — PostgreSQL и MySQL дозаписывают WAL-журнал, обновляют страницы данных на месте, делают fsync конкретных блоков. Это возможно именно потому, что файл — это адресуемая последовательность байт со смещениями.

В классической модели объектного хранилища частичной перезаписи нет. Чтобы изменить объект, вы обычно загружаете его целиком заново — новый PUT полностью заменяет старую версию (в реализациях с версионированием, включая MinIO, старая версия при этом не исчезает бесследно, а становится предыдущей версией объекта). Некоторые S3-совместимые реализации поддерживают multipart-upload, который режет один большой объект на части для параллельной загрузки — но с точки зрения клиента это по-прежнему одна логическая операция «загрузить объект», а не произвольная точечная правка байт внутри уже существующего объекта.

Это не недостаток, а следствие архитектуры: раз объекты реплицируются между узлами и должны оставаться консистентными в распределённой системе, проще гарантировать целостность, оперируя неделимыми единицами, чем синхронизировать частичные патчи по сети между узлами. Плата за эту простоту — не нужно проектировать приложение так, будто оно правит байты в объекте на месте.

Метаданные и масштабирование — то, что объектное хранилище даёт взамен

В обмен на потерю точечной перезаписи объектное хранилище даёт две вещи, которых в файловой системе нет по умолчанию.

Во-первых, метаданные на уровне объекта — произвольные пары ключ-значение, прикреплённые к каждому объекту (Content-Type, кастомные теги, дата, чек-сумма ETag), которые можно читать и фильтровать без скачивания самого объекта. Файловая система тоже хранит метаданные (время изменения, права доступа), но расширять их произвольными полями штатными средствами неудобно.

Во-вторых, горизонтальная масштабируемость, встроенная в саму модель. Файловая система по своей природе привязана к конкретному диску или локальному RAID-массиву на одной машине (сетевые файловые системы вроде NFS — отдельный случай с собственными компромиссами). Объектное хранилище изначально проектировалось так, что кластер узлов может расти добавлением нод, объекты распределяются между ними, и клиент не знает и не должен знать, на каком физическом диске лежит конкретный объект — он просто обращается по ключу через API, а хранилище само решает маршрутизацию. Это фундаментально проще масштабировать вширь до сотен терабайт и петабайт, чем наращивать один файловый сервер.

Когда объектное хранилище — правильный выбор

Объектное хранилище хорошо ложится на задачи с двумя характеристиками одновременно: большой объём слабо структурированных данных и редкое изменение уже записанного.

• Медиафайлы — фото, видео, аватары пользователей. Загрузили один раз, дальше только читают, изменение — это загрузка новой версии, а не правка байт внутри.
• Бэкапы и архивы — записали снапшот, он лежит месяцами, к нему обращаются только при восстановлении. Здесь равнодушно к тому, что нет частичной перезаписи: бэкап и не должен меняться после записи.
• Статические веб-ресурсы — CSS, JS, изображения для сайта, отдаваемые через CDN перед хранилищем.
• Архивы логов — накопленные и заархивированные логи, которые хранятся для разбора инцидентов или соответствия регламентам, а не для активной записи.

Второй важный критерий — когда к данным нужен доступ из нескольких разных приложений или серверов по сети через единый API, а не только с одной машины. Если у вас три worker-сервера генерируют отчёты и все три должны класть файлы в общее место, а потом четвёртый сервис их читает — гонять это через файловую систему с NFS или rsync между серверами обычно менее надёжно и сложнее в эксплуатации, чем дать всем трём HTTP-доступ к одному объектному хранилищу. Каждый сервис просто делает PUT/GET по сети, никакой общей точки монтирования, никаких проблем с блокировками файлов между хостами.

Когда файловая система остаётся правильным выбором

Обратная сторона: если приложению нужен традиционный файловый доступ, объектное хранилище не подменит файловую систему без переделки логики приложения.

• Базы данных — PostgreSQL, MySQL и подобные ожидают прямой файловый ввод-вывод с возможностью записи по смещению, fsync на уровне страниц и предсказуемой задержкой локального диска. Положить файлы БД в объектное хранилище напрямую — плохая идея; для БД нужен локальный SSD/NVMe или блочное хранилище.
• Рабочие файлы большинства обычных приложений — конфиги, кэши, временные файлы, файлы сессий — всё, что приложение открывает через обычные системные вызовы, ожидая стандартное файловое API.
• Частое изменение небольших частей данных — если файл активно правится (лог, который дозаписывается построчно, файл блокировки, часто обновляемый индекс), файловая система с её точечной записью по смещению эффективнее, чем перезагрузка целого объекта при каждом изменении.

Здесь же стоит вопрос производительности при большом количестве мелких операций: если приложение делает тысячи мелких чтений/записей в секунду, накладные расходы на HTTP-запрос к объектному хранилищу (соединение, заголовки, аутентификация подписи запроса) обычно выше, чем системный вызов к локальной файловой системе — конкретная разница в задержке будет сильно зависеть от вашего железа, сети и конфигурации, поэтому не буду называть цифры, но сам факт накладных расходов на каждый HTTP-вызов стоит держать в уме при проектировании.

Сравнение моделей — сводная таблица

Практический совет — используйте оба подхода вместе

Частая ошибка — воспринимать выбор как «или-или» на уровне всего проекта. На практике большинство современных архитектур используют обе модели параллельно, каждую там, где она сильна:

• Файловая система на сервере приложения — для рабочих данных: база данных на локальном диске, кэши, конфиги, временные файлы обработки.
• Объектное хранилище — для того, что генерируется или загружается, но не является рабочим состоянием приложения в реальном времени: пользовательские аватары и загрузки, готовые отчёты, архивы бэкапов БД, статика для раздачи через CDN.

Практическая схема на VPS: развернуть MinIO как self-hosted S3-совместимое хранилище на отдельном сервере или в отдельном контейнере, а приложение продолжает работать с локальной файловой системой для всего, что требует прямого файлового доступа, и обращается к MinIO по S3 API для медиа и бэкапов. Такой связке посвящена отдельная статья — пошаговая установка MinIO на VPS с реальными командами и конфигами, если решите развернуть S3-совместимое хранилище у себя, а не пользоваться внешним провайдером.

Если вопрос стоит уже не «файлы или объекты», а «где вообще держать хранилище в виртуализации» — это отдельная тема на уровне гипервизора, разобранная в статье про хранилища в Proxmox. А для сценария, когда файловое хранилище на сервере разрослось и его нужно перенести на терабайты без простоя, есть отдельный разбор в статье про миграцию файлового хранилища на терабайты.

Частые вопросы