Le plus petit datastore sous Windows

Question

Mon application garde la trace de l'état d'environ 1000 objets. Ces objets sont lus et écrits dans un magasin persistant (sérialisé) sans ordre particulier.

À l'heure actuelle, l'application utilise le registre pour stocker l'état de chaque objet. C'est bien parce que:

• C’est simple

• C'est très rapide

• L'état d'un objet individuel peut être lu / écrit sans qu'il soit nécessaire de lire une entité plus grande (comme extraire un extrait de code d'un fichier XML volumineux)

• Il existe un éditeur décent (RegEdit) qui permet de manipuler facilement des éléments individuels

Cela dit, je me demande s’il existe un meilleur moyen. SQLite semble être une possibilité, mais vous n’avez pas le même niveau de lecteurs / graveurs multiples que vous obtenez avec le registre, et aucun moyen simple de modifier les entrées existantes.

Avez-vous de meilleures suggestions? Un tas de fichiers plats?

Answer 1

Si vous commencez à expérimenter SQLite, sachez que "out of the box" " cela ne semble peut-être pas aussi rapide que vous le souhaiteriez, mais vous pouvez le faire beaucoup plus rapidement en appliquant certains conseils d'optimisation établis:

Optimisation SQLite

En fonction de la taille des données et de la quantité de RAM disponible, l'un des meilleurs gains de performances sera obtenu en définissant sqlite pour utiliser une base de données entièrement en mémoire plutôt qu'en écriture sur le disque.

Pour les bases de données en mémoire, transmettez NULL comme argument de nom de fichier à sqlite3_open et à assurez-vous que TEMP_STORE est défini correctement

D'un autre côté , si vous demandez à sqlite d'utiliser le disque dur, vous obtiendrez un avantage similaire à votre utilisation actuelle de RegEdit pour manipuler les données du programme "à la volée".

Pour simuler votre technique RegEdit actuelle avec sqlite, vous utiliseriez l'outil de ligne de commande sqlite pour vous connecter à la base de données sur disque. Vous pouvez exécuter des instructions UPDATE sur les données SQL à partir de la ligne de commande lorsque votre programme principal est en cours d'exécution (et / ou lorsqu'il est suspendu en mode pause).

Answer 2

Si vous entendez par «lecteurs multiples / écrivains multiples», vous gardez plusieurs threads écrivant simultanément dans le magasin, SQLite est threadsafe (vous pouvez avoir des commandes SELECT simultanées et des écritures simultanées gérées de manière transparente). Voir la [FAQ [1]] et grep pour 'threadsafe'

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

Answer 3

Je doute qu'une personne saine d'esprit se rende dans cette voie ces jours-ci. Toutefois, une partie de ce que vous décrivez pourrait être réalisée à l'aide de Stockage structuré / composé . Je ne fais que mentionner cela car vous parlez de Windows - et c’est / était une façon officielle de Windows de le faire.

Voici comment les fichiers DOC ont été assemblés (mais pas le nouveau format DOCX). Cela semble très compliqué pour MSDN, mais je l’utilise, ce n’est pas la pire API de Win32.

• ce n'est pas simple
• c'est rapide, je devinerai c'est plus rapide que le registre.
• L'état d'un objet individuel peut être lu / écrit sans avoir besoin de lire une entité plus grande.
• Il n’existe pas d’éditeur correct, mais il existe quelques éléments de base (VC ++ 6.0 avait le "DocFile Viewer" sous Outils. (oui, c’est ce que cette chose a fait). J'ai trouvé un peu plus en ligne.
• Vous obtenez un fichier à la place des clés de registre.
• Vous gagnez un geek-cred de développeur Windows de la vieille école.

Autres pensées aléatoires: Je pense que XML est la voie à suivre (malgré le problème de l'accès aléatoire). Heck, les fichiers INI peuvent fonctionner. Le registre vous donne une sécurité de grain très fine si vous en avez besoin - les gens semblent l'oublier lorsque la revendication utilisant des fichiers est meilleure. Une base de données intégrée peut sembler excessive si je comprends ce que vous faites.

Answer 4

Devez-vous conserver les objets à chaque événement de modification ou seulement en mémoire et les stocker à l’arrêt? Si tel est le cas, chargez-les et sérialisez-les à la fin, en supposant que votre application fonctionne longtemps (et que vous ne partagez pas cet état avec un autre programme), alors en mémoire, vous gagnerez.

Si vous avez des structures de taille fixe, vous pouvez envisager d'utiliser simplement un fichier mappé en mémoire et d'allouer de la mémoire à partir de cela

Answer 5

Si vous ne faites que sérialiser / désérialiser des objets individuels (pas de requêtes sophistiquées), utilisez une base de données btree, par exemple Base de données Berkeley . Il est très rapide pour stocker et récupérer des morceaux de données par clé (je suppose que vos objets ont un identifiant pouvant être utilisé comme clé) et que l'accès par plusieurs processus est pris en charge.