hikari-systems/slaterGraphdb à faible empreinte mémoire avec prise en charge de Bolt+tls, chiffrement au repos et vecteurs conçus pour les cas d’utilisation de graphes en réplica local.
Version actuelle : v0.25.2 — toutes les versions.
En une phrase : Slater sert des graphes qui ne tiennent pas en mémoire — des centaines de millions de nœuds et des milliards d'arêtes dans quelques centaines de Mo de RAM — via le Bolt standard, de sorte que n'importe quel pilote neo4j fonctionne tel quel, avec une recherche vectorielle native sur disque à côté du graphe, et il accepte des écritures en direct et durables sans y renoncer. La mémoire résidente est définie par un budget de cache que vous choisissez, pas par la taille du graphe.
Raccourcis
Une base de données graphe stocke les données sous forme de choses (nœuds) et de relations entre elles (arêtes), les relations étant des citoyens de première classe. C'est ce qu'il vous faut lorsque vos questions portent sur des connexions plutôt que sur des lignes — « qui se trouve à moins de trois sauts de ce compte ? », « quelle est la chaîne de dépendances complète derrière cette compilation ? », « quels comptes partagent un appareil, une adresse et une carte ? » — les requêtes qui deviennent un marécage de jointures récursives en SQL mais qui se résolvent naturellement dans un graphe.
La plainte la plus courante concernant les bases de données graphe est qu'elles ne passent pas à l'échelle au-delà de ce que vous pouvez tenir en RAM. Beaucoup d'entre elles (par ex. neo4j, Memgraph, FalkorDB, etc.) gardent tout le graphe en mémoire : un graphe de 40 Go veut 40 Go de mémoire — par instance. Vous voulez un réplica par région, par locataire ou par pod ? Multipliez la facture. Et au-delà d'une certaine taille, elles refusent tout simplement de charger : par exemple, le graphe Wikidata de 90 millions de nœuds / 1,5 milliard d'arêtes nécessite ~64–128 GiB résidents, donc les moteurs en mémoire ne peuvent pas l'ouvrir du tout.
Slater est la réfutation. Plutôt que de charger le graphe en mémoire, il le compile une fois, hors ligne : slater-build transforme vos données en une image sur disque immuable et adressée par contenu, et n'importe quel nombre de serveurs Slater sert ensuite cette image via Bolt (donc vos pilotes neo4j existants fonctionnent tels quels), en paginant les blocs à la demande et en ne gardant résident qu'un budget de cache fixe. C'est ainsi que le même graphe de 90M de nœuds est servi depuis quelques centaines de Mo de RAM — la taille du graphe et la facture mémoire sont découplées. Un graphe de 4 Go et un graphe de 400 Go coûtent la même RAM à servir, donc vous déployez des réplicas de lecture bon marché et sans état et laissez le stockage, pas le tas, contenir le graphe.
Cela en fait un choix naturel pour les graphes de connaissances derrière le RAG, les graphes de recommandation et d'identité, les graphes de dépendances — tout ce qui est volumineux et connecté que vous souhaitez interroger à moindre coût et souvent. La recherche vectorielle native sur disque vit juste à côté du graphe, donc le même moteur est aussi la couche de récupération pour les embeddings.
Compilé une fois ne signifie pas figé, cependant. Cette image est une base, pas un état final : une couche d'écriture optionnelle se superpose à elle, donc un graphe en direct peut être corrigé et étendu sans rien reconstruire.
Le cœur est immuable ; le graphe ne l'est pas. Activez la couche inscriptible (delta.enabled) et vous écrivez via Bolt — corrigez une propriété, ajoutez un nœud, retirez une arête — et le changement atterrit de manière durable, sans reconstruction de l'image. Ce qui maintient le coût faible côté lecture, c'est où vivent les écritures.
Les écritures s'accumulent dans une couche log-structurée-fusionnée (LSM) au-dessus du cœur immuable : un journal d'écriture anticipée et une table en mémoire, se déversant dans des segments delta immuables, repliés dans un nouveau cœur par une consolidation périodique. Ce que cela vous apporte :
count(*), les marginaux d'étiquettes et de types de relations — restent des lectures de métadonnées même avec des écritures en attente : le delta conserve ses propres compteurs, donc un count(*) sur un cœur de 91,6M de nœuds avec un demi-million d'écritures en attente répond encore en quelques dizaines de millisecondes sans toucher un seul bloc.SUCCESS qu'après le fsync qui couvre l'écriture. Regroupez vos écritures et elles sont bon marché — un UNWIND d'écriture valide un fsync par lot plutôt que par ligne.MERGE / MATCH … SET / DELETE (et CREATE / REMOVE, suppression détachée, écritures de relations) indexées sur la propriété d'identité d'un nœud — ou les instructions équivalentes de modification de données ISO GQL (INSERT / SET / REMOVE / DELETE), qui descendent sur le même chemin. Corrigez, insérez, upsert et retirez, sur les nœuds et les arêtes, adressés comme vos données le sont déjà.Avec la couche désactivée — le défaut — Slater sert le cœur immuable pur et refuse les écritures. Voir La couche inscriptible pour le modèle complet.
Sur le nom. Slater est nommé d'après l'agent de la CIA dans Archer (une excellente série) qui insiste pour être appelé par un seul nom — « Just… Slater » — et l'un de mes personnages préférés de la série. Voir la page wiki du personnage.