Самый быстрый доступ к файлам/хранение?

Похоже, это будет в значительной степени вопрос выбора файловой системы. Одним из возможных вариантов может быть ZFS, он предназначен для приложений с большим объемом.

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

Обновление. Ваша дополнительная информация, безусловно, полезна. При выборе между FAT32 и NTFS, тогда определенно выберите NTFS. Не храните слишком много файлов в одном каталоге, 100 000 могут быть верхним пределом для рассмотрения (хотя вам придется поэкспериментировать, жесткого правила не существует). Предложение вашего друга о новом каталоге для каждой буквы, вероятно, слишком много, вы можете подумать о том, чтобы разбить его на каждые четыре буквы или что-то в этом роде. Лучшее значение для выбора зависит от формы вашего набора данных.

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

Этот файловый алгоритм будет работать, но он не оптимален. Я бы подумал, что использование двух- или трехсимвольных «сегментов» будет лучше для производительности, особенно когда вы начинаете задумываться о создании резервных копий.

Например:
d:\storage\fo\ob\ar\foobar.txt
или
d:\storage\foo\bar\foobar.txt

Использование такого алгоритма имеет ряд преимуществ:

1. Доступ к базе данных не требуется.
2. Файлы будут разбросаны по многим каталогам. Если вы не распространите их, вы столкнетесь с серьезными проблемами производительности. (Я смутно припоминаю, что слышал о том, что у кого-то были проблемы с ~40 000 файлов в одной папке, но я не уверен в этом числе.)
3. Нет необходимости искать файл. Вы можете точно определить, где будет находиться файл, по имени файла.
4. Простота. Вы можете очень легко перенести этот алгоритм практически на любой язык.

Есть в этом и минусы:

1. Многие каталоги могут привести к медленному резервному копированию. Представьте себе выполнение рекурсивных различий в этих каталогах.
2. Масштабируемость. Что произойдет, если у вас закончится место на диске и вам нужно добавить больше памяти?
3. Имена ваших файлов не могут содержать пробелы.

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

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

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

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

Итак, я бы сохранил foobar.txt как f/o/o/b/foobar.txt.

Это сильно зависит от многих факторов:

• Какую файловую систему вы используете?
• Насколько велик каждый файл?
• Какой тип дисков вы используете?
• Каковы схемы доступа?

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

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

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

Обновлять:

Учитывая ваше обновление, возможно ли, что вы консолидируете некоторые файлы? Файлы размером 1k не очень эффективно хранить, поскольку файловые системы (fat32, ntfs) имеют размер кластера, и каждый файл все равно будет использовать размер кластера, даже если он меньше размера кластера. Обычно существует ограничение на количество файлов в каждой папке из-за проблем с производительностью. Вы можете провести простой тест, поместив в папку до 10 000 файлов, чтобы увидеть, насколько снижается производительность.

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

Во-первых, размер файла очень маленький. Любая файловая система займет как минимум в 4 раза больше места. Я имею в виду, что любой файл на диске будет занимать 4 КБ для файла размером 1 КБ. Особенно на SSD-дисках сектор размером 4 КБ будет нормой.

Таким образом, вам нужно сгруппировать несколько файлов в 1 физический файл. 1024 файла в 1 файле хранилища кажется разумным. Чтобы найти отдельные файлы в этих файлах хранилища, вы должны использовать некоторую СУБД (упомянута PostgreSQL, и это хорошо, но SQLite может лучше подходить для этого) или аналогичную структуру для выполнения сопоставления.

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

Если вы можете, не позволяйте им форматировать FAT32, по крайней мере, NTFS или какой-либо недавний вариант файловой системы Unix. Поскольку общий размер файлов не такой большой, NTFS может быть достаточно, но ZFS - лучший вариант...

Есть ли какая-либо связь между отдельными файлами? Что касается времени доступа, папки, в которые вы помещаете вещи, не сильно повлияют; физические места на диске имеют значение.

Почему неприемлемо сохранение путей в таблице базы данных?

Я предполагаю, что он думает о структуре данных Trie для создания на диске, где узел является каталог.

Я бы проверил модель hadoops.

P

Я знаю, что это с опозданием на несколько лет, но, возможно, это поможет следующему парню.

Я предлагаю использовать SAN, сопоставленную с диском Z, на который могут сопоставляться и другие серверы. Я бы не стал использовать путь к папке, который сказал ваш друг, но больше с диском:\clientid\год\месяц\день\ и если вы проглатываете более 100 тысяч документов в день, вы можете добавлять подпапки в течение часа и даже минуту, если это необходимо. Таким образом, у вас никогда не будет более 60 подпапок, а если потребуется, то вплоть до секунд. Сохраняйте ссылки в SQL для быстрого поиска и составления отчетов. Это делает путь к папке довольно коротким, например: Z:\05\2004\02\26\09\55\filename.txt, поэтому вы не столкнетесь с ограничениями 256 по всем направлениям.

Надеюсь, это поможет кому-то. :)