Назад | Перейти на главную страницу

Какая файловая система лучше всего подходит для управления миллионами изображений?

Я разрабатываю систему, способную работать с 15 миллионами (и растущими) файлами изображений размером от 100 КБ до 10 МБ. Я ищу мнения о том, какая файловая система может быть лучшей для поддержки (несколько) странных требований:

Дополнительная информация / требования:

Структура каталогов определенно не является необязательной [1], но из-за дизайна приложений, извлекающих эти данные, она относительно неизменна.
Данные должны быть оптимизированы для чтения, что включает, но не ограничивается: случайным чтением, последовательным чтением, списками каталогов (в некоторых каталогах может быть 30 000 каталогов или 1000 изображений) и т. Д.
Дополнительные данные будут записываться в файловую структуру (новые подкаталоги, дополнительные файлы в существующих подкаталогах и т. Д.) На полурегулярной основе, однако производительность записи не имеет большого значения. Данные будут записываться через SMB или NFS.
Существует значительное количество идентичных файлов (консервативная оценка - 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

Любая файловая система (включая невысокую ext4 и немного менее скромную XFS) может соответствовать перечисленным вами требованиям, которые в основном заключаются в способности хранить много файлов и разумной производительности в самых разных случаях использования. Мои знания (и интересные компромиссы в этом ответе) в основном касаются ZFS, поэтому я сосредоточусь на этом.

Дополнительные возможности, которые вы получите от ZFS:

Дедуп. Как вы сказали, это не очень хорошо в ZFS, потому что у него большие требования к оперативной памяти, но это работает. Чтобы получить что-то похожее на не-ZFS, вы можете хэшировать свои файлы и использовать хеши в качестве имен файлов / имен каталогов или сохранить базу данных хешей -> имен файлов, чтобы вы могли создавать жесткие ссылки. (В любом из этих случаев вам понадобится именно одинаковые файлы, а не только изображения, которые выглядят одинаково).
Сжатие. Большинство изображений уже сжаты, так что это может вам не дорого, но если они будут в формате RAW, а не в формате JPEG, это может быть большой экономией. В противном случае это не принесет вам многого.
Возможность делать снимок / резервное копирование. В ZFS для этого есть отличные встроенные инструменты. Вы также можете выполнять резервное копирование без использования ZFS, хотя получить согласованный снимок данных может быть сложно. LVM может кое-что из этого сделать, хотя, возможно, и не так хорошо.
Управление томами является частью ZFS. Вы можете выбрать из набора очень гибких конфигураций RAID, чтобы получить оптимальную конфигурацию [избыточность данных, использование пространства, производительность] для вашего конкретного приложения. Вы можете получить часть этого из LVM и другого программного обеспечения RAID, но я считаю, что ZFS предлагает одно из лучших решений для управления томами в сочетании с хорошо продуманной системой обнаружения сбоев и восстановления.

Вы упомянули еще две вещи:

Обработка метаданных. Я не думаю, что ZFS будет хуже других файловых систем: он действительно обновляет изрядное количество метаданных во время записи, но копирует при записи и выполняет эти обновления пакетами каждые 5-10 секунд, что означает, что происходят большие непрерывные записи. вместо небольших операций записи на месте, требующих многократного стирания и перезаписи блоков NAND. В традиционной файловой системе вы получите другой способ, потому что он будет выполнять обновления на месте, что, вероятно, немного хуже. В любом случае, современные твердотельные накопители имеют много дополнительных внутренних блоков, которые они резервируют для продления срока службы накопителя в случае износа - нормальный срок службы накопителя считается сопоставимым со сроком его службы. Я не говорю, что это неважно, просто не думаю, что вам следует слишком зацикливаться на этом аспекте, поскольку он довольно незначительный.
Масштабируемость жестких ссылок. Должны масштабироваться так же или лучше, чем обычные файлы (в ZFS или нет). В любом случае жесткая ссылка - это просто указатель на тот же индексный дескриптор, что и какой-либо другой файл, и вы, вероятно, получите очень небольшой выигрыш в эффективности кеширования, поскольку чтение этого файла по одной из ссылок сделает его кешированным для доступа по другим ссылкам. слишком.