2010-01-17 13 views
21

Estoy pensando en usar/implementar algún tipo de almacén de valor-clave (o documento) incrustado para mi aplicación de escritorio de Windows. Quiero poder almacenar varios tipos de datos (las pistas de GPS serían un ejemplo) y, por supuesto, poder consultar estos datos. La cantidad de datos sería tal que no podría ser cargada en la memoria al mismo tiempo.Almacén de datos incrustado no relacional (nosql)

Estoy pensando en usar sqlite como motor de almacenamiento para una tienda de valores-clave, algo así como y-serial, pero escrito en .NET. También he leído sobre FriendFeed's usage of MySQL to store schema-less data, que es un buen puntero sobre cómo usar RDBMS para datos no relacionales. sqlite parece ser una buena opción debido a su simplicidad, portabilidad y tamaño de biblioteca.

Mi pregunta es si hay otras opciones para una tienda incrustada no relacional? No necesita ser distribuible y no tiene que admitir transacciones, pero tiene que ser accesible desde .NET y debe tener un tamaño de descarga pequeño.

ACTUALIZACIÓN: He encontrado un artículo titulado SQLite as a Key-Value Database que compara sqlite con Berkeley DB, que es una biblioteca de almacenamiento de clave-valor incorporada.

Respuesta

5

Personalmente, me gustaría ir a SQLite con NHibernate (y Fluent NHibernate). NHibernate puede generar el esquema de la base de datos automáticamente para sus clases, por lo que solo debe especificar qué clases desea que persistan, y eso es bastante fácil con Fluent NHibernate. Además, puede buscar objetos específicos y no necesita cargar todos los datos en la memoria.

+0

Pero quería una tienda sin esquema ... –

+0

Astor tiene razón: quiero evitar el modelo relacional. Quiero poder almacenar prácticamente cualquier tipo de datos sin tener que preparar primero el esquema de la base de datos. Además, tener un modelo relacional estricto puede ser problemático si la estructura de datos cambia más tarde. Tendría que escribir scripts de cambios SQL para los datos existentes en la tienda. –

+1

Sé lo que está buscando, pero herramientas como NHibernate con generación de esquema ocultan el aspecto relacional casi por completo. No necesita definir ningún esquema, sino solo el mapeo para sus clases (lo que es realmente directo con Fluidez NHibernate) y cuando cambien sus clases, necesitará hacer algún tipo de actualización en cualquier estrategia de persistencia. –

19

Windows tiene una tienda incorporada no relacional. Se llama ESENT y es utilizado por varias aplicaciones de Windows, incluidas Active Directory y Windows Desktop Search.

http://blogs.msdn.com/windowssdk/archive/2008/10/23/esent-extensible-storage-engine-api-in-the-windows-sdk.aspx

Si desea .NET de acceso que puede utilizar la capa ManagedEsent en CodePlex.

http://managedesent.codeplex.com/

Ese proyecto tiene una clase que implementa PersistentDictionary un almacén de claves-valor que implementa la interfaz IDictionary, pero con el respaldo de una base de datos.

+0

@Laurion, he visto ESENT y al principio estaba muy emocionado. El único problema es que es solo para Windows (piense en Mono + Linux/Mac). –

2

Aplicando el principio de KISS a su problema, le recomendaría que use archivos.

Como en nombre de archivo es la clave. El contenido del archivo es el valor. La carpeta de Windows es el índice.

Simple, rápido, eficiente, flexible y a prueba de tontos (siempre que los tontos tengan poca inteligencia).

+0

Buen enfoque, aunque creo que usar archivos para almacenar valores sería un poco exagerado para valores simples (un solo entero, por ejemplo). –

+0

El tipo de pregunta implica que lo que se está almacenando puede ser bastante grande (documentos/demasiados datos para cargar en la memoria). Una de las ventajas del enfoque de archivos es que obtienes un buen conjunto de clases de manejo de Stream de forma gratuita, lo que es muy útil cuando se trata de grandes cantidades de datos y mucho más limpio que, por ejemplo, dividir datos en blobs arbitary nMB y almacenarlos en un base de datos. –

+2

Es cierto. ¿Qué pasa con los límites físicos del sistema de archivos? ¿Cómo se comportaría tal tienda cuando la cantidad de registros alcanza> 100.000? También: cuando hablé de "demasiados datos", me refería a la base de datos _toda_; mencioné esto para evitar respuestas como la serialización de árbol de objetos y similares. –

1

Gracias por su mención tipo de y_serial ... más precisamente, se trata de un módulo de Python:

objetos del almacén Python con SQLite

"serialización + persistencia :: en unas pocas líneas de código, comprimir y anotar objetos de Python en SQLite, y luego recuperarlos cronológicamente por palabras clave sin ningún SQL. Módulo "estándar" más útil para que una base de datos almacene datos sin esquema."

http://yserial.sourceforge.net

En mi experiencia, SQLite es una opción más rápida y más fiable que la mayoría de las bases de datos (incluyendo PostgreSQL y Berkeley DB) para la mayoría de los proyectos - y, por supuesto, que no necesita un demonio del servidor .

yserial es muy fácil de implementar (y mucho más rápido que el "nombre de archivo es el contenido de clave/valor de archivos es el" enfoque ;-)

+0

Sí, realmente me gusta el enfoque de y-serial, especialmente porque usa sqlite. Sigan con el buen trabajo! Tal vez cuando tenga algo de tiempo de mis otros proyectos, intentaré hacer algo similar en C# :) –

2

Podría crear una base de datos SQLite simple con dos columnas:

==documents== 
id|data 

y los datos serían datos json.

También puede crear una tabla de claves que serían:

==keys== 
keyname|keyvalue|id 

que se indexa el nombre de clave y valor clave para búsquedas rápidas.

Un único archivo db podría ser una colección, y podría crear múltiples archivos db para múltiples colecciones.

usted podría utilizar carpetas como "DBS" para que coincida con la jerarquía de mongodb de db-> colección-> documento

+0

Solo una nota: crearías una plantilla sqlite db, y la copiarías para cuando necesites crear una nueva colección . Si alguien quiere crear una configuración de php para manejar esto y abrirlo, avíseme. Creo que sería genial, pero nunca me molesté en hacerlo yo mismo. – RobKohr

+0

sus sugerencias están en la dirección de cómo y-serial hace las cosas. ¿Lo has visto? http://yserial.sourceforge.net/ –

+0

No, pero estoy buscando una solución de php yo mismo. – RobKohr

10

Tome un vistazo a RavenDB. Parece como si se puede encajar y es sin esquema y trabaja con .NET

Desde el sitio web:

  • infraestructura escalable Raven se acumula en la parte superior de la existente, probada y escalable infraestructura
  • configuración simple de Windows : Raven es simple de configurar y ejecutar en Windows como servicio o en el sitio web de IIS7
  • Transaccional: sistema de soporte de Raven. Transacción con transacciones ACID. Si coloca datos en él, esos datos permanecerán allí
  • Mapa/Reducir: defina fácilmente mapas/reduzca índices con consultas de Linq
  • .NET Client API: Raven viene con una API de cliente .NET totalmente funcional que implementa unidad de trabajo y mucho más
  • REST: Raven está construido alrededor de una API REST
2

Ésta es una vieja pregunta, pero pensé que me gustaría añadir una respuesta en caso de que alguien se topa con él. Mi empresa acaba de lanzar una base de datos XML de fuente abierta para la plataforma .NET llamada Nxdb. Está bajo la licencia de Apache 2.0 y ha estado en desarrollo y uso internamente durante varios años. Básicamente es un enlace a una versión compilada cruzada (usando IKVM) de BaseX (una fantástica base de datos Java XML) junto con una funcionalidad adicional para el caso de uso integrado y el entorno .NET. La página del proyecto está aquí: https://dracorp.assembla.com/spaces/nxdb

XML funciona bien para este tipo de almacén de datos dado que mientras el contenido que intenta almacenar sea serializable en texto puede almacenar árboles jerárquicos complejos. De hecho, si accede directamente a la base de datos, ni siquiera tiene que tocar "XML". También se puede consultar con XQuery, un lenguaje de consulta completo y potente.

1

Puedes probar este https://github.com/mdsoftware/mData. Pequeño, gratis y bastante inusual.Lenguaje de consulta de datos tipo Lisp, compilador de expresiones, serialización binaria de alto rendimiento, todo incluido.

Cuestiones relacionadas