В продолжение вопросаяспросил наПереполнение стекасуществуют ли файловые системы, в которых данные записываются «концом вперед» или «снизу вверх», а не сверху вниз?
В частности, я ищу (возможно, специально созданный) способ хранения файлов журналов в форме «сначала самые последние» (а-лякак организованы блоги и новостные сайты (самые свежие наверху).
Существует ли такой зверь? Если да, то что это и где его можно найти?
решение1
То, что вы просите, это не просто «обратная» файловая система. Вы хотитеструктурированный по записи, «обратная» файловая система, т. е. файловая система записей, где запись, добавленная последней, появляется первой в файле. Фактически обратный аспект, вероятно, будет реализован как «вы можете вставить запись перед первой существующей записью».
Интерфейсы файловой системы, которые обычно встречаются в операционных системах ПК (Unix, Windows и даже более экзотические), имеют только байтовую структуру — у них нет понятия записи. Так что вам не повезло.
Один из возможных подходов — сделать каждую запись журнала отдельным файлом в каталоге. Затем пройдитесь по каталогу в обратном порядке времени создания файла или в обратном порядке имен, если вы даете монотонно увеличивающиеся имена записям журнала. Поскольку у вас, скорее всего, будет большое количество записей журнала, либо убедитесь, что используете файловую систему, которая хорошо поддерживает большие каталоги (например, в Linux reiserfs и ext3 с этой dir_indexфункцией подходят, а ext2 — нет), либо используйте подкаталоги (один для первых 1000 записей, один для следующих 1000 и т. д.).
Другой подход — использовать более сложную базу данных, например, такую, к которой можно выполнять запросы в SQL, и просто выбирать записи в порядке, обратном их созданию ( SELECT message FROM logs ORDER BY date DESC).
решение2
Я не совсем уверен, что их вообще нет, но я точно никогда о них не слышал. Если их можно сделать, я думаю, что будут некоторые существенные недостатки.
Для добавления в файл обычно требуется полная копия существующих данных. В файловой системе вы можете справиться с этим, добавив блок в начало файла, но это все равно вызовет несколько незначительных проблем. Блоки со свободным пространством должны будут сохранять свободное пространство в начале, поэтому, скорее всего, потребуется дополнительный поиск со стороны диска, чтобы найти правильное местоположение.
Обработка свободного пространства на диске при работе в обратном направлении стала бы большой головной болью. Это противоречило бы большинству методов программирования, поскольку вам пришлось бы найти максимальный индекс, а затем работать оттуда.
Я могу себе представить, что это замедлит работу с большими файлами, и это определенно будет нелепо для программирования.
Вместо того, чтобы искать обратную файловую систему, почему бы вам просто не записать файл как обычно и разобрать его в обратном порядке? Разработайте базовую схему форматирования сообщений, прочитайте файл и разберите сообщения из него, затем отобразите их последними к первым. Если вам нужны только последние сообщения, ищите до конца файла, а затем обратнонсообщения. Это дало бы аналогичный результат, но с гораздо меньшими усилиями и сопоставимой или лучшей производительностью.
решение3
Вам нужно разделить идеихранилищеиизвлечение. Даже в блогах, которые вы упомянули, записи, скорее всего,хранитсяв прямом хронологическом порядке, ноотображаетсяв обратном хронологическом порядке (игнорируя тот факт, что это упрощается при использовании структурированного хранения).
Можно было бы, по идее, создать упрощенную структурированную систему хранения, которая хранила бы записи в привычном прямом порядке с «записями» свободной формы и переменной длины с указателями смещения байта, хранящимися в файле ресурсов в формате фиксированной длины (64 бита будут поддерживать файлы размером более 18 миллионов терабайт). Поиск последней записи или nthзаписи last - nв файле указателя, а затем байта, на который она указывает в основном файле, был бы тривиальным и быстрым. Хитрость, которую позволила бы специальная файловая система или драйвер, состояла бы в том, чтобы сделать это атомарным и сделать файл ресурсов прозрачным.
решение4
На ум приходят две мысли:
Некоторые системы контроля версий хранят первую версию контролируемого файла полностью, а все последующие версии — как изменения, тогда как другие хранят текущую версию контролируемого файла полностью, а все предыдущие версии — как изменения.
Если вы записываете события времени выполнения в базу данных, а не в плоский файл, вам может быть неясно, сохраняет ли база данных события последовательно, в обратном порядке или беспорядочно.