Benchmarks, amb honestedat

Mediana de N execucions, els dos motors en calent, sentències preparades a banda i banda, fsync a un disc real. Allà on guanya SQLite, ho ensenyem: el gràfic només és útil si te'n pots refiar.

AMD Ryzen 7 3700X · 32 GiB · ext4 en SATA SSD · rustc 1.95.0 · SQLite 3.50.2 · un sol fil

El marcador

Cada operació CRUD, com a ràtio de velocitat. A la dreta de la línia, Arkeion és més ràpid; a l'esquerra, ho és SQLite — i sí, l'escaneig complet encara és seu.

0.5×paritatSELECT by PK3.13×DELETE durable2.5×INSERT durable2.42×UPDATE durable2.06×SELECT by index1.98×API de càrrega massiva1.17×Inserció per lots (SQL)1.02×Escaneig complet0.48×
Cada punt duu el color del guanyador. Passa-hi el ratolí per veure les xifres; l'eix és logarítmic, així que 2× i ½× queden a la mateixa distància de la paritat.

Escriptures durables — el cas d'ús central

Cada transacció confirmada paga el fsync. El commit append-only d'Arkeion necessita un fdatasync; SQLite amb synchronous=FULL en paga dos. En disc real això capgira la taula — i és el que un motor auditat fa constantment.

INSERT, durable 2.42×× 656 vs 271 ops/s
UPDATE, durable 2.06×× 572 vs 278 ops/s
DELETE, durable 2.50×× 657 vs 263 ops/s

Les mateixes garanties — la baralla justa

El marcador de dalt competeix contra SQLite tal qual. Però Arkeion sempre porta a sobre versionat, una cadena de hashos per commit, AS OF i verify(). Dona a SQLite la mateixa feina — una taula d'històric completa més una cadena de hashos per escriptura, en una sola transacció — i la diferència s'eixampla: aquest és el cost d'un rastre d'auditoria que SQLite ha d'afegir a posteriori i que Arkeion simplement és.

Inserció durable, mateixes garanties, durable 2.51×× 656 vs 261 ops/s
Inserció per lots, mateixes garanties, durable 2.19×× 1.99M vs 906k ops/s

L'emulació amb SQLite no reprodueix ni el hash de contingut per commit ni una instantània consultable, així que aquestes ràtios són una cota inferior del cost real d'igualar Arkeion — que encara hi afegeix AS OF, verify() i ramificació.

Text complet vs FTS5 — decisió dividida

L'índex ha acabat sent més petit que el de FTS5; la velocitat de construcció i de consulta continuen sent terreny de FTS5. L'intercanvi compra una cosa que FTS5 no pot oferir: cerca versionada, demostrable i amb viatge en el temps.

Mida de l'índex, mateix corpus
Arkeion
Arkeion: 26.2 MB
26.2 MB
SQLite
SQLite: 27.2 MB
27.2 MB

Posting lists comprimides per prefix — i, a diferència de FTS5, cada posting està versionat, encadenat per hash i es pot cercar amb MATCH … AS OF.

Construcció de l'índex (5,5M postings) FTS5 18× més ràpid
Arkeion
Arkeion: 11 s
11 s
SQLite
SQLite: 0.6 s
0.6 s
Consulta, terme comú FTS5 2,3× més ràpid
Arkeion
Arkeion: 2.5 ms
2.5 ms
SQLite
SQLite: 1.1 ms
1.1 ms

Cerca vectorial davant la resta del camp

SIFT 1M, 128 dimensions, L2, ground truth real del top-100, consulta única amb recall ≈ 0,99. Sota càrrega concurrent manté ~700 qps en 8 nuclis; amb recall ≈ 0,88 una consulta única fa ~590 qps.

Rendiment amb recall ≈ 0,99
Qdrant (HNSW)
Qdrant (HNSW): 508 qps
508 qps
Arkeion (IVF-PQ)
Arkeion (IVF-PQ): 356 qps
356 qps
pgvector HNSW
pgvector HNSW: 188 qps
188 qps
pgvector IVFFlat
pgvector IVFFlat: 63 qps
63 qps
Mida de l'índex
pgvector HNSW
pgvector HNSW: 820 MB
820 MB
pgvector IVFFlat
pgvector IVFFlat: 551 MB
551 MB
Arkeion (IVF-PQ)
Arkeion (IVF-PQ): ~39 MB
~39 MB

14–21× més petit que els índexs HNSW — cap en una fracció de la RAM. Qdrant no reporta una mida de fitxer comparable.

Construcció de l'índex
pgvector HNSW
pgvector HNSW: 324 s
324 s
Arkeion (IVF-PQ)
Arkeion (IVF-PQ): 64 s
64 s
Qdrant (HNSW)
Qdrant (HNSW): 49 s
49 s
pgvector IVFFlat
pgvector IVFFlat: 23 s
23 s

Paral·lela i en streaming (186 s → 64 s): el conjunt de dades no es materialitza mai, així que escala a desenes de milions de files en una màquina modesta.

Llegeix-ho amb justícia: pgvector i Qdrant responen per TCP a localhost, així que un round trip de 0,05–0,2 ms infla les seves latències; i IVF escaneja O(N) candidats a recall fix mentre que HNSW és O(log N), de manera que els motors de graf dedicats s'avancen a partir de desenes de milions de vectors. HNSW queda exclòs aquí per disseny: el seu graf d'accés aleatori és incompatible amb el versionat copy-on-write i el viatge en el temps. Arkeion és l'únic fitxer on els vectors viuen al costat de SQL, text complet, branques i AS OF.

El preu de la durabilitat — v0.13 vs FAISS

La comparació més dura que podem fer: FAISS és la biblioteca ANN de referència — RAM pura, sense durabilitat, sense transaccions, sense versionat, sense SQL. La mateixa màquina (una VM de 4 nuclis, així que les barres de dalt i les de baix no són comparables entre si), el mateix SIFT-1M, configuració idèntica a banda i banda: IVF de 1000 llistes, PQ16, rerank exacte ×32. Recall@10 ≈ 0,99 en tots dos, una consulta cada cop, un sol fil.

Rendiment amb recall ≈ 0,99, un sol fil
FAISS (biblioteca en RAM)
FAISS (biblioteca en RAM): 756 qps
756 qps
Arkeion v0.13 (dins el fitxer)
Arkeion v0.13 (dins el fitxer): 404 qps
404 qps
Arkeion v0.12
Arkeion v0.12: 110 qps
110 qps

A menys de 2× de la referència en RAM — des d'un fitxer xifrat, versionat i durable. Abans de la v0.13 la diferència era de 7–10×. El mode per lots de FAISS amb 8 fils arriba a ~5.000 qps davant els 1.381 concurrents d'Arkeion.

Més petit en disc

El mateix conjunt de dades comprimible, escrit pels dos motors. Empaquetatge de pàgines més LZSS en Rust pur — Arkeion va començar aquesta feina amb 4,0 MB.

Executa'ls tu mateix

# CRUD vs SQLite (apunta a un disc real, no a tmpfs)
ARKEION_BENCH_DIR=/path/on/real/disk cargo bench --features bench-sqlite

# espai en disc
cargo run --release --example dbsize --features bench-sqlite

Una lliçó que vam aprendre a les males: en tmpfs els fsync surten de franc i SQLite guanya les escriptures durables. En un disc real la cosa es capgira. Fes sempre els benchmarks al disc on executaràs.

Convençut? És a una ordre de distància

Llegeix el codi del bench