hikari-systems/slaterSpeicherschonende graphdb mit Bolt+tls-Unterstützung, Verschlüsselung im Ruhezustand und Vektoren, entwickelt für lokale Replikat-Graph-Anwendungsfälle.
Aktuelle Version: v0.25.2 — alle Releases.
In einem Satz: Slater bedient Graphen, die nicht in den Speicher passen — Hunderte Millionen Knoten und Milliarden Kanten in wenigen hundert MB RAM — über standardmäßiges Bolt, sodass jeder neo4j-Treiber einfach funktioniert, mit disk-nativem Vektor-Search direkt neben dem Graphen, und es nimmt live, dauerhafte Schreibvorgänge entgegen, ohne darauf zu verzichten. Der residente Speicher wird durch ein Cache-Budget bestimmt, das Sie wählen, nicht durch die Größe des Graphen.
Verknüpfungen
Eine Graphdatenbank speichert Daten als Dinge (Knoten) und die Beziehungen zwischen ihnen (Kanten), wobei die Beziehungen erstklassige Bürger sind. Das ist genau das, was Sie brauchen, wenn Ihre Fragen sich um Verbindungen drehen und nicht um Zeilen — „Wer ist innerhalb von drei Hops von diesem Konto entfernt?“, „Was ist die vollständige Abhängigkeitskette hinter diesem Build?“, „Welche Konten teilen sich ein Gerät, eine Adresse und eine Karte?“ — die Abfragen, die in SQL zu einem Sumpf rekursiver Joins werden, sich in einem Graphen aber natürlich ergeben.
Die häufigste Beschwerde über Graphdatenbanken ist, dass sie nicht über das hinaus skalieren, was Sie im RAM halten können. Viele von ihnen (z. B. neo4j, Memgraph, FalkorDB usw.) halten den gesamten Graphen resident: Ein 40 GB-Graph benötigt 40 GB Speicher — pro Instanz. Möchten Sie eine Replik pro Region, pro Mandant oder pro Pod? Multiplizieren Sie die Rechnung. Und ab einer bestimmten Größe laden sie einfach nicht mehr: Der Wikidata-Graph mit 90 Millionen Knoten / 1,5 Milliarden Kanten benötigt ~64–128 GiB resident, sodass die In-Memory-Engines ihn überhaupt nicht öffnen können.
Slater ist die Widerlegung. Anstatt den Graphen in den Speicher zu laden, kompiliert es ihn einmal, offline: slater-build verwandelt Ihre Daten in ein content-addressed, unveränderliches On-Disk-Image, und beliebig viele Slater-Server bedienen dieses Image dann über Bolt (sodass Ihre vorhandenen neo4j-Treiber einfach funktionieren), pagen Blöcke bei Bedarf ein und halten nur ein festes Cache-Budget resident. So wird derselbe 90M-Knoten-Graph aus ein paar hundert MB RAM bedient — Graphgröße und Speicherrechnung sind entkoppelt. Ein 4 GB-Graph und ein 400 GB-Graph kosten denselben RAM zum Bedienen, sodass Sie günstige, zustandslose Lese-Repliken ausrollen und den Store, nicht den Heap, den Graphen halten lassen.
Das macht ihn zu einer natürlichen Wahl für Wissensgraphen hinter RAG, Empfehlungs- und Identitätsgraphen, Abhängigkeitsgraphen — alles Große und Verbundene, das Sie günstig und häufig abfragen möchten. Disk-nativer Vektor-Search lebt direkt neben dem Graphen, sodass dieselbe Engine auch die Retrieval-Schicht für Embeddings ist.
Einmal kompiliert bedeutet jedoch nicht eingefroren. Dieses Image ist eine Basis, kein Endzustand: Eine optionale Schreibschicht sitzt darüber, sodass ein Live-Graph korrigiert und erweitert werden kann, ohne etwas neu zu bauen.
Der Kern ist unveränderlich; der Graph ist es nicht. Aktivieren Sie die beschreibbare Schicht (delta.enabled) und Sie schreiben über Bolt — korrigieren Sie eine Eigenschaft, fügen Sie einen Knoten hinzu, ziehen Sie eine Kante zurück — und die Änderung landet dauerhaft, ohne Neubau des Images. Was es auf der Leseseite günstig hält, ist wo die Schreibvorgänge leben.
Schreibvorgänge sammeln sich in einer Log-Structured-Merge (LSM)-Schicht über dem unveränderlichen Kern: ein Write-Ahead-Log und eine In-Memory-Tabelle, die in unveränderliche Delta-Segmente überläuft und durch eine periodische Konsolidierung in einen frischen Kern zurückgefaltet wird. Was Ihnen das bringt:
count(*), die Label- und Beziehungstyp-Marginalien — bleiben Metadaten-Lesevorgänge, selbst bei ausstehenden Schreibvorgängen: Das Delta führt seine eigenen Zähler, sodass ein count(*) über einen 91,6M-Knoten-Kern mit einer halben Million ausstehender Schreibvorgänge immer noch in zig Millisekunden antwortet, ohne einen einzigen Block zu berühren.SUCCESS erst nach dem fsync zurück, das den Schreibvorgang abdeckt. Bündeln Sie Ihre Schreibvorgänge und sie sind günstig — ein Schreib-UNWIND committet ein fsync pro Batch statt pro Zeile.MERGE / MATCH … SET / DELETE (und CREATE / REMOVE, Detach-Delete, Beziehungsschreibvorgänge), die auf die Identitätseigenschaft eines Knotens schlüsseln — oder die äquivalenten ISO-GQL-Datenmodifikationsanweisungen (INSERT / SET / REMOVE / DELETE), die auf denselben Pfad herunterbrechen. Korrigieren, einfügen, upserten und zurückziehen, über Knoten und Kanten, adressiert so, wie Ihre Daten bereits sind.Bei deaktivierter Schicht — dem Standard — bedient Slater den reinen unveränderlichen Kern und verweigert Schreibvorgänge. Siehe Die beschreibbare Schicht für das vollständige Modell.
Zum Namen. Slater ist nach dem CIA-Agenten in Archer (einer großartigen Serie) benannt, der darauf besteht, nur mit einem Namen genannt zu werden — „Just… Slater“ — und einer meiner Lieblingsfiguren darin. Siehe die Charakter-Wiki-Seite.