Один большой файл или несколько маленьких файлов?

Question

У меня есть приложение (в настоящее время написанное на Python, когда мы проясняем специфику, но в конечном итоге оно будет написано на C), которое использует отдельные записи, хранящиеся в текстовых файлах. Мы не можем использовать базу данных, и новые записи должны будут регулярно добавляться вручную.

У меня такой вопрос: было бы быстрее иметь один файл (500k-1Mb), чтобы мое приложение открывало, просматривало, находило и закрывало файл ИЛИ было бы быстрее разделять и именовать записи, используя соответствующее соглашение, чтобы приложение могло просто зацикливаться на именах файлов, чтобы найти необходимые данные?

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

Большое спасибо заранее за ваше время, Dan

Answer 1

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

Вы можете достичь цели "не помещать слишком много файлов в один каталог", используя несколько уровней каталогов - например, запись с ключом FOOBAR может храниться в data/F/FO/FOOBAR, а не просто data/FOOBAR.

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

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

Answer 2

Чтение каталога обычно обходится дороже, чем чтение файла. Но если вы можете найти нужный файл, не читая каталог (т. Е. Не «перебирать имена файлов», а «создавать имя файла») из-за соглашения об именовании, может оказаться полезным разделить базу данных.

Answer 3

Учитывая, что ваши данные составляют 1 МБ, я бы даже подумал сохранить их полностью в памяти.

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

Answer 4

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

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

(Что я могу сказать наверняка, так это то, что вам не следует прибегать к линейному поиску файлов, вместо этого используйте соглашение об именах, чтобы точно определить время файла за O (1)).

Answer 5

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

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

Answer 6

Открытие файла и закрытие файла в C займет много времени то есть у вас есть 500 файлов по 2 КБ каждый ... и если вы обработаете его, 1000 дополнительных операций будет добавлено в ваше приложение (500 открывающих файлов и 500 закрывающих) ... в то время как только 1 файл размером 1 МБ спасет вас от этого 1000 дополнительных операций ... (Это чисто мое личное мнение ...)

Answer 7

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

Answer 8

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

Не всем БД требуется сервер для подключения или сложного развертывания. Например, SQLite может быть легко встроен в ваше приложение. В Python он уже встроен, и его очень легко соединить с кодом C (сам SQLite написан на C, а его основной API предназначен для C). SQLite управляет полнофункциональной БД в одном файле на диске, где вы можете создавать несколько таблиц и использовать все другие полезные функции БД.