Как лучше всего хранить 1 миллиард маленьких текстовых файлов?

Question

В одной файловой системе мне нужно хранить 1 миллиард 1KB текстовых файлов.Каждый файл имеет уникальную строку идентификатора, и он должен быть оптимизирован по производительности.Что лучше?

EXT4: (пример структуры файла для имени файла: kdWqpGQ1)

/kd/Wq/pG/Q1.file

или

/kdWqpGQ1.file

Или я должен избегать этого и использовать какой-то виднереляционной базы данных?

Кроме того, я всегда могу разделить имеющийся у меня том объемом 5 ТБ на 5 * 1 ТБ жестких дисков, каждый из которых содержит более 200 МБ файлов.Я хочу добавить, что 1B файлов - это предельный случай, я, скорее всего, достигну только 500M.

Спасибо!

Answer 1

«Или мне следует избегать этого и использовать какую-то нереляционную базу данных?»

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

Файловая система NTFS, распространенная в Windows, имеет теоретический предел , равный примерно 4 миллиардам файлов.По умолчанию минимальный размер файла в NTFS составляет 4 КБ, что означает, что ваша база данных объемом 1 ТБ мгновенно увеличится до 4 ТБ только по этой причине.

Вы, вероятно, должны смотреть на систему баз данных, такую ​​как sql или sqlite .Преимущество заключается в том, что вам не нужно думать о схемах именования и других практических деталях.Вы также можете разработать собственный формат, в котором все данные хранятся в нескольких файлах. Если вы дадите подробную информацию о типе данных, с которыми вы работаете, возможно, у кого-то есть более конкретные советы для вас!

Answer 2

Ваш первый вариант намного быстрее.

Думайте о каталоге в файловой системе как о текстовом файле с несортированным списком всех файлов в этом каталоге с адресом, где найти файл на диске. Чтобы прочитать файл, вам необходимо знать адрес файла на диске. Если у вас есть путь, например «/ myfilename», вам нужно найти файл /, который является каталогом и содержит все файлы в этом каталоге. Чем вам нужно отсканировать этот файл для записи «myfilename», которая в худшем случае может потребовать, чтобы вы просмотрели весь файл. В среднем это займет O (N / 2), в то время как N составляет примерно 1 миллиард (общее количество файлов в этом каталоге).

Если у вас есть несколько каталогов ... Скажем, всегда 1000 файлов в каталоге, чтобы у вас было 3 уровня каталогов и ваш путь к файлу теперь / A / B / myfilename, тогда вам сначала нужно будет открыть каталог /, найдите A (для этого требуется O (1000/2), откройте этот файл и найдите B (O (1000/2) снова) и снова откройте этот файл, чтобы найти myfilename (все же снова O (1000/2)). быть 3 * O (1000/2) = 1500, что НАМНОГО быстрее, чем O (500.000.000), который мы имели ранее.

Это очень важный аспект файловых систем, о котором всегда следует помнить. Если у вас есть каталог, риск которого может превысить 10 000 файлов, я настоятельно рекомендую подумать о стратегии сортировки этих файлов в подкаталогах.

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

Для дальнейшего чтения файловых систем я рекомендую книгу Tanenbaum «Современная операционная система» (глава 6 «Файловые системы»), которая доступна онлайн здесь: http://lovingod.host.sk/index.html?page=tanenbaum%2FOperating-Systems-Design.html