Статья о хранении большого количества файлов

https://habr.com/post/423875/
Чего только не придумают люди чтобы усложнить себе жизнь. В комментариях
я считаю вполне себе годно заметили что если это append/write-only
хранилище, то разумно придумать собственный просто формат, запросто
затребующий ровно одного обращения/seek-а к диске для чтения файла.
Именно так, кстати, и делают, насколько слышал, в VK.

Лично меня когда-то тоже пугала мысль "что? писать что-то типа ФС
самостоятельно?". Но так уже приходилось делать -- для
узкоспециализированной задачи это не rocket science.

Но вообще мне кажется что XFS файловая система превосходно решит
проблему с большим кол-во файлов даже в одной директории. Созданная ещё
в 90-х годах Silicon Graphics, она изначально была заточена например
под то, чтобы хранить в одной директории полностью весь фильм, где
каждый кадр в отдельном файле. Речь про миллионы файлов в директории.
Все директории там устроены просто B-деревом. Поиск строки в СУБД
наверняка тоже будет B-деревом. Поэтому поиск файла на ФС наверняка
будет равносилен поиску в СУБД с точки зрения IOPS-ов, плюс он сразу
будет знать его размещение на ФС, без всё-равно хождения по иерархии
директорий названных в два символа. Кроме того, мало того что кэшу ФС
приходится запоминать метаинформацию директорий, так ещё и кэшировать
файлы самой СУБД, где эти индексы. Надо конечно проверять, как всегда в
Linux оно может работать ощутимо хуже, но для XFS поставленная задача не
проблема.

Впрочем, конечно же, как и для ZFS если будет память для кэширования
метаинформации, которая не так много весит.

Inode-based файловые системы типа Linux-овых ext*, BSD-шных UFS конечно
тут будут не очень.