Хранение больших объемов данных в файлах. Какова самая производительная опция?

Что такое данные?

С xml очевидным ответом было бы использование сглаживания типа GZipStream для их сжатия - делая его меньше и темнее. Вы можете использовать BinaryFormatter , но он хрупкий и IMO не подходит для длительного хранения. Я бы сказал «буферы протокола» (возможно, protobuf-net), но это зависит от того, что это за «пользовательские данные». Но если вы используете XmlSerializer в настоящий момент, protobuf-net может работать виртуально без изменений (возможно, добавить несколько атрибутов) - и это (во всех случаях, которые я видел до сих пор ) и меньше, и быстрее, чем BinaryFormatter .

Вот крутая кривая обучения (см. Также: Начало работы ):

[ProtoContract]
public class Person {
    [ProtoMember(1)]
    public int Id {get;set;}

    [ProtoMember(2)]
    public string Name {get;set;}

    //...
}

Честно говоря, это может стать немного сложнее, если вы используете наследование - хотя и не намного. . Во многих случаях вы действительно можете использовать свои существующие атрибуты - они будут работать с атрибутами xml / wcf, если включен явный порядок элементов.

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

Необходимо только перегрузить функцию ToString в объекте, например

public override string ToString()
{
    /* some code handling here */
    return ""; //your own formated string
}

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

Я бы попытался использовать как можно больше существующих форматов:
http://blog.stevex.net/string-formatting-in-csharp/

Я согласен с Am об использовании встроенной базы данных, такой как SQLite. Это дает значительные преимущества. Возможность укладки ORM поверх него, вероятно, наиболее значима.

Сериализация XML удобна, особенно если требуется редактировать XML вручную или обрабатывать его с помощью других инструментов XML, таких как XSLT и т.д., но при этом возникают некоторые неизбежные проблемы с производительностью. Одним из важных методов использования сериализации XML в .Net является кэширование сериализаторов XML. Или создать их sgen при построении.

Причина кэширования сериализатора XML связана с тем, что среда выполнения .Net автоматически создает, компилирует и загружает сборку, содержащую сериализатор, если она не может найти его в уже загруженной сборке. Этот процесс может быть действительно медленным. Кроме того, создание нового экземпляра XMLSerializer может быть довольно медленным. Следовательно, почему вы должны кэшировать его. Будьте осторожны при кэшировании сериализатора, хотя различные конструкторы XMLSerializer могут создавать различные реализации сериализатора, которые ведут себя по-разному. В частности, в отношении пространств имен и т.д.

Тогда, конечно, есть обычные последствия производительности разбора большого количества текста. К сожалению, этого нелегко избежать с помощью XML.

Одна из причин, по которой SQLite является лучшим выбором, чем XML, связана с тем, что в его основе лежит система места хранения записей фиксированной длины. Любой двоичный файл с записями фиксированной длины будет быстро считываться, индексироваться и сканироваться. Форматы файлов фиксированного размера блоков почти всегда быстро читаются и записываются. Я бы рекомендовал внедрить один в какой-то момент для вашего собственного образования.

Если вы по-прежнему хотите текстовый формат (для удобства взаимодействия) и не нуждаетесь в преимуществах ORM, попробуйте использовать библиотеку FileHelpers .