Какова лучшая файловая система для управления миллионами изображений?
Я проектирую систему, способную работать с 15 миллионами (и растущими) файлами изображений размером от 100 до 10 МБ. Я ищу некоторые мнения о том, что может быть лучшей файловой системой для поддержки (несколько) странных требований:
Дополнительная информация / требования:
- Структура каталогов не является обязательной [1], но из-за дизайна приложений, извлекающих эти данные, она относительно неизменна.
- Данные должны быть оптимизированы для чтения, включая, но не ограничиваясь: случайное чтение, последовательное чтение, списки каталогов (в некоторых каталогах может быть 30000 каталогов или 1000 изображений) и т. Д.
- Дополнительные данные будут записываться в файловую структуру (новые подкаталоги, дополнительные файлы в существующих подкаталогах и т. Д.) На полурегулярной основе, однако производительность записи не представляет большой проблемы. Данные будут записываться через SMB или NFS.
- Существует значительное количество идентичных файлов (консервативная оценка составляет 20%), однако из-за дизайна приложения, извлекающего эти данные, мы не можем удалить дублирующиеся имена файлов. В идеале нам хотелось бы какой-то дедупликации (конечно, мы могли бы иметь жесткую ссылку, но я не уверен, как будут масштабироваться миллионы жестких ссылок)
- Твердотельные накопители будут основной формой хранилища для этого проекта (если вместо этого не может быть задан аргумент для счетчиков), поэтому мы хотели бы ограничить записи в систему, где это возможно.
Оборудование, выделенное для этого проекта, выглядит следующим образом:
Dell R720xd w/ 24x 2.5” bays
RAM: 128GB RAM (more can be allocated if needed)
CPU: 2x E5-2620 @ 2.20GHz
Storage:
8x2TB SSDs local storage
1x500GB SSD for OS
RAID: H310 (IT Mode)
Мы изначально рассматривали ZFS для этого, но после некоторых дополнительных исследований это выглядит так:
- ZFS может перебивать SSD при записи обновлений метаданных.
- ZFS предъявляет высокие требования к оперативной памяти для дедупликации (5 ГБ ОЗУ на 1 ТБ данных). Это должно быть выполнимо на нашем текущем оборудовании, хотя, это кажется большим количеством накладных расходов.
- RiserFS может лучше подходить для случайного поиска небольших файлов (кажется, я не могу найти то, что подходит для "маленького" файла).
Будем весьма благодарны за любые мнения об оптимальной файловой системе для этого варианта использования, а также о любых аппаратных настройках.
[1]
Пример структуры каталогов (ни один из каталогов или имен файлов никоим образом не нормализован (последовательный и т. Д.))
+ root directory 1
- sub directory 1
- image 1
- image 2
- image 3
- ...
- image n (where n is between 1 and 1,000+)
- sub directory 2
- image 1
- image 2
- image 3
- ...
- image n
....
- sub directory n (where n is between 1,000 and 30,000)
- image 1
- image 2
- image 3
- ...
- image n
+ root directory 2
+ ...
+ root directory 15
1 ответ
Любая файловая система (в том числе XFS с небольшим объемом ext4 и чуть-чуть меньше) может соответствовать перечисленным требованиям, которые в основном заключаются в способности хранить много файлов и разумной производительности в самых разных случаях. Мои знания (и интересные компромиссы в этом ответе) в основном касаются ZFS, поэтому я сосредоточусь на этом.
Дополнительные возможности, которые вы получите от ZFS:
- DeDup. Как вы сказали, это не супер замечательно в ZFS, потому что у него большие требования к оперативной памяти, но он работает. Чтобы получить нечто похожее на не-ZFS, вы можете хэшировать свои файлы и использовать хэши в качестве имен файлов / имен каталогов, или хранить базу данных хэшей -> имя файла, чтобы вы могли создавать жесткие ссылки. (В любом из этих случаев вам понадобятся одинаковые файлы, а не только изображения, которые выглядят одинаково).
- Сжатие. Большинство изображений уже сжаты, так что это может вам ничего не купить, но если они не в формате JPEG, а в формате RAW, это может стать большой экономией. Если нет, это не купит вам много.
- Возможность снимать / резервировать. ZFS имеет отличные встроенные инструменты для этого. Вы также можете создавать резервные копии не-ZFS, хотя может быть сложно получить непротиворечивый снимок ваших данных. LVM может сделать кое-что из этого, хотя, возможно, не так хорошо.
- Управление томами является частью ZFS. Вы можете выбрать из набора очень гибких конфигураций RAID, чтобы получить оптимальную конфигурацию [избыточность данных, использование пространства, производительность] для вашего конкретного приложения. Вы можете получить часть этого из LVM и другого программного RAID, но я считаю, что ZFS предлагает одно из лучших решений для управления томами в сочетании с хорошо разработанной системой обнаружения и восстановления после сбоев.
Вы упомянули еще две вещи:
- Бьющие метаданные. Я не думаю, что ZFS будет хуже, чем другие файловые системы: он обновляет достаточное количество метаданных во время записи, но копирует при записи и выполняет эти обновления пакетами каждые 5-10 секунд, что означает, что происходят большие непрерывные записи вместо небольших записей на месте, которые требуют многократного стирания и перезаписи блоков NAND. В традиционной файловой системе вы получите другой путь, потому что он будет выполнять обновления на месте, что, вероятно, немного хуже. Во всяком случае, современные твердотельные накопители имеют много дополнительных внутренних блоков, которые они резервируют для продления срока службы накопителя при наличии износа - нормальные сроки службы накопителя считаются сопоставимыми с продолжительностью службы накопителя. Я не говорю, что это не имеет значения, я просто не думаю, что вам следует слишком зацикливаться на этом аспекте, поскольку он довольно незначительный.
- Масштабируемость жестких ссылок. Должен масштабироваться так же или лучше, чем обычные файлы (в ZFS или нет). В любом случае, жесткая ссылка - это просто указатель на тот же индекс, что и какой-либо другой файл, и вы, вероятно, получите очень небольшой выигрыш в эффективности кэша, поскольку чтение этого файла по одной из ссылок сделает его кэшированным для доступа через другие ссылки. тоже.