Versione amistoso, formato de archivo binario extensible

Question

En el proyecto en el que estoy trabajando actualmente hay una necesidad de guardar una estructura de datos considerable en el disco (editar: creo docenas de MB). Siendo un optimista, pensé que debe haber una solución estándar para tal problema; Sin embargo, hasta ahora no he encontrado una solución que satisfaga los siguientes requisitos:

1. .NET 2.0 de apoyo, preferentemente con una aplicación de software libre
2. versión amigable (esto debe interpretarse como: lectura de una versión antigua del formato debería ser relativamente simple si los cambios en la estructura de datos subyacente son simples, digamos agregar/soltar campos)
3. Posibilidad de hacer alguna forma de acceso aleatorio donde parte de los datos se puede extender después de la creación inicial, sin la necesidad para deserializar la colección creada hasta este punto en el tiempo (piense en esto como extender los resultados intermedios)
4. espacio y el tiempo eficiente (XML ha sido excluido como opción dado este requisito)

Opciones considerado hasta ahora:

• XmlSerializer: fue rechazada desde la serialización XML no cumple con el requisito 3 y 4.
• SerializableAttribute: no es compatible requisitos 2 y 3.
• Protocol Buffers: fue rechazada por el veredicto de la documentación sobre Large Data Sets - ya que este comentario sugirió añadir otra capa o En la parte superior, esto requeriría una complejidad adicional que deseo haber manejado por el formato de archivo en sí.
• HDF5, EXI: no parecen tener implementaciones .NET
• SQLite/SQL Server Compact edition: la estructura de datos que nos ocupa resultaría en una estructura de tabla bastante complejo que parece demasiado peso pesado para el uso previsto
• BSON: no parece ser compatible con el requisito 3.
• Fast Infoset: solo parece haber pagado las implementaciones de .NET.

Cualquier recomendación o sugerencia es muy apreciada. Además, si crees que la información anterior no es cierta, proporciona punteros/ejemplos para demostrar que estoy equivocado.

Answer 1

¿Ha considerado usar SQL Server Compact Edition?

1. Tiene un montón de apoyo .NET
2. El control de versiones del esquema y la capacidad para las nuevas versiones de su manejo de los esquemas viejos sería totalmente en su control de aplicaciones. El control de versiones de SQL Server Compact debe ser algo parecido a lo que sucede más allá de su aplicación mediante el uso de funciones en una versión más nueva que no existía en la versión anterior.
3. Tiene la mayoría de la sintaxis SQL disponible para consultas.
4. Obviamente, a partir del nombre, esta versión de SQL Server se diseñó para sistemas integrados que pueden incluir aplicaciones que desean evitar la instalación de SQL Express o la versión completa de SQL Server.

Ahora, esto tendría los mismos problemas que SQLite en el sentido de que la estructura de datos, por lo que nos ha dicho, podría complicarse, pero eso será cierto incluso si usted tira su propio formato binario.

Por cierto, se me ocurre que no ha aclarado qué significa exactamente "considerable". Si "considerable" significa cerca de o más de 4 GB, obviamente SQL Compact no funcionará ni lo hará un host de otros formatos de archivo de base de datos.

EDIT He notado que ha agregado SQL Compact Edition a su lista de "pesados" después de mi publicación. SQL Compact requiere solo 5 MB de RAM y 2 MB de almacenamiento en disco, según el tamaño de la base de datos. Entonces, el problema no puede ser que sea pesado. Ahora, en cuanto al segundo punto de reclamar la estructura de datos sería bastante complicado. Si eso es cierto, sospecho que será cierto para cualquier producto de base de datos relacional y que enrollar su propio formato binario será aún más complicado. Dado eso, puede consultar productos de bases de datos no relacionales como mongodb.

Answer 2

¿Considerarías (B) JSON? Si es así, una de las bases de datos orientadas a documentos puede ajustarse a sus necesidades. CouchDB es una tienda de documentos JSON con una API REST (definitivamente utilizable desde .Net). Los documentos CouchDB pueden tener archivos adjuntos binarios y he hablado con personas que han almacenado archivos adjuntos multi-MB en documentos sin problemas. Creo que MongoDB, una base de datos de documentos alternativa que utiliza JSON binario como formato de almacenamiento, también tiene enlaces .Net.

Estas alternativas "NoSQL" son fácilmente versionadas porque están esencialmente libres de esquemas. JSON es bastante compacto, y ciertamente permiten actualizaciones a los datos existentes.

Answer 3

¿Ha mirado la serialización binaria?

Ver mi publicación here para más información. Tiene un código de muestra para serializar una clase personalizada contenida en un objeto de diccionario. No estoy seguro de cuán compleja es su estructura, pero debería ser bastante sencillo adaptarla a sus necesidades.

Añadir un comentario si necesita más ayuda ...

Answer 4

Si XML no cumple los requisitos debido al consumo de espacio, se podría alimentar el XML a través de una System.IO.Compression.DeflateStream para reducir su tamaño. El algoritmo Deflate es esencialmente el mismo que la compresión GZip, pero puede ser hasta un 40% más rápido (consulte Jeff Atwood's blog).

Answer 5

No cancelaría los búfers de protocolo tan rápido. Claro, la entrada manual que mencionas dice del orden de un megabyte, y estás lidiando con decenas de megabytes ... pero, ¿has probado un estudio para ver si esta limitación te impacta?

Si todavía tiene un impacto en usted, mi sugerencia es ir con un enfoque híbrido: corte y corte su conjunto de datos en trozos de tamaño de 1 MB, y luego almacene cada trozo como un campo de una tabla SQLite (como un blob binario) Agregue otros campos a la tabla para los elementos que desea indexar (o buscar por).

Sí, agrega complejidad, pero nada más parece acercarlo a donde necesita ir.

Answer 6

¿Has considerado algo así como db4o? La licencia puede restringirlo, pero de lo contrario parece ajustarse a la factura.

Answer 7

Aquí es una opción interesante para pensar: ETCH de Cisco, disponible bajo la licencia Apache (que no paga las regalías y el software se conserva comercial y los suyos.)

La idea está utilizando Etch para la comunicación entre los componentes de su sistema, en una forma binaria. El formato es resistente a los cambios de versión, y puede manejar campos faltantes, etc., según lo indique su requerimiento.

La ventaja es que obtiene un sistema de transferencia más completo, además del formato binario. Se considera muy rápido (una máquina que realiza 900 transacciones XML SOAP por segundo, realizó 50,000 transacciones de ETCH).

Puede almacenar el formulario binario en un RDBMS liviano si necesita varios índices. Si solo un índice fuera suficiente, entonces un simple almacén de claves/valores (CouchDB/MongoDB o incluso Cassandra para entornos distribuidos) también le brindaría un maravilloso rendimiento de almacenamiento.