Один большой файл или несколько маленьких файлов?
У меня есть приложение (в настоящее время писавшийся в Python, поскольку мы сглаживаем специфические особенности, но в конечном счете он будет записан в C), который использует отдельные записи, сохраненные в файлах простого текста. Мы не можем использовать базу данных, и новые записи должны будут вручную регулярно добавляться.
Мой вопрос - это: это было бы быстрее, чтобы иметь единственный файл (500k-1Mb) и иметь мое открытое приложение, цикл через, найти и закрыть файл, ИЛИ это было бы быстрее, чтобы разделить записи и названное использование некоторой соответствующей конвенции так, чтобы приложение могло просто циклично выполниться по именам файлов для нахождения данных, в которых это нуждается?
Я знаю, что мой вопрос является довольно общим, таким образом, направление к любым хорошим статьям о теме как ценится так же как предложения.
Заранее большое спасибо в течение Вашего времени, Dan
8 ответов
По сути, ваш второй подход - это индексирование - вы просто создаете свой индекс в самой файловой системе. По сути, в этом нет ничего плохого, и если вы все устроите так, чтобы не было слишком много файлов в одном каталоге, все будет достаточно быстро.
Вы можете достичь цели «не помещать слишком много файлов в один каталог», используя несколько уровней каталогов - например, запись с ключом FOOBAR может храниться в data / F / FO / FOOBAR , а не просто data / FOOBAR .
В качестве альтернативы, вы можете сделать так, чтобы один большой файл также работал, создав индексный файл, который содержит (отсортированный) список пар ключ-смещение. Подход «каталоги как индекс» терпит неудачу, когда вы хотите искать по ключу, отличному от того, который вы использовали для создания имен файлов - если вы использовали индексный файл, вы можете просто создать второй индекс для этой ситуации.
Возможно, вы захотите пересмотреть ограничение «мы не можем использовать базу данных», поскольку вы в любом случае фактически просто создаете свою собственную базу данных.
Чтение каталога в целом более затратно, чем чтение файла. Но если вы можете найти нужный файл без чтения каталога (т.е. не "перебирать имена файлов", а "конструировать имя файла") благодаря вашему соглашению об именовании, то разделение базы данных может оказаться полезным.
Учитывая, что ваши данные составляют 1 МБ, я бы даже подумал о том, чтобы хранить их полностью в памяти.
Чтобы дать вам некоторую подсказку по вашему вопросу, я бы считал, что наличие одного большого файла означает, что ваше приложение выполняет управление строками. Наличие нескольких маленьких файлов означает, что управление данными возлагается на систему и файловую систему. Хотя последний вариант может быть довольно медленным, поскольку он включает системные вызовы для всех ваших операций.
Все это зависит, среди прочего, от вашей файловой системы, размера блока и кеш-памяти.
Как обычно, измерьте и выясните, является ли это реальной проблемой, поскольку следует избегать преждевременной оптимизации . Может случиться так, что использование одного файла вместо множества небольших файлов не имеет большого значения для производительности на практике, и выбор должен быть основан на ясности и удобстве обслуживания.
(Что я могу сказать наверняка, так это то, что вам не следует прибегать к линейному поиску файлов, вместо этого используйте соглашение об именах, чтобы точно определить файл за время O (1)).
Открытие файла и закрытие файла в C займет много времени. Т.е. у вас есть 500 файлов по 2 КБ каждый... и если вы обработаете их, то в ваше приложение будет добавлено 1000 дополнительных операций (500 открытие файла и 500 закрытие)... в то время как наличие только 1 файла размером 1 МБ сэкономит вам эти 1000 дополнительных операций... (Это чисто мое личное мнение...)
.Вообще, лучше иметь несколько маленьких файлов. Это снижает потребление памяти и повышает производительность при поиске.
Но это зависит от количества операций, которые вам понадобятся, потому что вызовы файловой системы намного дороже по сравнению, например, с хранением в памяти.
Мне любопытно, почему вы не можете использовать БД? Я уважаю ваши предпочтения, но просто хочу убедиться, что это правильно.
Не всем БД требуется сервер для подключения или сложного развертывания. SQLite , например, можно легко встроить в ваше приложение. Он уже встроен в Python, и его очень легко подключить к коду C (сам SQLite написан на C, а его основной API - для C). SQLite управляет полнофункциональной БД в одном файле на диске, где вы можете создавать несколько таблиц и использовать все другие полезные функции БД.
Общий компромисс заключается в том, что один большой файл может быть сложнее обновлять, а множество маленьких файлов - хлопотно. Мое предложение заключается в том, что если вы используете несколько файлов, и в итоге у вас их много, это может привести к очень медленному обходу каталога с миллионом файлов в нем. По возможности разбивайте файлы на какие-то группы, чтобы их можно было помещать в отдельные каталоги и "подбирать ключи". У меня есть приложение, которое требует создания множества маленьких pdf-документов для всех пользователей системы. Если бы мы поместили это в один каталог, это было бы кошмаром, но наличие каталога для каждого пользователя делает его гораздо более управляемым.