turbopuffer-ը անցնում է v3-ին. վեկտորային ինդեքսը դառնում է երկրորդական

turbopuffer-ի բլոգում սեպտեմբերի 30-ին հրապարակվել է «RIP, vector database» գրառումը։ Ընկերության ինժեներ Դեն Հարիսոնը նկարագրել է turbopuffer v3 նոր պահպանման ճարտարապետությունը. փաստաթղթերն ու ինդեքսներն այլևս կապված չեն ANN վեկտորային հասցեին, վեկտորային ինդեքսը դառնում է երկրորդական, իսկ հիմնական ինդեքսի դերը անցնում է նոր կառուցվածքին։

Ընկերության հայտարարությամբ՝ փոփոխությունը կարագացնի բոլոր որոնումները՝ տեքստային, regex և վեկտորային, և հիմք կստեղծի turbopuffer-ում շատ ավելի շատ SQL հարցումներ արագ կատարելու համար։

v1-ից v2

turbopuffer-ը սկսվել է որպես սերվերային վեկտորային բազա. փաստաթուղթը բաղկացած էր միայն ID-ից ու վեկտորից, բնօրինակ տվյալները պահվում էին օբյեկտային պահոցում, իսկ արագությունը ապահովում էին NVMe սկավառակներն ու հիշողության քեշերը։ Վեկտորները դասավորվում էին հիերարխիկ կլաստերներով՝ սկզբում SPANN-ով, ավելի ուշ՝ SPFresh-ով, որը ընկերությունն ընտրել էր ինկրեմենտ ինդեքսավորման համար։ Առաջին օգտատերերից էին Cursor-ը և Notion-ը։ Երկրորդ սերունդը ավելացրեց ատրիբուտներով ֆիլտրում և BM25 տեքստային որոնում, ապա regex, մոտավոր համընկնում, ցրված վեկտորներ և ագրեգացիաներ։ Շարժիչը օգտագործվում է նաև այլ խնդիրներում, օրինակ՝ Linear-ի սինխրոնացման համակարգում։ Որոնումն ընդլայնվեց, բայց պահպանման կառուցվածքը մնում էր վեկտորային ինդեքսի վրա, ինչը սահմանափակում էր GROUP BY-ն ու ագրեգացիաները։

Երեք խնդիր

Գրառումը նշում է վեկտորային ինդեքսի կառուցվածքի երեք թերություն։ Առաջինը՝ տվյալների կրկնապատկումը պահոցում. փաստաթղթի ողջ բովանդակությունը պահվում է վեկտորի հասցեում, ուստի բազմավեկտոր ներկայացումները, օրինակ՝ ներդրումը կամ late interaction-ը, նույն տվյալները կրկնում են ամեն վեկտորի վրա։ Երկրորդը՝ գրառումների կրկնապատկումը. SPFresh-ը կլաստերները վերադասավորում է ամեն գրառման, թարմացման կամ ջնջման, քանի որ ատրիբուտներն ու ինվերտ ինդեքսները նույն հասցեին են կապված, մեկ վեկտորի թարմացումը կարող է տեղաշարժել հարյուրավոր ատրիբուտներ և ինդեքսներ։ Երրորդը՝ վեկտորացման սահմանափակումը. ժամանակակից շարժիչները արժեքները մշակում են բլոկներով (DuckDB՝ 2 048 տող, ClickHouse՝ մոտ 65 հազար, Lucene-ի բլոկներում՝ 256 փաստաթուղթ), իսկ turbopuffer-ի ANN կլաստերները լավագույնս աշխատում են 100-200 փաստաթղթի վրա, ուստի ավելի մեծ բլոկներ ցանկացող պլանները չեն անցնի այս սահմանը։

Որպես օրինակ՝ ընկերությունը նշում է իր տեքստային որոնումը. պոստինգները մոտ 256 հաստատուն բլոկների բաժանելը ինդեքսը փոքրացրել է 10 անգամ, իսկ հարցումները՝ արագացրել 20 անգամ։

Ինչ է հաջորդը

v3-ը դեռ արտադրության մեջ չի թողարկվել։ Սեպտեմբերին ընկերությունը հասել է կարևոր փուլի. v3-ում CI թեստերի 100%-ը հաջողությամբ անցնում է։ Թիմն այժմ ճշգրտությունից անցնում է արագությանը և առաջիկա շաբաթներին բենչմարքները կհրապարակի turbopuffer.com/v3-ում, որպեսզի մինչև v3-ի թողարկումը հասնի ու գերազանցի արտադրողականության պարիտետին։

Ըստ turbopuffer-ի՝ համակարգը հյուրընկալում է 1 տրիլիոնից ավելի փաստաթուղթ, մշակում է վայրկյանում 10 միլիոնից ավելի գրառում և սպասարկում է վայրկյանում 25 հազարից ավելի հարցում։ Նախորդ ճարտարապետության համար ընկերությունը վեկտորային որոնումը հասցրել էր 100 միլիարդից ավելի վեկտոր ունեցող առանձին ինդեքսների. p99 ընթերցման ժամանակը 200 միլիվայրկյան էր, իսկ հաճախությունը՝ վայրկյանում 1000-ից ավելի։