A LanceDB 10 milliárd vektoros keresést mutatott be
A LanceDB olyan vektorkeresési architektúrát mutatott be, amely 10 millió vektortól 10 milliárd vektorig támogatja a keresést. A vállalat szerint a rendszer elosztott indexeléssel, növekvő adathalmazhoz igazított karbantartással és lekérdezésenként változtatható pontossággal működik.
- A LanceDB 10 milliótól 10 milliárd vektorig mutatta be a keresés skálázását.
- Az öt bites RaBitQ 1614 lekérdezést kezelt másodpercenként 96,2 százalékos visszahívással.
- A 10 milliárd vektoros teszt medián válaszideje 18,05 ezredmásodperc volt.
- Az indexelés és karbantartás elosztott, illetve inkrementális módon is működhet.
- A lekérdezések sebessége és pontossága az index újraépítése nélkül állítható.
A tömörítés a sebességet és a pontosságot is befolyásolja
A LanceDB tesztje 10 millió, egyenként 768 dimenziós képbeágyazást vizsgált. A vállalat a RaBitQ, a termék-kvantálás (PQ) és a skaláris kvantálás (SQ) különböző beállításait hasonlította össze, nyers vektoros finomítás nélkül.
Az öt bites RaBitQ 1614 lekérdezést kezelt másodpercenként 96,2 százalékos visszahívással. A PQ96 1647 lekérdezés/másodperc mellett 68,6 százalékos, a PQ384 pedig 1047 lekérdezés/másodperc mellett 91,5 százalékos visszahívást ért el. Az SQ értékei 789 lekérdezés/másodperc és 95,4 százalékos visszahívás voltak.
A RaBitQ először egy olcsó, egy bites távolságbecsléssel szűri ki a kevésbé ígéretes jelölteket, majd a további biteket csak a megmaradó elemeknél használja. A LanceDB egyik profilozott munkaterhelésében ez a lépés a jelölt sorok mintegy 99,9 százalékát eltávolította, amikor szigorúbbá vált a találati küszöb.
Elosztott indexelés tízmilliárd vektorig
A rendszer az első index létrehozását több gép között osztja fel. A munkatársak párhuzamosan építik az adattábla különböző szegmenseit, majd a LanceDB együtt teszi közzé az elkészült indexet.
Az új adatok érkezésekor a karbantartási útvonal a hozzáadás méretéhez igazodik. Kisebb bővítéseknél a LanceDB az SPFresh használatával olvasztja be az új adatokat, és újraegyensúlyozza az IVF-partíciókat. Nagyobb bővítéseknél több új szegmens készül párhuzamosan, elosztott munkatársakkal. A vállalat szerint így egy új képcsomag hozzáadásához nem szükséges rendszeresen újraépíteni a korábbi szegmenseket.
A 10 milliárd vektoros tesztadatbázist a 10 millió vektoros adathalmaz ezerszeres ismétlésével hozták létre. A 10 milliárd, 768 dimenziós indexbejegyzésnél a medián válaszidő 18,05 ezredmásodperc, a 99. percentilis pedig 21,61 ezredmásodperc volt. 32 párhuzamos kérésnél 951, 256 párhuzamos kérésnél 1066 lekérdezést mértek másodpercenként.
Egy táblából online és offline keresés
A LanceDB szerint ugyanaz az adattábla használható interaktív keresésre és offline visszakeresési feladatokra is. A lekérdezések külön-külön állíthatják be a sebesség és a pontosság egyensúlyát, így az index újraépítése nélkül változtatható a keresés módja.
Az öt bites RaBitQ-index gyors módja dimenziónként egy bitet használ a jelöltek pontozására. Normál módban mind az öt bit felhasználható a pontosabb távolságszámításhoz. A 10 millió vektoros tesztben a gyors módról normál módra váltva a visszahívás 75,0 százalékról 93,1 százalékra nőtt, miközben mindkét mód hozzávetőleg 1700 lekérdezést kezelt másodpercenként.
A LanceDB Enterprise a memória, a helyi NVMe SSD és az objektumtároló kombinációjára épít. A vállalat egyik példájában a teljes ötbites kód memóriában tárolása 4,80 TB memóriát igényelne 10 milliárd vektornál. Egy bit memóriában, négy bit NVMe-n való elhelyezése 0,96 TB memória és 3,84 TB NVMe használatát jelentené, miközben a további pontosságot csak a fennmaradó jelölteknél kellene beolvasni.
LanceDB: From 10 Million to 10 Billion: Vector Search Built to Grow
