2010-08-23 13 views
9

¿Hay algún sistema de archivos basado en la implementación B + Tree en C# (código abierto). He encontrado algunos proyectos, pero esos no son implementaciones basadas en archivos (disco). Estoy buscando específicamente B + Trees basado en el sistema de archivos.Implementación B + Tree del sistema de archivos en C#

+0

¿Qué ... está demasiado localizado ...? vamos chicos – RameshVel

Respuesta

10

Actualización:

he añadido algunos benchmarks of managed B-Tree implementations para su disfrute si se mira en este tipo de cosas.

BplusDotNet "... es conocido por ser un poco buggy eliminaciones"

me pareció todo lo contrario para ser verdad, RaptorDB 1.6 fue corrompiendo Estado y BplusDotNet 1.0.2082.16942 parecía funcionar bastante bien .

original:

Para completar voy a añadir mi propia aplicación aquí.

+0

Puedo confirmar que BPlusTree HACE datos corruptos al leer a través de un serializador personalizado serializador. Entities tiene HMACs basados ​​en SHA256 incorporados para las autoverificaciones y fallarían 1: 50K veces (los flujos IO se cerrarían prematuramente). También se reduce el rendimiento, por lo que leer las últimas entidades del 10% es MUCHO más lento que leer el primer 10%. Los problemas desaparecieron cuando realizamos la misma serialización de T => byte [] fuera de BPlusTree y BPlusTree usa PrimitiveSerializer.Bytes para trabajar con solo byte [] en lugar de una entidad personalizada. Proyecto probablemente muerto dado que NuGet no ha visto ningún lanzamiento en 1.5 años. – DeepSpace101

+0

@ DeepSpace101 ¿puede compartir su implementación del ISerializer? Sospecho que tu problema posiblemente esté allí. El BPlusTree se encuentra actualmente en uso en varias ofertas comerciales y ha demostrado ser confiable como usted indica que experimentó al usar el byte [] y el serializador incorporado. En cuanto al proyecto está muerto, ciertamente puedo entender la impresión, ya que no he hecho ninguna mejora significativa en mucho tiempo. Me complace ayudarlo a usted y a otros con eso, solo escríbame un correo electrónico roger @ mi nombre de usuario. –

+0

Le enviaremos un correo electrónico, pero la causa raíz fue que el serializador tenía una convención de que end-of-stream = end of object.Esa convención/suposición se rompió en la interfaz 'T ReadFrom (Stream stream)', lo que da como resultado que se lean más bytes (más allá del 'final'), eliminando las sumas de comprobación de cifrado. – DeepSpace101

Cuestiones relacionadas