Hébergement · GSDS
Plusieurs bases, un protocole.
GSDS distribue et exploite plusieurs Engine Generic System persistants sans remplacer leur modèle de données, leur sémantique transactionnelle ni leur protocole natif. Ce que l'on fait en local avec Engine, on le fait à distance avec ClientEngine.
Plan de contrôle
REST : le catalogue.
L'API /api/v1/* gère le cycle de vie des bases : créer, lister, lire l'état, supprimer. Elle ne sert pas à lire ou modifier les Generic métier.
Plan de données
WebSocket : le graphe.
Un unique transport /ws/{databaseId} porte le protocole natif Generic System. Le proxy démarre l'Engine de la base et pipe les frames binaires sans les interpréter : il n'y a qu'une seule implémentation de la sémantique, celle du kernel.
Le graphe distant reste un graphe
ClientEngine présente un Root identique.
La différence se situe sous le cache : un commit distant transporte le différentiel au serveur, qui applique la vraie transaction. Les lectures absentes du cache client sont récupérées à la demande.
| Local | Distant (GSDS) | |
|---|---|---|
| Racine | Engine | ClientEngine |
| Cache | Cache | ClientCache |
| Transaction | locale | FrontEndTransaction → serveur |
| Generics | identiques | |
Chaque base GSDS correspond à un vrai Engine géré par un pool : la base peut être connue du registre avec son Engine actif, arrêté, ou éphémère. Arrêter un Engine du pool ne supprime pas sa base persistante.
Trois états distincts
Le registre n'est pas la base.
Le registry.json liste les bases connues (identifiant, chemin, classe d'application). L'Engine en mémoire porte l'état transactionnel vivant. Les snapshots *.gs.zip matérialisent cet état sur disque. Restaurer le registre ne restaure pas le contenu d'une base.
Persistance
Le graphe reste disponible.
GSDS conserve chaque graphe sur disque par snapshots périodiques et en écrit un à l’arrêt propre. Un flush() valide les changements dans le moteur serveur ; les opérations d’exploitation permettent de maîtriser explicitement la matérialisation du graphe.
Sécurité d'accès
Un accès maîtrisé à chaque base.
Le mécanisme comporte deux secrets, créés par install-service.sh (256 bits, droits 0600) :
| Clé | Envoyée comme | Protège |
|---|---|---|
| Clé d'accès | Authorization: Bearer | toutes les routes REST et les handshakes /ws/ |
| Clé admin | X-Admin-Key | en plus, POST et DELETE /api/v1/databases |
Le service écoute en local (127.0.0.1) par défaut et refuse de démarrer sur une adresse exposée sans les deux clés.
GSDS s'intègre à l'infrastructure existante : un reverse proxy ou un tunnel apporte le chiffrement réseau hors de la machine. La séparation entre clé d'accès et clé d'administration protège les opérations courantes comme la gestion des bases.
Exploitation
Des scripts, pas de magie.
./gs-database-server/gsds-status.sh
./gs-database-server/rebuild-restart-gsds.sh
./gs-database-server/gsds-prune.sh --dry-runAprès une reconstruction du JAR, le service doit être redémarré : il charge gs-database-server/target/gs-database-server.jar, un artefact reconstruit ne prend pas effet tout seul.
Ce que GSDS n'est pas
Une couche, pas un remplacement.
GSDS n'est ni le kernel (moteur, transaction, persistance), ni GS-Reactor (projection web), ni GS-Agent (surface MCP), ni une API métier REST, ni un serveur d'identité. Il ajoute au kernel : un catalogue multi-base, un adressage par databaseId, un pool de Engines, un proxy WebSocket, la sécurité d'accès et le monitoring.
Continuer
Le moteur sous le capot.
La sémantique transactionnelle, le MVCC et la persistance décrits ici sont ceux du kernel. La page du moteur les détaille.