From: Sergey Matveev Date: Thu, 20 Sep 2018 18:44:08 +0000 (+0300) Subject: Статья о хранении большого количества файлов X-Git-Url: http://www.git.stargrave.org/?a=commitdiff_plain;h=87034a28f5cf0ab7dd4193dcfdb2ac52fd83c949;p=stargrave-blog.git Статья о хранении большого количества файлов 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 конечно тут будут не очень. ---