版本控制友好,可扩展的二进制文件格式

在我正在进行的项目中,需要将大量的数据结构保存到磁盘(编辑:想想几十MB).作为一个乐观主义者,我认为必须有一个标准的解决方案来解决这个问题; 但是,到目前为止,我还没有找到满足以下要求的解决方案:

.NET 2.0支持,最好是FOSS实现

版本友好(这应该解释为:如果底层数据结构中的更改很简单,例如添加/删除字段,则读取旧版本的格式应该相对简单)

能够进行某种形式的随机访问,其中部分数据可以在初始创建后进行扩展,而无需反序列化到目前为止创建的集合(将其视为扩展中间结果)

节省空间和时间(根据此要求,XML已被排除在选项之外)

目前考虑的选项:

XmlSerializer:由于xml序列化不符合要求3和4而被拒绝.

SerializableAttribute:不支持要求2和3.

协议缓冲区:由于关于大数据集的文档的判断被拒绝- 因为这个评论建议在顶部添加另一层,这将需要额外的复杂性,我希望由文件格式本身处理.

HDF5,EXI:似乎没有.net实现

SQLite/SQL Server Compact版本:手头的数据结构会导致一个非常复杂的表结构,对于预期用途来说似乎太重了

BSON:似乎不支持要求3.

Fast Infoset:似乎只付了.NET实现.

非常感谢任何建议或指示.此外,如果您认为上述任何信息都不正确,请提供指示/示例以证明我的错误.

您是否考虑过使用SQL Server Compact Edition？

它有很多.NET支持

架构的版本控制以及处理旧架构的应用程序的新版本的能力将完全由您控制.除了旧版本中不存在的较新版本的功能之外,SQL Server Compact的版本控制在您的应用程序之外应该是有些无用的.

您可以使用大部分SQL语法进行查询.

显然,从这个名称来看,这个版本的SQL Server是为嵌入式系统设计的,其中包括希望避免安装SQL Express或SQL Server完整版本的应用程序.

现在,这将与SQLite具有相同的问题,因为您告诉我们的数据结构可能会变得复杂,但即使您使用自己的二进制格式也是如此.

顺便说一下,我发现你还没有弄清楚"大小"究竟是什么意思.如果"sizeable"意味着接近或超过4 GB,显然SQL Compact将不起作用,也不会有许多其他数据库文件格式.

编辑我注意到你在我的帖子之后将SQL Compact Edition添加到了"太重量级"列表中.SQL Compact仅需要5MB的RAM和2MB的磁盘存储空间,具体取决于数据库的大小.所以,问题不能是重量级的.现在,关于声称数据结构的第二点将非常复杂.如果这是真的,我怀疑任何关系数据库产品都是如此,滚动你自己的二进制格式将更加复杂.鉴于此,您可以查看非关系数据库产品,例如mongodb.