2 файла, половина содержимого, против 1 файла, в два раза больше содержимого, что больше? - PullRequest
0 голосов
/ 30 марта 2010

Если у меня есть 2 файла каждый с этим:

«Hello World» (x 1000)

Это занимает больше места, чем 1 файл с этим:

«Hello World» (x 2000)

Каковы недостатки разделения содержимого на несколько более мелких файлов (если есть причина разделять их на несколько файлов, а не какэтот пример)?

Обновление:

Я использую Macbook Pro, 10.5.Но я также хотел бы знать, для Ubuntu Linux.

Ответы [ 5 ]

3 голосов
/ 30 марта 2010

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

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

"Hello World" x1000

намного эффективнее, чем на самом деле, когда "hello world" записан 1000 раз.

1 голос
/ 30 марта 2010

Файлы занимают место в виде кластеров на диске. Кластер - это число секторов, размер которого зависит от того, как был отформатирован диск.

Типичный размер кластеров составляет 8 килобайт. Это будет означать, что два файла меньшего размера будут использовать два кластера (16 килобайт) каждый, а файл большего размера будет использовать три кластера (24 килобайт).

Файл будет в среднем использовать на половину кластера больше, чем его размер. Таким образом, при размере кластера 8 килобайт каждый файл будет иметь в среднем 4 килобайта.

1 голос
/ 30 марта 2010

В большинстве файловых систем для хранения файлов используется кластер фиксированного размера (4 КБ, но не универсальный). Файлы ниже этого размера кластера будут занимать одинаковое минимальное количество.

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

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

Если у вас есть опция, вы также можете настроить размеры файлов, чтобы они всегда заполняли целое число кластеров, и тогда небольшие файлы не будут проблемой. Это, как правило, слишком привередливый, чтобы стоить того, хотя есть и другие затраты. Для пропускной способности большого объема оптимальный размер файла в наши дни составляет от 64 до 256 МБ (я думаю).

Практический совет: занесите свои вещи в базу данных, если нет веских причин не делать этого. SQLite существенно уменьшает количество причин.

0 голосов
/ 30 марта 2010

Большинство файловых систем выделяют пространство в единицах размером больше байта (обычно 4 КБ в настоящее время). Эффективные размеры файлов «округляются» до следующего кратного этого «размера кластера». Поэтому разделение файла почти всегда будет занимать больше общего пространства. И, конечно, есть одна дополнительная запись в каталоге, которая может привести к тому, что он будет занимать больше места, и многие файловые системы имеют дополнительный промежуточный уровень inode s, где каждый файл использует одну запись.

Каковы недостатки деления содержимое в несколько небольших файлов (при условии, что есть причина делить их в несколько файлов, а не так пример)

  • Больше потерянного пространства
  • Возможность исчерпания инодов (в крайних случаях)
  • В некоторых файловых системах: очень плохая производительность, когда каталоги содержат много файлов (потому что они фактически неупорядоченные списки)
  • Содержимое в одном файле обычно может быть прочитано последовательно (то есть без необходимости перемещения головки чтения / записи) с HD, что является наиболее эффективным способом. Когда он охватывает несколько файлов, этот идеальный случай становится гораздо менее вероятным.
0 голосов
/ 30 марта 2010

Я думаю, что использование файла (ов) должно быть принято во внимание, в соответствии с API и языком, используемым для их чтения / записи (и, следовательно, в конечном итоге ограничения API). Фрагментация диска, которая будет иметь тенденцию уменьшаться только с большими файлами, будет ограничивать доступ к данным, если вы читаете один большой файл за один раз, тогда как разнесенный доступ к небольшим файлам в несколько раз не будет наказываться фрагментацией.

...