У меня есть трехуровневая структура каталогов, определяемая двумя шестнадцатеричными цифрами как таковая:
0A/FF/2B/someimagefile.gif
У меня есть 300 миллионов небольших файлов в 1,5 ТБ сжатых файлов, которые будут заполнять эти каталоги (в будущем у нас будет больше файлов, поэтому я выбрал структуру каталогов, чтобы масса файлов не приводила к сбоям в типичной файловой системе extX).
Распаковка этих файлов выполняется со скоростью 1 МБ в секунду (или ~ 18 дней на распаковку). Оучи!
Я предполагаю, что это было медленно, потому что я создавал структуру каталогов, а затем файлы (сделанные из Java API). Поэтому я решил просто создать структуру каталогов в цикле bash.
Одни только каталоги - это примерно 5-дневная задача при текущей ставке.
Есть идеи по увеличению скорости движения?
ОБНОВИТЬ
Одна часть головоломки решена: использование perl, а не bash, создает каталоги более чем в 200 раз быстрее, теперь это операция, которая дает вам перерыв на кофе, а не расширенные выходные.
Но создание файлов по-прежнему происходит очень медленно, даже без необходимости создания каталогов.
Мой окончательный ответ на это: «Не делай этого».
Я не смог найти способ повысить скорость более 2 Мбайт / сек при создании большого количества небольших файлов. Для террабайтных объемов данных это слишком большая инерция, чтобы противостоять ей.
Мы идем по стопам facebook и выгружаем файлы в хранилище двоичных данных (или используем массивную таблицу mysql / myisam с BLOB, экспериментируем сейчас ...).
Это немного сложнее, но устраняет проблему случайного поиска, связанную с небольшими файлами, и я могу работать с террабайтными объемами данных за считанные часы или день, а не недели.
MongoDB стал еще одним хорошим вариантом для исследования.
перемонтировать файловую систему с параметрами noatime, nodiratime