Je suis à la recherche d'un stockage permanent de valeurs-clés pour .NET. Les conditions sont les suivantes:.NET - Un stockage de clé-valeur persistante léger et rapide
- Le stockage est utilisé pour les objets identifiés par des chaînes et possédant plusieurs propriétés facultatives (nommées) avec des valeurs qui ne sont que des tableaux d'octets. Pour une solution SQL, je la modéliserais comme une chaîne -> table id, et plusieurs tables id -> blob.
- La quantité de données attendue est plusieurs méga-octets (plus de 10 Mo est actuellement peu probable, mais mise à l'échelle jusqu'à 100 Mb serait un joli bonus)
- léger - de préférence un seul assemblage, certainement sans applications externes
- Lit les sont plus fréquentes que les écritures, au moins par un facteur de 100.
- Accès rapide en lecture/écriture - Je prévois un stockage en mémoire et des écritures paresseuses sur les mises à jour des données; Je peux périodiquement apparaître async écrit moi-même, des points bonus si le stockage le fait.
- E/S atomiques - la base de données ne doit pas être interrompue si le processus est terminé au milieu de l'écriture; sinon, les données ne sont pas critiques, c'est-à-dire qu'aucune redondance supplémentaire n'est nécessaire.
Actuellement, je pense que SQLite fonctionnera ici; Cependant, il semble qu'il y ait une légère surcharge - je n'ai besoin que d'un stockage à valeur-clé, pas d'un support SQL complet. J'ai également entendu parler de bdb, et de la liaison libdb-dotnet - il semble être plus léger, mais je ne connais pas les caractéristiques de performance/cohérence.
Quelqu'un peut-il recommander quelque chose ici? Des références supplémentaires sont les bienvenues (ie ce serait génial si quelque chose dans .NET Framework pouvait faire le travail), ainsi que des expériences avec SQLite ou libdb-dotnet (ou bdb en général) ou une solution locale, si c'était indolore .
Semble à moi en utilisant n'importe quel type de base de données serait trop pour cela, avec seulement 10mb pourquoi ne pas lire/écrire tout à la fois sur et à partir du disque? (Ce n'est pas comme si ça prenait autant de mémoire) – Doggett
@Doggett, cela ressemble à réinventer la base de données, si l'application proposée est non-triviale. – driis
@Doggett, le problème est que l'écriture de DB complète à chaque mise à jour sera lente, et il n'y a pas de point de vidage unique (je ne peux pas écrire DB complète sur app exit parce que l'application peut être terminée prématurément); Je vais devoir supporter des flushs partiels, et les rendre atomiques - c'est la seule chose non triviale à ce sujet, je suppose. – zeuxcg