hikari-systems/slaterDatabase a grafi a basso consumo di memoria con supporto Bolt+TLS, crittografia at-rest e vettori, progettato per casi d'uso di repliche locali di grafi.
Versione attuale: v0.25.2 — tutte le release.
In una riga: Slater serve grafi che non stanno in memoria — centinaia di milioni di nodi e miliardi di relazioni in poche centinaia di MB di RAM — tramite il Bolt standard, quindi qualsiasi driver neo4j funziona senza modifiche, con la ricerca vettoriale nativa su disco accanto al grafo, e accetta scritture live e durevoli senza rinunciare a tutto questo. La memoria residente è determinata da un budget di cache che scegli tu, non dalla dimensione del grafo.
Scorciatoie
Un database a grafo memorizza i dati come cose (nodi) e relazioni tra loro (archi), con le relazioni trattate come cittadini di prima classe. È ciò che ti serve quando le domande riguardano connessioni piuttosto che righe — "chi è entro tre salti da questo conto?", "qual è l'intera catena di dipendenze dietro questa build?", "quali conti condividono un dispositivo, un indirizzo e una carta?" — le query che in SQL diventano una palude di join ricorsivi ma che in un grafo emergono naturalmente.
La lamentela più comune sui database a grafo è che non scalano oltre ciò che puoi tenere in RAM. Molti di essi (ad es. neo4j, Memgraph, FalkorDB, ecc.) mantengono l'intero grafo residente: un grafo da 40 GB richiede 40 GB di memoria — per istanza. Vuoi una replica per regione, per tenant o per pod? Moltiplica il costo. E oltre una certa dimensione semplicemente non si caricano: ad esempio il grafo Wikidata da 90 milioni di nodi / 1,5 miliardi di archi richiede ~64–128 GiB residenti, quindi i motori in memoria non riescono ad aprirlo affatto.
Slater è la confutazione. Invece di caricare il grafo in memoria, lo compila una volta, offline: slater-build trasforma i tuoi dati in un'immagine su disco immutabile e indirizzata al contenuto, e un numero qualsiasi di server Slater serve poi quell'immagine tramite Bolt (così i tuoi driver neo4j esistenti funzionano e basta), caricando i blocchi on demand e tenendo residente solo un budget di cache fisso. È così che lo stesso grafo da 90 milioni di nodi viene servito da poche centinaia di MB di RAM — dimensione del grafo e costo di memoria sono disaccoppiati. Un grafo da 4 GB e uno da 400 GB costano la stessa RAM da servire, quindi puoi distribuire repliche di lettura economiche e senza stato e lasciare che sia lo storage, non l'heap, a contenere il grafo.
Questo lo rende un candidato naturale per i knowledge graph dietro RAG, grafi di raccomandazione e identità, grafi di dipendenze — qualsiasi cosa grande e interconnessa tu voglia interrogare in modo economico e frequente. La ricerca vettoriale nativa su disco vive proprio accanto al grafo, così lo stesso motore è anche il livello di retrieval per gli embedding.
Compilato una volta, però, non significa congelato. Quell'immagine è una base, non uno stato finale: un livello di scrittura opt-in si trova sopra di essa, quindi un grafo live può essere corretto ed esteso senza ricostruire nulla.
Il core è immutabile; il grafo no. Attiva il livello scrivibile (delta.enabled) e scrivi tramite Bolt — correggi una proprietà, aggiungi un nodo, ritira un arco — e la modifica atterra in modo durevole, senza ricostruire l'immagine. Ciò che mantiene bassi i costi sul lato lettura è dove vivono le scritture.
Le scritture si accumulano in un livello log-structured-merge (LSM) sopra il core immutabile: un write-ahead log e una tabella in memoria, che si riversano in segmenti delta immutabili, riassorbiti in un nuovo core da una consolidation periodica. Cosa ottieni:
count(*), le marginali su etichette e tipi di relazione — restano letture di metadati anche con scritture in sospeso: il delta mantiene i propri contatori, quindi un count(*) su un core da 91,6 milioni di nodi con mezzo milione di scritture in attesa risponde comunque in decine di millisecondi senza toccare un singolo blocco.SUCCESS solo dopo l'fsync che copre la scrittura. Raggruppa le tue scritture e diventano economiche — una scrittura-UNWIND committa un fsync per batch, non per riga.MERGE / MATCH … SET / DELETE (e CREATE / REMOVE, delete con detach, scritture di relazioni) basate sulla proprietà identità di un nodo — oppure le equivalenti istruzioni di modifica ISO GQL (INSERT / SET / REMOVE / DELETE), che si appoggiano allo stesso percorso. Correggi, inserisci, fai upsert e ritrai, su nodi e archi, indirizzati nel modo in cui i tuoi dati sono già strutturati.Con il livello disattivato — il default — Slater serve il puro core immutabile e rifiuta le scritture. Vedi Il livello scrivibile per il modello completo.
Sul nome. Slater prende il nome dall'agente della CIA in Archer (una grande serie) che insiste sull'uso di un solo nome — "Just… Slater" — e uno dei miei personaggi preferiti della serie. Vedi la pagina wiki del personaggio.