Управление версиями дружественный, растяжимый формат двоичного файла
В проекте я в настоящее время продолжаю работать существует потребность сохранить значительную структуру данных на диск (редактирование: думайте десятки МБ). Будучи оптимистом, я думал, что должно быть стандартное решение для такой проблемы; однако, до сих пор я не нашел решение, которое удовлетворяет следующие требования:
- .NET 2,0 поддержки, предпочтительно с реализацией FOSS
- Дружественная версия (это должно быть интерпретировано как: чтение старой версии формата должно быть относительно простым, если изменения в базовой структуре данных просты, говорят добавление/отбрасывание полей),
- Способность сделать некоторую форму произвольного доступа, где часть данных может быть расширена после начального создания без потребности десериализовать набор, созданный до этого момента времени (думают об этом как расширяющий промежуточные результаты),
- Эффективное пространство и время (XML был исключен как опция, учитывая это требование),
Возможности рассмотрены до сих пор:
- XmlSerializer: выключался, так как XML-сериализация не встречает требование 3 и 4.
- SerializableAttribute: не поддерживает требования 2 и 3.
- Буферы протокола: выключался вердиктом документации о Больших Наборах данных - так как этот комментарий предложил добавить другой слой на вершине, это призовет к дополнительной сложности, которую я хочу обработать самим форматом файла.
- HDF5, EXI: кажется, не имею реализации .NET
- Сервер SQLite/SQL Компактный выпуск: структура данных под рукой привела бы к структуре довольно сложной таблицы, которая кажется слишком тяжелой для надлежащего использования
- BSON: кажется, не поддерживает требование 3.
- Fast Infoset: только, кажется, заплатил реализации.NET.
Любые рекомендации или указатели значительно ценятся. Кроме того, если Вы полагаете, что любая информация выше не верна, обеспечьте указатели/примеры для доказательства меня неправильно.
7 ответов
Рассматривали ли вы возможность использования SQL Server Compact Edition ?
- В нем много поддержки .NET.
- Управление версиями схемы и способность новых версий вашего приложения обрабатывать старые схемы будут полностью под вашим контролем. Управление версиями SQL Server Compact должно быть несколько незаметным за пределами вашего приложения, использующего функции в новой версии, которых не было в старой версии.
- У вас есть большая часть синтаксиса SQL, доступного для выполнения запросов.
- Судя по названию, эта версия SQL Server была разработана для встроенных систем, которые могут включать приложения, которые хотят избежать установки SQL Express или полной версии SQL Server.
Это будет иметь те же проблемы, что и SQLite, в том смысле, что структура данных, из того, что вы нам сказали, может стать сложной, но это будет верно, даже если вы создадите собственный двоичный формат.
Между прочим, мне приходит в голову, что вы не разъяснили, что именно подразумевается под «значительным». Если «размерный» означает около или более 4 ГБ, очевидно, что SQL Compact не будет работать, как и множество других форматов файлов баз данных.
РЕДАКТИРОВАТЬ Я заметил, что вы добавили SQL Compact Edition в свой список «слишком тяжеловесных» после моего сообщения. SQL Compact требует всего 5 МБ ОЗУ и 2 МБ на диске в зависимости от размера базы данных. Так что проблема не может быть в том, что это тяжеловес.Теперь, что касается второго пункта, заявить о структуре данных было бы довольно сложно. Если это так, то я подозреваю, что это будет верно для любого продукта реляционной базы данных, и создание собственного двоичного формата будет еще более сложным. Учитывая это, вы можете посмотреть на продукты нереляционных баз данных, такие как mongodb .
Вы смотрели двоичную сериализацию?
См. Мою пост здесь для получения дополнительной информации. В нем есть образец кода для сериализации настраиваемого класса, содержащегося в объекте Dictionary. Не уверен, насколько сложна ваша структура, но она должна быть довольно простой, чтобы адаптировать ее к вашим потребностям.
Добавьте комментарий, если вам нужна дополнительная помощь ...
Вы бы рассмотрели (B) JSON? Если да, то одна из баз данных, ориентированных на документы, может соответствовать вашим потребностям. CouchDB - это хранилище документов JSON с REST API (определенно можно использовать из .Net). Документы CouchDB могут иметь двоичные вложения, и я разговаривал с людьми, которые без проблем хранили вложения размером в несколько МБ. Я считаю, что MongoDB , альтернативная база данных документов, которая использует двоичный JSON в качестве формата хранения, также имеет привязки .Net.
Эти альтернативы "NoSQL" легко версируются, потому что они по сути свободны от схемы. JSON довольно компактен, и они, безусловно, позволяют обновлять существующие данные.
Я бы не стал так быстро списывать со счетов протокольные буферы. Конечно, в ручном вводе, на который вы ссылаетесь, говорится о порядке мегабайта, а вы имеете дело с десятками мегабайт ... но пробовали ли вы провести исследование, чтобы узнать, влияет ли это ограничение на вас?
Если оно все еще влияет на вас? я предлагаю использовать гибридный подход: нарезать и нарезать ваш набор данных на фрагменты размером 1 МБ, а затем сохранить каждый фрагмент как поле таблицы SQLite (как двоичный blob). Добавьте в таблицу другие поля для элементов, которые вы хотите проиндексировать (или выполнить поиск).
Да, это добавляет сложности, но ничто другое не приближает вас к тому месту, куда вам нужно идти.
Если XML не соответствует требованиям из-за занимаемого места, вы можете передать XML через System.IO.Compression.DeflateStream чтобы уменьшить его размер. Алгоритм Deflate по сути такой же, как сжатие GZip , но может быть на 40% быстрее (см. блог Джеффа Этвуда ).
Думали ли вы о чем-то вроде db4o ? Лицензирование может ограничивать вас, но в противном случае оно, похоже, отвечает всем требованиям.
Вот интересный вариант, о котором можно подумать: ETCH от Cisco, доступный по лицензии Apache (вы не платите роялти, и ваше программное обеспечение остается коммерческим и вашим.)
Идея заключается в использовании Etch для связи между компонентами вашей системы, в двоичной форме. Формат устойчив к изменениям версии и может обрабатывать отсутствующие поля и т. Д. В соответствии с вашими требованиями.
Преимущество состоит в том, что вы получаете более полную систему передачи поверх двоичного формата. Считается очень быстрой (машина, выполняющая 900 транзакций SOAP XML в секунду, совершила 50 000 транзакций ETCH).
Вы можете сохранить бинаризованную форму в облегченной СУБД, если вам нужно несколько индексов. Если бы было достаточно всего одного индекса, то простое хранилище ключей / значений (CouchDB / MongoDB или даже Cassandra для распределенных сред) также обеспечило бы отличную производительность хранилища!