Использование файловой системы в качестве базы данных для 15 миллионов файлов - насколько это эффективно?

У меня 15 миллионов простых записей типа ключ / значение. Размеры ключей - это все отдельные слова, значения, которые они содержат, имеют размер от нескольких байтов до 10 МБ каждое.

К случайным ключам потребуется часто обращаться.

Я думаю, что было бы гораздо эффективнее хранить их как файлы в каталоге, а не в базе данных. Поэтому вместо того, чтобы иметь массивную таблицу со всеми этими записями, все, что мне нужно, это каталог с именем файла в качестве ключа и значением внутри файла.

Это означает, что если мне нужно значение для ключа azpdk, мне просто нужно file_get_contents('/my/directory/azpdk') в PHP вместо того, чтобы беспокоить MySQL таким запросом.

В моей голове это имеет смысл, и я ожидаю, что будет более эффективно использовать для этого файловую систему вместо базы данных. Верно ли я в этом предположении? Будет ли это по-прежнему быстрым и эффективным с 15 миллионами файлов в одном каталоге?

К вашему сведению, файловая система - xfs.


database filesystems xfs
person Alasdair    schedule 01.05.2014    source источник

Ответы (2)


arrow_upward
4
arrow_downward

Есть несколько причин, по которым вы, вероятно, захотите взглянуть на базу данных (не обязательно MySQL), а не на файловую систему для такого рода вещей:

Чем больше файлов в одном каталоге, тем медленнее

Хотя предполагается, что XFS очень умно распределяет ресурсы, производительность большинства файловых систем снижается по мере того, как больше файлов находится в одном каталоге. Также становится головной болью иметь дело с ними в командной строке. Взглянув на это (http://oss.sgi.com/projects/xfs/datasheet.pdf) там есть график поисковиков, который увеличивается только до 50 КБ на каталог, и он сокращается.

Накладные расходы

Существует определенное количество накладных расходов файловой системы на файл. Если у вас много небольших файлов, вы можете обнаружить, что в результате последний раздувается.

Чистка ключей

Все ли ваши слова безопасны для использования в имени файла? Вы уверены? Пара косых черт действительно испортит вам день.

NoSQL может быть хорошим вариантом

Что-то вроде MongoDB / Redis может быть для этого хорошим вариантом. MongoDB может хранить отдельные документы размером до 16 МБ, и использовать это не намного сложнее, если поместить вещи в файловую систему. Если вы храните документы размером 15 Мбайт, то, возможно, вы слишком близки к этому пределу, но есть и другие варианты.

Приятно то, что производительность поиска, вероятно, будет довольно хорошей с самого начала, и если вы позже обнаружите, что это не так, вы можете масштабировать производительность, создав кластер и т. Д. Любая подобная система также будет хорошо работать. разумного управления файлами на диске для обеспечения хорошей производительности.

Если вы собираетесь использовать диск

Подумайте о том, чтобы взять хеш MD5 слова, которое вы хотите сохранить, и основать свое имя файла на этом. Например, MD5 azpdk:

1c58fb66d5a4d6a1ebe5ec9e217fbbf9

Вы можете использовать это для создания имени файла, например:

my_directory/1c5/8fb/66d5a4d6a1ebe5ec9e217fbbf9

У этого есть несколько приятных особенностей:

  • Хеш заботится о страшных персонажах
  • В каталогах разбросаны данные, поэтому ни в одном каталоге нет более 4096 записей.
  • Это означает, что производительность поиска должна быть относительно приличной.

Надеюсь, это поможет.

person Jon Betts    schedule 01.05.2014
comment
Спасибо, я закончил тем, что использовал первые два символа в качестве каталога, так как все ключи были a-z минимум 3 символа. Поскольку xfs в любом случае использует индексы btree ... ну, это в значительной степени сама база данных. - person Alasdair; 14.05.2014

arrow_upward
0
arrow_downward

Я работал в исследовательском центре геномики, где биоинфомратицины не были особо опытными программистами.

Вместо того, чтобы использовать базу данных, некоторые из них будут генерировать миллионы маленьких файлов, пока файловая система не остановится.

person wobbily_col    schedule 14.05.2014