El almacén de datos pequeño más rápido en Windows

Question

Mi aplicación realiza un seguimiento del estado de aproximadamente 1000 objetos. Esos objetos se leen y se escriben en un almacén persistente (serializado) en ningún orden en particular.

En este momento, la aplicación utiliza el registro para almacenar el estado de cada objeto. Esto es bueno porque:

• Es simple

• Es muy rápido

• El estado del objeto individual se puede leer / escribir sin necesidad de leer una entidad más grande (como extraer un fragmento de un archivo XML grande)

• Hay un editor decente (RegEdit) que permite manipular fácilmente elementos individuales

Habiendo dicho eso, me pregunto si hay una mejor manera. SQLite parece una posibilidad, pero no tiene el mismo nivel de múltiples lectores / escritores múltiples que obtiene con el registro, y no hay una forma sencilla de editar entradas existentes.

¿Alguna sugerencia mejor? Un montón de archivos planos?

Answer 1

Si comienzas a experimentar con SQLite, deberías saber que " fuera de la caja " Puede que no parezca tan rápido como quisiera, pero se puede hacer que sea mucho más rápido aplicando algunos consejos de optimización establecidos:

optimización de SQLite

Dependiendo del tamaño de los datos y la cantidad de RAM disponible, una de las mejores ganancias de rendimiento se producirá al configurar sqlite para que use una base de datos de memoria en lugar de escribir en el disco.

Para las bases de datos en memoria, pase NULL como el argumento de nombre de archivo a sqlite3_open y asegúrese de que TEMP_STORE esté correctamente definida

Por otra parte , si le dices a sqlite que use el disco duro, obtendrás un beneficio similar a tu uso actual de RegEdit para manipular los datos del programa "al vuelo".

La forma en que podría simular su técnica RegEdit actual con sqlite sería utilizar la herramienta de línea de comandos sqlite para conectarse a la base de datos en disco. Puede ejecutar instrucciones UPDATE en los datos de SQL desde la línea de comandos mientras su programa principal se está ejecutando (y / o mientras está en pausa en modo de interrupción).

Answer 2

Si lo que quiere decir con 'lector múltiple / escritor múltiple' es que mantiene una gran cantidad de subprocesos que se escriben en la tienda al mismo tiempo, SQLite es seguro para los hilos (puede tener SELECT simultáneos y las escrituras simultáneas se manejan de manera transparente). Consulte [FAQ [1]] y grep para 'threadsafe'

[1]: http://www.sqlite.org/faq.html/ Preguntas frecuentes

Answer 3

Dudo que alguna persona sana vaya por este camino en estos días, sin embargo, parte de lo que describe se podría hacer con el Almacenamiento estructurado / compuesto . Solo menciono esto porque estás preguntando sobre Windows , y esta es / fue una forma oficial de Windows para hacer esto.

Así es como se agruparon los archivos DOC (pero no el nuevo formato DOCX). Desde MSDN parecerá realmente complicado, pero lo he usado, no es la API peor en Win32.

• es no simple
• es rápido, supongo es más rápido que el registro.
• El estado del objeto individual se puede leer / escribir sin necesidad de leer una entidad más grande.
• No hay un editor decente, sin embargo, hay algunas cosas básicas reales (VC ++ 6.0 tenía el " Visor de DocFile " en Herramientas. (sí, eso es lo que hizo) encontré un pocos más en línea.
• Obtienes un archivo en lugar de las claves de registro.
• Ganas un poco de geek-cred del desarrollador de Windows de la vieja escuela.

Otros pensamientos aleatorios: Creo que XML es el camino a seguir (a pesar del problema de acceso aleatorio). Heck, los archivos INI pueden funcionar. El registro le brinda seguridad de grano fino si lo necesita; la gente parece olvidar esto cuando la reclamación de archivos es mejor. Una base de datos incrustada parece una exageración si entiendo lo que estás haciendo.

Answer 4

¿Necesita conservar los objetos en cada evento de cambio o solo en la memoria y almacenar en el apagado? Si es así, simplemente cárguelos y serialícelos al final, suponiendo que su aplicación se ejecute durante mucho tiempo (y no comparta ese estado con otro programa), en la memoria será un ganador.

Si tienes estructuras de tamaño fijo, ¿podrías considerar simplemente usar un archivo asignado en memoria y asignar memoria a partir de eso?

Answer 5

Si lo único que hace es serializar / deserializar objetos individuales (sin consultas extravagantes), use una base de datos btree, por ejemplo Berkeley DB . Es muy rápido para almacenar y recuperar fragmentos de datos por clave (supongo que sus objetos tienen algún ID que puede usarse como clave) y el acceso por múltiples procesos es compatible.