Qdrant ці pgvector: 216 супраць 154 QPS не вырашаюць пытанне міграцыі

У даследаванні вектарных баз на SIFT1M з мільёнам 128-мерных вектараў Qdrant паказаў 216 QPS, а pgvector — 154 QPS у аднапатокавым пошуку са стандартнымі наладамі і без фільтраў. Гэты вынік паказвае хуткасць канкрэтнага запыту, але не ўлічвае SQL-злучэнні, сінхранізацыю даных і кошт асобнага сховішча.

Калі вектары ўжо захоўваюцца ў PostgreSQL і вынікі рэгулярна трэба злучаць з рэляцыйнымі табліцамі, pgvector звычайна дазваляе захаваць прасцейшую схему. Qdrant мае сэнс разглядаць, калі пошук з фільтрамі стаў самастойнай нагрузкай, а палі адбору можна падтрымліваць у асобнай калекцыі. Падставай для міграцыі будзе выйгрыш на ўласных запытах пры прымальнай якасці выдачы пасля ўліку дадатковай сістэмы.

Што вымярае SIFT1M

QPS — колькасць пошукавых запытаў за секунду ў пэўных умовах. Для набліжанага пошуку аднаго гэтага паказчыка мала: хуткасць залежыць ад таго, колькі сапраўды блізкіх аб’ектаў вяртаецца, якую адлегласць лічаць і наколькі глыбокая выдача. На SIFT1M Qdrant атрымаў і вышэйшую паўнату вынікаў, аднак паказчыкі QPS не былі нармалізаваныя да аднолькавай паўнаты.

SIFT1M складаецца з дэскрыптараў выяў. Пошук па тэкставых эмбэдынгах іншай размернасці дае іншы кошт вылічэння адлегласці і можа інакш выкарыстоўваць індэкс. Таму адзін вынік SIFT1M не дае надзейнага прагнозу для каталога дакументаў ці пошуку па тэксце. Фільтраванне паводле атрыбутаў таксама змяняе нагрузку ў параўнанні з чыстым вектарным пошукам.

Для архітэктурнага рашэння трэба параўноўваць аднолькавыя запыты: тую самую метрыку адлегласці, колькасць вынікаў, фільтры і мэтавую паўнату. Затрымка тыповага запыту і павольных запытаў паказвае іншы бок нагрузкі, чым сумарны QPS. Калі праграме пасля пошуку патрэбны дадатковы SQL-запыт, у яе час адказу ўваходзіць і гэты крок.

Як фільтры змяняюць працу індэкса

У pgvector фільтр пры набліжаным пошуку прымяняецца пасля сканавання індэкса. Дакументацыя pgvector тлумачыць, чаму запыт можа вярнуць менш радкоў за зададзены ліміт, і апісвае ітэратыўнае сканаванне, даступнае з версіі 0.8.0: яно працягвае прагляд індэкса, пакуль не набярэ дастаткова вынікаў або не дасягне мяжы сканавання. Гэта дапамагае пры фільтрах, але дадатковы прагляд каштуе часу і рэсурсаў.

Калі ўмова пакідае невялікую частку радкоў, у PostgreSQL можна спачатку звузіць выбарку звычайным індэксам па полі фільтра і дакладна палічыць адлегласць на ёй. Для невялікай колькасці значэнняў магчымы частковыя HNSW-індэксы; пры многіх значэннях трэба ўлічваць памер і суправаджэнне такіх індэксаў. Выбар паміж гэтымі планамі залежыць ад долі радкоў, якія праходзяць фільтр, а не толькі ад агульнай колькасці вектараў.

У Qdrant індэксаваныя палі payload дапамагаюць фільтраваць падчас абыходу HNSW-графа: механізм індэксавання Qdrant дадае сувязі паміж вузламі з улікам значэнняў гэтых палёў. Індэксы payload лепш стварыць перад загрузкай вектараў; пасля позняга дадання індэкса для новых сувязяў патрэбна перабудова графа. Пры спалучэнні некалькіх строгіх фільтраў граф можа губляць звязнасць, таму перавага такога падыходу залежыць ад фактычнай камбінацыі ўмоў.

Сувязь з PostgreSQL вызначае кошт пераносу

pgvector захоўвае вектар у радку PostgreSQL побач з астатнімі данымі. Таму ў адным SQL-запыце можна сумясціць вектарную блізкасць з катэгорыямі, сувязямі паміж запісамі і ўмовамі доступу. Абнаўленне вектара і звязаных запісаў можа ўдзельнічаць у адной транзакцыі, а рэзервовае капіраванне і аднаўленне застаюцца ў звыклым контуры PostgreSQL.

Qdrant арганізуе пункты з вектарамі і payload у калекцыях і працуе як асобны сэрвіс. Калі зыходны запіс застаецца ў PostgreSQL, праграме трэба перадаваць змены атрыбутаў, новыя вектары і выдаленні ў калекцыю. Пасля пошуку можа спатрэбіцца атрымаць актуальныя радкі з PostgreSQL па ідэнтыфікатарах; гэты дадатковы зварот і час сінхранізацыі ўваходзяць у рэальную затрымку пошуку.

Розніца асабліва прыкметная для правоў доступу. Стабільныя атрыбуты аб’екта зручна капіяваць у payload, каб Qdrant адразу адсяваў непатрэбнае. Калі ж бачнасць залежыць ад часта зменлівых сувязяў карыстальнікаў, груп і запісаў у некалькіх табліцах, асобная база патрабуе абнаўляць іх копію або правяраць правы пасля пошуку. У абодвух выпадках складанасць вынікае з мадэлі даных, а не з самога алгарытму блізкасці.

Памер індэкса і эксплуатацыя

У аглядзе Qdrant апісаны захоўванне вектараў у аператыўнай памяці па змаўчанні, магчымасць перанесці іх і HNSW-індэкс на дыск, а таксама шарды і рэплікі для разгортвання. Дыск дапамагае абмежаваць патрэбу ў памяці, але пры абыходзе графа можа павялічыць колькасць аперацый уводу і вываду. Такі кампраміс важны, калі аб’ём індэкса ўжо набліжаецца да даступнай памяці.

Дадатковыя сувязі ў фільтраваным HNSW Qdrant таксама займаюць месца і павялічваюць час пабудовы індэкса. З іншага боку, pgvector выкарыстоўвае рэсурсы той жа базы, што абслугоўвае транзакцыйныя запыты. Параўнанне агульнага кошту павінна ахопліваць памяць і дыскавы след, час стварэння індэкса, абнаўленні, рэзервовыя копіі і назіранне за асобным сэрвісам. Вынас пошуку мае дадатковую вартасць, калі ён вызваляе рэсурсы PostgreSQL для асноўнай нагрузкі, але гэта трэба вымераць на сваёй сістэме.

Матрыца выбару

• Частыя SQL-злучэнні і агульныя транзакцыі. pgvector захоўвае пошук у той жа базе, дзе ўжо жывуць сувязі і правілы доступу. Гэта асабліва важна, калі выдачу вызначаюць даныя з некалькіх табліц.
• Пастаянныя фільтры па атрыбутах аб’ектаў. Qdrant цікавы, калі гэтыя атрыбуты можна дакладна падтрымліваць у payload і фільтраваны пошук займае значную долю нагрузкі. Правяраць варта рэальныя спалучэнні ўмоў і якасць выдачы.
• Вялікі індэкс або частыя абнаўленні. Выбар залежыць ад памяці, дыска, часу перабудовы і затрымкі падчас запісу. Адна лічба прапускной здольнасці не ўключае гэты кошт.
• Абмежаваныя рэсурсы на эксплуатацыю. pgvector звычайна дае карацейшы шлях, калі PostgreSQL ужо ёсць у сістэме. Для Qdrant трэба закласці сінхранізацыю, маніторынг і аднаўленне асобнага сховішча.

Рашэнне аб міграцыі ўзнікае тады, калі фільтраваныя запыты або ізаляцыя пошукавай нагрузкі даюць вымераную карысць, большую за выдаткі на яшчэ адну базу. Параўноўваць варта поўны час адказу і паўнату вынікаў разам з рэсурсамі абедзвюх схем: менавіта тут архітэктурная розніца становіцца бачнай карыстальніку.

Чытайце таксама:

• Pinecone ці Weaviate: нізкая затрымка не вырашае выбар вектарнай БД
• LangChain ці LlamaIndex: аркестрацыя супраць якасці пошуку ў RAG
• Passkey ці код з аўтэнтыфікатара: фішынг вырашае выбар