
pgvector eða Qdrant: hraðari leit getur kostað annað kerfi

Fyrir teymi sem geymir viðskiptagögn í PostgreSQL er pgvector oft einfaldari upphafskostur: vigrar geta verið með gögnunum sem leitin þarf að tengja við. Qdrant kemur helst til álita þegar síuð vigraleit er þungur hluti álagsins og lægri leitartöf réttlætir sjálfstæða þjónustu. Qdrant mældist hraðari í tveimur birtum prófunum, en hraðamunurinn einn segir ekki til um hvort annað kerfi borgi sig.
Ákvörðunin ræðst af allri fyrirspurninni: hvaða færslur mega koma til greina, hversu margar réttar niðurstöður finnast og hvað þarf að gerast við breytingar eða eyðingar gagna. Lítið safn með þröngum SQL-skilyrðum getur hentað nákvæmri leit í PostgreSQL. Þegar leitarmengið stækkar og síur verða ráðandi þarf að bera saman nálgaða leit, endurheimt og rekstrarbyrði við sama álag.
Hvað mældist hratt og við hvaða aðstæður?
Í fræðilegri samanburðarrannsókn mældist Qdrant með 4,55 ms miðgildi svartíma á SIFT1M, lægst meðal fullra gagnagrunna í þeirri prófun. SIFT1M inniheldur milljón vigra með 128 víddum. Qdrant afgreiddi 216 fyrirspurnir á sekúndu og pgvector 154; endurheimt við hundrað niðurstöður var 0,959 hjá Qdrant og 0,937 hjá pgvector. Vísagerð tók 194,7 sekúndur hjá Qdrant og 414,9 hjá pgvector. Þetta eru niðurstöður fyrir myndlýsingar og vigraleit án skilyrðasía.
Kerfin voru prófuð á einni vél með sjálfgefnum stillingum. Rannsóknin nefnir GCP n2-standard-8, 32 GB vinnsluminni og 500 GB SSD, en tilgreinir jafnframt sex sýndarörgjörva; nákvæm lýsing á örgjörvaúthlutuninni er því óljós. Sjálfgefnar stillingar sýna hvernig kerfin hegðuðu sér án ítarlegrar fínstillingar, ekki mesta hraða sem hvort þeirra getur náð við tiltekna endurheimt.
Í verklegri mælingu Ergini voru notaðir fimm milljónir textavigra með 1536 víddum, sömu 500 fyrirspurnir, tíu niðurstöður í svari, upphitaðir hnútar og engin þjöppun. pgvector á Supabase, með HNSW-stillinguna m=16 og deilt reikniafl, mældist með 14 ms p50, 38 ms p95, 0,96 endurheimt við tíu niðurstöður og um 32 mínútna vísagerð. Qdrant 1.x á einum hnúti með fjórum sýndarörgjörvum mældist með 8 ms p50, 21 ms p95, 0,98 endurheimt og um 18 mínútna vísagerð. Höfundurinn segir niðurstöður geta breyst um 20–40% eftir álagi og umhverfi; það er fyrirvari hans, ekki mæld óvissa prófsins.
Seinni mælingin notar sama gagnasafn og sömu fyrirspurnir fyrir kerfin, en hýsing þeirra er ólík. Hún einangrar því ekki áhrif gagnagrunnsins frá áhrifum vélbúnaðar og rekstrarumhverfis. Fyrri rannsóknin notar annað gagnasafn og færri víddir. Tölurnar gefa tvö dæmi um hraðaforskot Qdrant við tilgreind skilyrði, ekki algilda töf fyrir íslenska þjónustu með eigin síum og SQL-tengingum.
Af hverju breyta síur niðurstöðunni?
pgvector styður nákvæma leit og nálgaða leit með HNSW eða IVFFlat. Í skjölun pgvector kemur fram að skilyrði eru metin eftir skönnun nálgaðs vísis. Þröng sía getur því skilað færri niðurstöðum en beðið var um. Endurtekin vísaskönnun getur leitað lengra, en tekur meiri vinnu; hlutvísar og töfluskipting henta ákveðnum dreifingum skilyrða. Ef hefðbundinn vísir þrengir mengið nægilega getur PostgreSQL þess í stað reiknað nákvæma fjarlægð fyrir færslurnar sem eftir standa.
Leiðbeiningar Qdrant um síaða leit lýsa gagnavísum sem meta hve margir vigrar uppfylla skilyrði. Þegar fáir passa getur kerfið reiknað fjarlægð þeirra beint; annars leitar það í síanlegu HNSW-grafi með viðbótartengingum milli vigra sem deila vísuðu gagnagildi. Gagnavísarnir þurfa að vera til staðar þegar grafið er byggt svo þessar tengingar nýtist strax. Tvær eða fleiri strangar síur geta samt rofið leiðir um grafið og lækkað endurheimt, jafnvel þótt hver reitur hafi sinn vísi.
Fyrir leit sem alltaf takmarkast við viðskiptavin eða aðgangsheimild skiptir endurheimt innan leyfða mengisins meira máli en hraði ósíaðrar leitar. Mæling þarf jafnframt að telja hvort svar skili umbeðnum fjölda niðurstaðna. Hraðasta fyrirspurnin nýtist lítið ef hún finnur of fáar leyfðar færslur eða sleppir þeim sem eru næst fyrirspurnarvigrinum.
Hvar fellur rekstrarkostnaðurinn til?
Þegar vigrar og viðskiptagögn eru í PostgreSQL er hægt að nota SQL-tengingar og færslur innan sama gagnagrunns. pgvector nýtir einnig endurheimt PostgreSQL að tilteknum tímapunkti. Það einfaldar samræmi milli vigurs, heimilda og færslunnar sem hann lýsir. Stór vigurvísir er þó ekki ókeypis: hann tekur geymslupláss, þarf tíma í byggingu og getur keppt við annað PostgreSQL-álag um minni og reikniafl.
Ef viðskiptagögnin verða áfram í PostgreSQL en vigrarnir fara í Qdrant þarf sérstaka leið fyrir nýjar færslur, breytingar, eyðingar og þau skilyrði sem leitin byggir á. Töf í samstillingu getur þá þýtt að leitarniðurstaða vísi á gamla útgáfu eða á færslu sem á ekki lengur að birtast. Þetta er arkitektúrafleiðing þess að geyma tengd gögn í tveimur kerfum; umfang vinnunnar ræðst af því hversu fersk og samræmd gögn þjónustan krefst.
Qdrant hefur eigin leiðir til afritunar og endurheimtar. Skjölun um skyndimyndir Qdrant segir að skyndimynd safns á dreifðri uppsetningu nái aðeins til gagna á viðkomandi hnúti og að taka þurfi myndir af hnútunum sérstaklega. Rekstrarreikningurinn þarf því að ná til afrita, endurheimtar, vöktunar, uppfærslna og samstillingar við PostgreSQL. Hýst þjónusta getur tekið við hluta gagnagrunnsrekstrarins, en samræmi við viðskiptagögnin er áfram verkefni teymisins.
Hvernig breytist valið með stærð safnsins?
Lítið safn: Ef SQL-sía skilur aðeins eftir fáar færslur er nákvæm leit í PostgreSQL rökréttur upphafspunktur. Hún finnur raunverulega næstu vigra innan þess mengis og krefst ekki sérstaks vigravísis. Fjöldi vigra í allri töflunni segir þá minna um töfina en fjöldinn sem hver venjuleg fyrirspurn þarf að raða.
Miðlungs safn: HNSW í pgvector getur stytt leitartíma án þess að færa gögn úr PostgreSQL. Verð þess er mögulegt tap á endurheimt og viðbótarvinna við vísinn, einkum þegar síur þrengja niðurstöðurnar. Ef fyrirspurnirnar byggjast mikið á SQL-tengingum getur sameiginleg geymsla vegið þyngra en munur á hreinni vigurleit. Ef þröng síun veldur sífellt lengri skönnun verður sérhæfð leit Qdrant áhugaverðari.
Margar milljónir vigra: Verklega mælingin sýndi lægri töf og styttri vísagerð hjá Qdrant á því umfangi, en hún skilgreinir engin almenn mörk þar sem flytja verður gögnin. Vídd vigra, minni, uppfærslutíðni, síur og annað álag á PostgreSQL breyta niðurstöðunni. Við þetta umfang er einnig hægt að bera geymslu og vísagerð við kostnað nýrrar þjónustu, fremur en að reikna aðeins millisekúndur á fyrirspurn.
Mælikvarðarnir sem ráða ákvörðuninni
Sanngjarn samanburður notar sama vigramengi, fjarlægðarmælingu, fyrirspurnir og síur í báðum kerfum. Skrá þarf vélbúnað, minni, geymslu, stillingar vísanna, tíma við vísagerð og töf bæði fyrir venjuleg svör og hægustu svörin. Endurheimt miðað við nákvæma leit sýnir hvort lægri töf fæst með því að missa af réttum niðurstöðum. Sérstaklega þarf að mæla þær síur sem raunveruleg þjónusta notar oftast eða sem þrengja mengið mest.
Rekstrarhliðin á heima í sama samanburði: hversu fljótt verða breytingar og eyðingar sýnilegar, hvað tekur langan tíma að endurheimta þjónustu og hver sinnir samstillingu og vöktun? Ef pgvector stenst kröfur um töf og endurheimt með ásættanlegu PostgreSQL-álagi hefur einfaldara rekstrarform sjálfstætt gildi. Ef Qdrant skilar mælanlega betri þjónustu fyrir raunverulegar, síaðar fyrirspurnir þarf sá ávinningur að standa undir vinnunni við annan gagnagrunn.
Lestu einnig:
Tengdar greinar


Pinecone eða Weaviate: lágmarksverðið segir ekki leitarhraðann

Supabase eða Firebase: gagnalíkanið ræður áður en verðið gerir það

Railway eða Render: hraðari smíði getur kostað fyrirsjáanleikann

AlloyDB einangrar gagnagrunn fyrir hvern fulltrúa — en aðeins í forskoðun

Cloudflare Basin fer í almenna notkun — útflutningsgjaldið hverfur
Gerstu áskrifandi að fréttabréfinu okkar
Fáðu nýjustu fréttir af Web3, gervigreind og rafmyntum beint í pósthólfið.