Si vous avez déjà monté un système d’agents avec plusieurs agents concurrents et SQLite, vous avez probablement croisé le genre de problèmes que GapDB est censé régler.
Quand on crée des apps basées sur des agents, un simple magasin de données ne suffit pas. Les agents ont aussi besoin d’un endroit pour se coordonner.
Un agent s’approprie une tâche. Un autre la révise. Un troisième change son état. Les agents redémarrent, réessaient, disparaissent, reviennent plus tard, et agissent parfois sur des infos déjà périmées.
À ce stade, la base de données doit être capable de stocker à la fois l’état et l’autorité.
Qui possède cette tâche ? Est-ce que cet enregistrement a changé depuis que je l’ai lu ? Ai-je toujours le droit de le mettre à jour ? Est-ce que cette écriture est devenue durable ? Qu’est-ce qui a bougé pendant mon absence ?
C’est pour ça que j’ai commencé à coder GapDB.
Robert Douglass, chez Spec Kitty, a eu la gentillesse d’adopter le projet, donc celui-ci compte bien comme une release officielle de Spec Kitty.
https://github.com/spec-kitty/gapdb
Une petite API de coordination
GapDB est un petit magasin de données local, natif pour les agents, construit autour des primitives de coordination dont les systèmes d’agents ont réellement besoin.
Son API est volontairement minuscule : Get, Put, PutIfAbsent, CompareAndSwap, DeleteIfRevision, AtomicBatch, ScanPrefix et Watch.
Pas de SQL, pas de jointures, pas de planificateur de requêtes, et aucune intention de devenir une base de données généraliste.
État, révisions et durabilité
Chaque commit réussi reçoit une révision. Un agent peut donc concrètement dire :
« Applique ce changement, mais seulement si le monde est toujours celui que j’ai observé. »
Si un autre agent a modifié l’enregistrement entre-temps, l’opération périmée échoue.
La durabilité est aussi explicite. Une écriture peut être acquittée comme étant en mémoire ou durable, selon que l’état est jetable ou représente quelque chose d’important, comme un bail, une décision de révision ou une autorité de workflow.
Une architecture volontairement réduite
En interne, GapDB reste intentionnellement simple : un processus propriétaire, une map faisant autorité en mémoire, un seul écrivain sérialisé, un WAL en append-only, des snapshots avec checksum et des sockets Unix-domain.
Le but n’est pas de remplacer SQLite partout.
Je l’ai plutôt conçu pour fournir une couche de coordination petite et flexible pour le cas, de plus en plus courant, où plusieurs agents autonomes partagent un état local et ont besoin d’assez de structure pour éviter de se marcher sur les pattes.
On peut respirer, sans importer tout un univers de base de données pour régler un problème relativement ciblé.
C’est ça, GapDB.
À vous de l’utiliser, de jouer avec et de le démonter. C’est publié sous une licence MIT permissive.
Maintenant, allez mes enfants, construisez un truc cool et montrez-moi ce que vous en avez fait !