Vector search benchmark zbulon një hendek të madh në build time
Një vector search benchmark në gjashtë database engine zbuloi se shndërrimi i të njëjtave 990,000 embedding në një index të gatshëm për query zgjati nga 1.9 minuta deri në 6.7 orë. Percona i kreu testet në një makinë, me të njëjtin query set dhe të njëjtën formë container, duke matur build time, storage, memory, accuracy, throughput, concurrent client, kërkimet e filtruara dhe efektin e rishkrimit të 10% të të dhënave.
Corpus ishte dbpedia-openai-1000k-angular, që përmbante 990,000 OpenAI embedding, secili i përfaqësuar nga 1,536 numra float32. Një embedding është një paraqitje numerike që përdoret për të krahasuar kuptimin ose ngjashmërinë. Çdo engine përdori HNSW, ose Hierarchical Navigable Small World, një strukturë graph që përshpejton kërkimet për vector pranë njëri-tjetrit, me M të vendosur në 16 dhe numrin e rezultateve k të vendosur në 10. Host kishte një procesor Intel Xeon Gold 6230, 80 CPU logjike, AVX-512 dhe 187.5 GiB RAM. Database container mori CPU-të nga 0 deri në 63 dhe një kufi memory prej 120.8 GB; një test container i veçantë mori 16 CPU dhe 8 GB. Ndarja e tyre pengoi që query set i mbajtur nga NumPy të llogaritej si database memory.
Sistemet e testuara ishin open-source relational database 11.8.8 me MHNSW, i njëjti open-source relational database 12.3.2 me MHNSW, AliSQL 8.0.44-2 me VIDX, pgvector 0.8.6 në relational database që përdoret nga shumë aplikacione web, Valkey 9.1.1 me valkey-search dhe Percona Search for MongoDB 1.70.3-1 në PSMDB 8.3.8-2. Percona Search ishte një Technical Preview, dokumentacioni i të cilit thoshte se nuk ishte për production. Testet e tij përdorën një index me scalar quantization, i cili ruan vlera numerike më pak precize për të ulur kërkesat për processing dhe storage.
Build performance ndryshonte në mënyrë dramatike. Percona Search u bë i gatshëm për query pas 1.9 minutash, Valkey pas 4.3 minutash dhe relational database me pgvector pas 40.9 minutash. Relational database shpenzoi 26.9 minuta për loading përmes COPY dhe 14 minuta për ndërtimin e index me tetë worker. Open-source database 11.8 kërkoi 3.6 orë, open-source database 12.3 kërkoi 5.4 orë dhe AliSQL kërkoi 6.7 orë. MHNSW dhe VIDX e përditësojnë graph gjatë çdo INSERT, prandaj loading dhe ndërtimi i index ishin një operacion i vetëm. Normat e tyre varionin nga 41 deri në 76 rreshta në sekondë, krahasuar me 613 për pgvector dhe 30,170 për Valkey.
Sistemet me build më të ngadaltë prodhuan index më të vegjël. Open-source database dhe AliSQL përdorën secili 3.9 GiB, sepse graph e tyre mbanin kopje të vector të quantized në 16-bit, ndërsa pgvector dhe Valkey indeksuan vlera të plota float32. Vetëm vector e papërpunuar zinin 5.7 GiB. Madhësitë e index ishin 7.6 GiB për pgvector, 11.3 GiB për Valkey dhe 15.1 GiB për Percona Search. Duke përfshirë table, AliSQL përdori 14.4 GiB, pgvector 15.2 GiB, open-source database 11.8 dhe Valkey nga 18.2 GiB secili, ndërsa Percona Search 20.9 GiB. Index i Percona Search u mat më vonë në 7.2 GiB në fillim të testit të churn dhe Percona nuk mundi të përcaktonte se cila shifër përfaqësonte steady state.
Peak resident memory varionte nga 14.3 GiB për Valkey deri në 48.8 GiB për Percona Search. Ndarjet e cache ishin specifike për secilin engine dhe jo identike: sistemet InnoDB morën një buffer pool prej 42.3 GB dhe një graph cache prej 30.2 GB, pgvector mori 72.5 GB shared_buffers plus 12.1 GB maintenance_work_mem, ndërsa Valkey kishte 108.7 GB maxmemory. Percona Search përdori cache standard WiredTiger të MongoDB prej 57 deri në 64 GB. Build të index u kufizuan në tetë thread, sepse numrat më të lartë shkaktonin contention dhe mund të bllokonin write në index të mbushur.
Accuracy u mat si recall, që tregon sa nga fqinjët e saktë më të afërt kthente kërkimi. Me një client dhe recall prej të paktën 0.99, open-source database 12.3 realizoi 277 queries per second (QPS), Valkey 264, pgvector 210, AliSQL 126 dhe open-source database 11.8 vetëm 46. Index me quantization i Percona Search arriti kulmin në 0.892 recall, ndaj nuk u kualifikua; pa quantization regjistroi 88 QPS në pragun 0.99. Diferenca prej 13 QPS mes open-source database 12.3 dhe Valkey ishte tepër e vogël që një ekzekutim i vetëm ta dallonte nga noise. Open-source database 12.3 ishte gjithashtu compiled me -march=native, ndryshe nga build x86-64-v3 të përdorura për open-source database 11.8, AliSQL dhe pgvector.
AliSQL prodhoi një anomali të pashpjeguar. Me M në 16, throughput u rrit nga 2.6 në 4.4 QPS kur ef_search, sasia e përpjekjes së kërkimit gjatë query, u rrit nga 400 në 800, megjithëse më shumë punë nuk duhet ta bëjë të njëjtin index më të shpejtë. Median latency gjithashtu u rrit papritur nga 6.6 milisekonda me ef_search 80 në 50.8 milisekonda me 120, pastaj nga 191 në 384 milisekonda mbi atë nivel. Percona e shënoi këtë interval si jo të besueshëm, në vend që ta trajtonte si rezultat të vlefshëm.
Rezultatet e concurrency kërkojnë po aq kujdes gjatë interpretimit. Me 32 client dhe ef_search 100, Valkey arriti 5,683 QPS me p99 latency prej 10.2 milisekondash, që do të thotë se 99% e query përfunduan brenda asaj kohe. Pgvector arriti 4,798 QPS në 10.8 milisekonda, ndërsa Percona Search arriti 1,844 QPS në 43.5 milisekonda. Pgvector prodhoi 21.7 herë throughput e tij me një client. Megjithatë, harness kishte vetëm 16 CPU, ndaj rrafshimi i performancës së Valkey dhe Percona Search midis 16 dhe 32 client mund të pasqyrojë kufizime të CPU në anën e client.
Nuk u raportuan shifra me shumë client për open-source database 11.8, open-source database 12.3 ose AliSQL. Python client e tyre me thread, që të gjithë përdornin connector për open-source database, mbetën pranë një query në proces ndërsa numri i client rritej. Percona nuk e kishte identifikuar mekanizmin e saktë dhe nuk bëri profiling të server, ndaj nuk bëri asnjë pretendim për scaling në anën e server. Harness është ndryshuar që atëherë për ta vendosur secilin client në një process të veçantë të operating system, por ky version ishte testuar vetëm me synthetic driver dhe nuk i kishte matur ende përsëri këta engine.
Filtrimi nxori në pah dallime të mëdha në sjellje. Me selectivity prej 1%, që do të thotë se vetëm 1% e rreshtave kaluan kushtin, Valkey dha 0.9996 recall me 8.2 QPS. Open-source database 12.3, open-source database 11.8 dhe AliSQL vazhduan kërkimin pas filtrimit, duke ruajtur recall midis 0.9724 dhe 0.9884, por duke rënë nën një QPS, me p99 latency prej 10 deri në 13 sekonda. Percona Search filtroi përpara vector search dhe u përshpejtua nga 71.9 QPS me selectivity 10% në 117.5 me 1%, megjithëse quantization e kufizoi recall në 0.8666.
Sjellja standarde e pgvector kërkonte fillimisht, hiqte rreshtat që nuk plotësonin kushtin dhe më pas ndalonte. Me selectivity prej 1%, të 500 query kthyen më pak se dhjetë rreshtat e kërkuar, duke prodhuar recall prej 0.1034 me 237.1 QPS, pa error ose warning. Pgvector 0.8 përfshin iterative scan për ta trajtuar këtë rast, por benchmark nuk e testoi. Mësimi praktik është se përfundimi i shpejtë nuk është i dobishëm nëse një aplikacion merr në heshtje rezultate jo të plota.
Pasi 99,000 rreshta u fshinë dhe u rifutën, pgvector mbeti i qëndrueshëm në 245 QPS, me rritje 0.4%, ndërsa Valkey ra 4% në 460 QPS. Percona Search ra 38.9% në 113 QPS, megjithëse recall ndryshoi fare pak, nga 0.8432 në 0.8416.