2010-05-07 3 views
1

У нас есть простой формат двоичного файла для кэширования данных в нашем приложении (C# .NET Windows App). Формат в основном является коротким, который указывает тип объекта, за которым следует указатель (строка) для идентификатора объекта, а затем любые объектно-ориентированные данные (любые строки). Мы хотим иметь возможность хранить много объектов в одном файле (> 10000), но в определенных ситуациях загружать только по требованию. Решение состоит в том, чтобы сохранить индекс расположения объектов в файле - поэтому, когда мы начинаем писать новый объект, мы записываем позицию в потоке файла, с которого начинается объект. Когда мы хотим загрузить этот объект, мы используем это индексированное местоположение для загрузки релевантных данных. Это прекрасно работает.Загрузка определенного раздела сжатого потока файлов

Однако, если мы хотим сжать файл, будет ли этот метод по-прежнему возможен? Я не слишком горячий, как работает сжатие, и особенно класс GZipStream (System.IO.Compression), который мы планируем использовать. Насколько я понимаю, этот класс не поддерживает свойство Seeking или Position. Будет ли все еще возможно использовать Seek и Position основного FileStream (я предполагаю, что нет)? В принципе, возможно ли иметь сжатый файл, который мы можем выборочно загружать, если да, то как это сделать?

Спасибо,

Стив

ответ

1

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

0

Это не верно Seek, но решение будет:

  • держать след вашей позиции в файле (возможно, лучше всего сделать путем внедрения «myBinaryReader», который наследуется от BinaryReader)
  • , если вы ищете позицию с вашего текущего положения - ReadBytes, пока вы не доберетесь туда.
  • Если вы ищете позицию до текущей позиции - откройте файл для распакованного чтения (которое сбрасывает текущую позицию до нуля), а затем ReadBytes, пока вы не доберетесь до того места, где вы хотите быть.

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

В идеале базовый класс дефлята будет изменен для поддержки истинного Seeks.

0

лучшее решение:

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

После этого вы можете обеспечить поддержку базового потока дисков Seeks.

Смежные вопросы