Benchmark comparativo

ONTO (OntoEngine) confrontato con tre alternative generaliste su un carico di lavoro tipico del paradigma: record con proprietà booleane trivalenti, query per congiunzione di proprietà, distribuzione dei valori e ranking per punteggio.

Metodologia

• Dataset: 8 proprietà booleane trivalenti (febbre, tosse, dispnea, perdita_olfatto, mal_di_testa, dolori_muscolari, congiuntivite, stanchezza), distribuzione 55% V / 30% F / 15% N, generato in modo riproducibile con seed fisso (StdRng::seed_from_u64(42)).
• Dimensioni: N ∈ {1 000, 10 000, 100 000, 500 000}.
• Query:
  • Q1 — scan singolo: febbre = V;
  • Q2 — AND su 3 proprietà: febbre = V ^ tosse = V ^ perdita_olfatto = V;
  • Q3 — AND su 6 proprietà: profilo "COVID" (selettività massima);
  • Q4 — AND trivalente (compressione: V^V=V, F^N=N^F=N, altrimenti F) tra febbre e tosse, materializzazione lazy del risultato;
  • Q5 — distribuzione V/F/N di una proprietà (conteggio aggregato);
  • Q7 — top-20 per peso epistemico (V=2, N=1, F=0);
  • Q8 — scan a soglia sul punteggio totale, con classificazione V/N/F.
• Motori:
  • onto — questo motore (indice bitset trivalente in memoria);
  • sqlite — rusqlite con feature bundled (SQLite incorporato, un indice B-tree per proprietà, nessun server richiesto);
  • naive_scan — Vec<HashMap> senza indici, baseline "applicativo che filtra a mano";
  • sled_kv — KV embedded puro Rust, usato come proxy di Redis (vedi nota).

Riprodurre:

cargo run -p onto-cli --release -- bench --sizes 1000,10000,100000,500000 --out risultati_bench.csv

Ogni query è misurata una volta per esecuzione. I tempi riportati sono la mediana di 7 esecuzioni dello sweep sulla stessa macchina.

Risultati a N = 500 000 (tempi in ms)

Risultati completi

Tempi grezzi (ms) per tutte le dimensioni testate.

N = 1 000

N = 10 000

N = 100 000

N = 500 000

Memoria

Il motore non conserva una copia dei record: li ricostruisce dall'indice, che tiene tre bit per proprietà e per record, più due byte di peso epistemico. Con 8 proprietà trivalenti un record occupa circa 6 byte: 500 000 record stanno in meno di 3 MB (misura riproducibile con cargo run --release --example misura_memoria). Numeri e testi degli elementi, quando presenti, occupano memoria in più nel loro indice ordinato.

Tendenze

• ONTO è il motore più veloce su tutte le query a ogni N testato. Il vantaggio cresce con N e, soprattutto, con il numero di proprietà congiunte: da ~10× (Q2, N=1 000) a 41-51× (Q2-Q3, N=500 000). Le congiunzioni su bitset sono O(n/64) a livello di parola intera, mentre SQLite deve incrociare più indici B-tree e gli altri motori scandiscono record per record.
• Q5 (distribuzione) è il divario più ampio: ~950× a N=500 000. Il conteggio V/F/N è un singolo count_ones() sui bitset già in memoria; gli altri motori eseguono una scansione completa o una query aggregata su tabella.
• Q7 (ranking) penalizza soprattutto sled_kv (~130× più lento): senza uno score posizionale nativo, ogni query deve materializzare gli insiemi V/N di tutte le 8 proprietà e ricalcolare il punteggio lato applicativo — lo stesso costo che avrebbe un client Redis con SINTER/SMEMBERS ripetuti.
• Q1 è il caso dove il KV si avvicina di più (2.1×): un singolo lookup per chiave è quasi ottimale anche per un KV generico. Il vantaggio di ONTO emerge appena la query combina più proprietà o richiede ranking/soglie.
• La costruzione di ONTO costa più di naive_scan e sled_kv (indicizzare 8 bitset per record), ma resta più veloce di SQLite (8 indici B-tree) e viene ripagata interamente dal costo delle query: a N=500 000 l'intero build è recuperato da poche decine di Q2-Q3.

Nota sulla sostituzione di Redis

Redis non è disponibile in questo ambiente (nessun redis-server nel PATH), quindi il confronto "NoSQL/KV" usa sled, un motore KV embedded puro Rust che non richiede alcun processo esterno. sled non è architetturalmente identico a Redis (nessuna rete, nessuna replica, nessun TTL), ma condivide il tratto rilevante per questo confronto: nessun bitset posizionale nativo, solo lookup per chiave — la stessa categoria di struttura dati che userebbe un client Redis con SADD/SINTER. Per un confronto con Redis reale in produzione, valutare che il costo di rete e di materializzazione degli insiemi lato client si sommerebbe a quello già misurato per sled_kv.

Micro-benchmark di regressione (cargo bench)

Al contrario dello sweep sopra (pensato per confrontare motori diversi su dataset grandi), benches/benchmark.rs misura le operazioni core in isolamento, per intercettare regressioni tra modifiche. Numeri da una sessione di misura su questo repository:

Report HTML completo in target/criterion/report/index.html dopo cargo bench.