Какая файловая система лучше всего подходит для управления миллионами изображений?
Я разрабатываю систему, способную работать с 15 миллионами (и растущими) файлами изображений размером от 100 КБ до 10 МБ. Я ищу некоторые мнения о том, какая файловая система может быть лучшей для поддержки (несколько) странных требований:
Дополнительная информация / Требования:
- Структура каталогов определенно не является обязательной [1], но из-за дизайна приложений, вытягивающих эти данные относительно неизменяемы.
- Данные должны быть оптимизированы для чтения, что включает, но не ограничивается: случайные чтения, последовательные чтения, списки каталогов (некоторые каталоги могут иметь 30 000 каталогов или 1000 изображений) и т. д.
- Дополнительные данные будут записываться в файловую структуру (новые подкаталоги, дополнительные файлы в существующих подкаталогах и т. Д.) На полурегулярной основе, однако производительность записи не имеет большого значения.Данные будут записываться через SMB или NFS.
- Существует значительное количество идентичных l файлов (консервативная оценка - 20%), однако из-за дизайна приложения, получающего эти данные, мы не можем удалить повторяющиеся имена файлов. В идеале нам нужна какая-то дедупликация (мы, конечно, могли бы жестко связать, но я не уверен, как будут масштабироваться миллионы жестких ссылок)
- SSD будут основной формой хранилища для этого проекта (если не будет аргументов в пользу прядильщики), поэтому мы хотели бы ограничить запись в систему, где это возможно.
Оборудование, которое мы выделили для этого проекта, выглядит следующим образом:
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
4
задан Josh
27 November 2018 в 02:25
Ссылка
1 ответ
Любая файловая система (включая простую ext4 и чуть менее скромную XFS) может удовлетворить перечисленным вами требованиям, которые в основном заключаются в способности хранить много файлов и разумной производительности в широком диапазоне вариантов использования. Мои знания (и интересные компромиссы в этом ответе) в основном касаются ZFS, поэтому я сосредоточусь на этом.
Дополнительные возможности, которые вы получите от ZFS, следующие:
- Dedup. Как вы сказали, в ZFS это не очень хорошо, потому что у него большие требования к оперативной памяти, но это работает. Чтобы получить что-то похожее на не-ZFS, вы можете хэшировать свои файлы и использовать хеши в качестве имен файлов / имен каталогов или сохранить базу данных хешей -> имен файлов, чтобы вы могли создавать жесткие ссылки. (В любом из этих случаев вам потребуется точно одинаковых файлов, а не только изображения, которые выглядят одинаково).
- Сжатие. Большинство изображений уже сжаты, так что это может вам не дорого, но если они будут в формате RAW, а не в формате JPEG, это может быть большой экономией. В противном случае это ничего не даст.
- Возможность делать снимки / резервные копии. ZFS имеет для этого отличные встроенные инструменты. Вы также можете выполнять резервное копирование без использования ZFS, хотя получить согласованный снимок данных может быть сложно. LVM может кое-что из этого, хотя, возможно, и не так хорошо.
- Управление томами является частью ZFS. Вы можете выбрать из набора очень гибких конфигураций RAID, чтобы получить оптимальную конфигурацию [избыточность данных, использование пространства, производительность] для вашего конкретного приложения. Вы можете получить часть этого с помощью LVM и другого программного обеспечения RAID, но я считаю, что ZFS предлагает одно из лучших решений для управления томами в сочетании с хорошо продуманной системой обнаружения сбоев и восстановления.
Еще две вещи. вы упомянули:
- Обработка метаданных. Я не думаю, что ZFS будет хуже, чем другие файловые системы: он действительно обновляет изрядное количество метаданных во время записи, но он копирует при записи и выполняет эти обновления пакетами каждые 5-10 секунд, что означает, что происходят большие непрерывные записи вместо небольших операций записи на месте, требующих многократного стирания и перезаписи блоков NAND. В традиционной файловой системе вы получите другой способ, потому что он будет выполнять обновления на месте, что, вероятно, немного хуже. В любом случае, современные твердотельные накопители имеют много дополнительных внутренних блоков, которые они резервируют для продления срока службы накопителя в случае износа - нормальный срок службы накопителя считается сопоставимым со сроком его службы. Я не говорю, что это неважно, просто не думаю, что вам стоит слишком зацикливаться на этом аспекте, поскольку он довольно второстепенный.
- Масштабируемость жестких ссылок. Должны масштабироваться так же или лучше, чем обычные файлы (в ZFS или нет). В любом случае жесткая ссылка - это просто указатель на тот же индексный дескриптор, что и какой-либо другой файл, и вы, вероятно, получите очень небольшую победу в эффективности кеширования, поскольку чтение этого файла по одной из ссылок сделает его кешированным для доступа по другим ссылкам. тоже.
3