Две философии хранения

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

Файловое хранилище – это дерево: папки, подпапки, пути. Человеку такая навигация привычна, но для системы – нагрузка. Это шкаф с полками и подписанными папками: чтобы найти документ, нужно знать маршрут. Дерево требует постоянного обновления таблиц, контроля перемещений и прав доступа, а рост данных усложняет систему. На объемах около 1 Пбайт файловые системы «задыхаются».

Объектное хранилище имеет иную парадигму: в нем нет иерархии, это плоское пространство с уникальными идентификаторами, где каждый объект самодостаточен. Аналогия – склад без стеллажей, где у каждого контейнера свой QR-код. Это снимает проблему масштабирования: экзабайты данных – вполне решаемая задача, поиск идет не по папкам, а по атрибутам. При этом важно понимать: объектное хранилище заточено именно под хранение, а не под редактирование.

Второй момент – метаданные. В файловом мире они аскетичны: дата создания, изменения, пара флагов. Для навигации по папкам этого достаточно, а для аналитики или автоматизации обработки – мало. Объектное хранилище в этом смысле – настоящий рай, оно позволяет добавить к объекту любые метаданные в формате «ключ-значение»: проект, отдел, статус, срок хранения, теги. Это превращает хранилище в подобие базы данных с классификацией.

Различаются и протоколы доступа. Файловые хранилища «общаются» на языках SMB/CIFS, NFS и подобных, они умеют блокировать, открывать на запись, править фрагменты. Объектные хранилища «говорят» на HTTP через RESTful API, как правило, совместимых с Amazon S3. Философия здесь иная: объект кладется целиком, берется целиком, удаляется целиком. Без работы с фрагментами.

Холодно-горячо: сортируем данные

Как понять, что класть в шкаф (файлы), а что – на склад (объекты)? Нужно измерить «температуру» данных. «Горячее» – то, с чем работают прямо сейчас: совместное редактирование, быстрая навигация по папкам, постоянные изменения. Это – зона файлового хранилища: бухгалтерия, почта, проектные каталоги, рабочие базы данных.

«Теплое» – данные, к которым обращаются время от времени и которые могут пригодиться в ближайшие пару лет. Их пока еще удобнее держать в файлах. А вот «холодное» – архив, который не изменится, но должен храниться. Это территория объектного хранилища.

Классический корпоративный файловый сервер, куда отделы ежедневно складывают документы, таблицы, презентации и мелкие картинки – это пример зоны ответственности файлового хранилища. Чтобы открывать, править, переименовывать и перетасовывать, нужна файловая система с низкими задержками и поддержкой блокировок.

Например, бухгалтерия. Текущая база данных (MySQL или другая СУБД) требует минимальных задержек – это идеальный сценарий для файлового хранилища. А база данных за прошлые годы, которая хранится для аудита – идеальный кандидат для объектного хранения. Место занимает, но ресурсы на поддержку быстрого доступа не потребляет. Задержки при чтении выше, но для архива это некритично. Туда же отправляются все неизменяемые документы: накладные прошлых лет, договоры, закрытые проекты, старые версии отчетов.

Если коротко: «горячие» и «теплые» – в файловое. «Холодные» – в объектное.

Стоимость, безопасность, масштабирование

Кроме «температуры» данных, выбор хранилища диктуют безопасность, стоимость и масштабирование.

Что касается безопасности, в файловых хранилищах модель привычная: пользователи, группы, списки доступа к каждой папке и файлу. Кто может заглянуть, а кто – исправить, прописано четко. Учетные записи и классические списки контроля доступа (ACL) выступают основным инструментом. В объектных хранилищах логика иная, в них доступ управляется через бакеты – контейнеры для объектов, к которым применяют политики доступа. Гибкость такой модели выше.

Но фундаментальной разницы в уровне безопасности между подходами нет. В обоих случаях доступно шифрование, роли и политики. Вопрос не в типе хранилища, а в том, как выстроена архитектура и выполнены настройки.

Если говорить о стоимости, то существует устойчивый миф: раз объектное хранилище современно, значит, оно автоматически экономит бюджет. Это верно лишь с оговоркой. Если заглянуть «под капот», физическая основа у обоих типов одна – жесткие диски. Физику не обмануть: стоимость гигабайта на носителе примерно одинакова. Но экономика меняется в зависимости от архитектуры и масштаба.

Условно, на малых объемах, до 50-100 Тбайт, объектное хранилище может оказаться дороже файловой «полки» из-за необходимости в дополнительных серверах для управления метаданными и распределенностью. Когда данные переваливают за сотни терабайт к петабайтам – расклад меняется. Объектное хранилище масштабируется горизонтально: добавил сервисы – линейно увеличил емкость. Для файловой системы петабайтный объем – инженерный подвиг с дорогими специализированными решениями. Еще один важный нюанс: файловые хранилища для горячих данных строят на NVMe-дисках, очень быстрых, но очень дорогих. Для холодных или даже теплых массивов такая скорость избыточна. Это как гонять Ferrari за хлебом в соседний магазин.

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

Если рассматривать вопрос масштабирования, в мире файловых хранилищ данные требуют регулярного резервного копирования. В объектных – логика кардинально иная. Архитектура с троекратной репликацией (часто географически распределенной) делает классический бэкап излишним. Данные переживают выход из строя диска, сервера и даже целого дата-центра. Исключение – базы данных с частыми изменениями. Им классический бэкап по-прежнему нужен.

Строим мосты, а не ломаем софт

Главная сложность внедрения объектных хранилищ в корпоративную среду – в привычках. Большинство приложений – от офисных пакетов до учетных систем – заточены под файловую модель: папки, сохранение, переименование. Нативной поддержки протоколов вроде S3 у такого софта практически нет. Здесь возможны два пути. Первый – разработка собственных интерфейсов, например, веб-приложений, в которых можно искать документы по метаданным, просматривать и скачивать. Второй вариант – использование шлюзов (программ-переводчиков), которые имитируют файловую структуру (папки) поверх объектного хранилища.

Но если приложение само умеет работать с S3 напрямую (современные аналитические платформы, системы Big Data), любой шлюз добавляет лишь задержки. В таких случаях правильнее обращаться к хранилищу через нативный API.

Диктуют ли правила большие данные

Главный драйвер развития систем хранения сегодня – Big Data, машинное обучение, датасеты для ИИ-моделей. Это гигантские массивы информации, которые не требуют частых изменений. Здесь объектное хранилище с его «безразмерной» архитектурой – единственный экономически оправданный вариант.

Но есть и технологический вызов. Объектные хранилища пока проигрывают файловым в скорости доступа: миллисекунды против сотен миллисекунд. Усилия вендоров направлены на сокращение этого разрыва за счет новых протоколов и кэширования. Если провайдер инвестирует в ускорение S3, это позволит «перекладывать» в объекты все более теплые данные, экономя на дорогих носителях.

Вывод

Файловые и объектные хранилища – не конкуренты, а инструменты для разных задач. Файлы незаменимы для операционной работы с часто изменяемыми данными, где важна скорость. Объекты – для масштабируемых архивов, аналитических платформ и резервных копий, где приоритетны надежность, экономичность и глубокая классификация. Грамотный подход – не выбор чего-то одного, а симбиоз, распределяющий данные по их актуальности и ценности.

Поэтому выбор – не между «шкафом» и «складом». Умная архитектура – когда «горячие» документы лежат в шкафу под рукой, а «холодный» архив – на складе, откуда его можно получить по QR-коду в любую секунду. И с развитием ИИ таких «холодных», но ценных данных будет только больше.

 

Автор – Руслан Райкевич, ИТ-директор ActiveCloud