A Databricks bemutatta, hogyan skálázható a Lakebase Search

A kereső közvetlenül az alkalmazás adatbázisában fut

A Lakebase Search PostgreSQL-kiterjesztésekként fut a Lakebase Postgresben, az alkalmazás táblái mellett. A fejlesztőknek így nem kell külön keresőrendszerbe másolniuk az adatokat, és második tranzakciós útvonalat sem kell fenntartaniuk.

A rendszer kétféle keresést támogat. A lakebase_vector a szövegek jelentését leíró vektorokkal dolgozik, és a lakebase_ann indexet használja közelítő legközelebbi szomszéd kereséshez. A lakebase_text a BM25 módszerrel a lekérdezés szavait tartalmazó szövegeket rangsorolja. A lakebase_tokenizer opcionális összetevő.

A Databricks belső Slide Hub alkalmazása mintegy 700 prezentációból keres egyedi diákat. A rendszer 23 ezer dia rekordját, a szavazatokat, a keresési adatokat, a változási előzményeket és a keresési indexeket ugyanabban a szerver nélküli Lakebase Postgres-példányban tárolja. A keresés egy SQL-utasításban egyesíti a vektoros és a kulcsszavas találatokat, majd jogosultsági szűrőket és további rangsorolási szabályokat alkalmaz.

A kapacitást a keresés és az alkalmazás is korlátozhatja

A Databricks tesztjeiben a Lakebase Postgres kapacitását Compute Unitban, CU-ban mérték. Egy CU körülbelül 2 GB memóriát biztosít az adatbázisnak, a hozzá tartozó processzor- és helyi SSD-kapacitással együtt. Az adatbázis nemrég olvasott oldalakat Local File Cache-ben, LFC-ben tartja, amely a számítási mérettel együtt növekszik, és a memória legfeljebb 75 százalékát használhatja.

500 egyidejű felhasználónál 1 CU és egy MEDIUM alkalmazás 196 kérést kezelt másodpercenként, 1,8 másodperces medián késleltetéssel. 8 CU-nál a teljesítmény 336 kérésre nőtt másodpercenként, a medián késleltetés pedig 1 másodpercre csökkent. 16 CU és ugyanaz a MEDIUM alkalmazás már csak 4 százalékos többletet hozott. Amikor 16 CU mellé LARGE alkalmazás és négy worker került, a rendszer legalább 662 kérést kezelt másodpercenként, 343 ezredmásodperces mediánnal.

A teszt alapján 8 CU alatt az adatbázis, 8 CU-tól pedig az alkalmazás oldala jelentette a korlátot. A Databricks javaslata szerint először a lekérdezést kell méretezni, ezt követően a Lakebase Postgres kapacitását addig növelni, amíg az alkalmazás workerei válnak szűk keresztmetszetté.

Kisebb jelöltkészlettel gyorsabb lehet a keresés

A Slide Hub eredetileg módszerenként 1000 jelöltet vizsgált. A Databricks 20 nyilvános lekérdezéssel hasonlította össze a 40, 100, 200 és 1000 elemű jelöltkészleteket.

200 jelöltnél a top 10 találat 90,5 százaléka egyezett az 1000 jelöltes referenciaeredménnyel. A lekérdezés 10 401 oldalt érintett, szemben az 1000 jelöltes beállítás 28 972 oldalával. A megismételt keresés medián késleltetése 11,7 ezredmásodperc volt 200 jelöltnél, míg 1000 jelöltnél 35,3 ezredmásodperc.

A Slide Hub ezért 200 jelöltet használ. A Databricks szerint a felhasználók ritkán lapoznak 200 találaton túl. A teljes folyamatot mérve egy hideg, 200 jelöltes keresés 2,9 másodpercig tartott, ismételt futtatáskor pedig 40 ezredmásodpercig. A hideg indításból körülbelül 1 másodpercet az ébredő végpont jelentett.

A hidegindítás költsége alacsony, a folyamatos elérhetőség viszont tervezést igényel

A Lakebase Postgres csak működés közben számít fel számítási költséget. A Databricks egy 14 perces terhelési tesztben 109 ezer kérést szolgált ki, és ehhez 0,02 dollár Lakebase Postgres számítási költséget mért.

A vállalat ugyanakkor éles környezetben 0,5 CU-s, folyamatosan bekapcsolt alapszintet javasol a hidegindítások elkerülésére. A forrás ezt havi 31 és 40 dollár közötti költséggel társítja. A bemutatott eredmények fejlesztőknek és architekteknek szólnak, akik az alkalmazásuk saját Lakebase Postgres-adatbázisában szeretnének keresőt vagy AI-ügynökök számára használható keresési eszközt kialakítani.