A LanceDB összevetette a Lance, a Delta Lake és az Iceberg teljesítményét
A LanceDB S3-on végzett, 10 000 commitot vizsgáló benchmarkja szerint a Lance rövidebb commitkésleltetést és kisebb aktív metaadat-lábnyomot ért el, mint a Delta Lake és az Iceberg. A vállalat emellett új blobkezelést, világmodell-kutatási platformot és több vállalati funkciót ismertetett.
- A Lance átlagos commitkésleltetése 140 ezredmásodperc volt S3-on.
- Kétszáz egyidejű író mellett a Lance hibaaránya 16 százalékot ért el.
- A Lance Blob V2 csak íráskor materializálja a nagy bináris adatokat.
- A stable-worldmodel közvetlenül S3-ról is képes tanítani.
- A LanceDB táblaszintű, git-szerű ágkezelést vezetett be.
A Lance kevesebb hibával kezelte a párhuzamos írásokat
A LanceDB közlése szerint a 10 000 commitot tartalmazó, Amazon S3-on futtatott tesztben a Lance átlagos commitkésleltetése 140 ezredmásodperc volt. A Delta Lake esetében ez 534 ezredmásodpercet, az Icebergnél pedig 457 ezredmásodpercet tett ki.
Az aktív metaadatok mérete a Lance használatakor 0,78 MiB maradt, miközben az Iceberg esetében meghaladta a 42 MiB-ot. Kétszáz egyidejű író mellett a Lance 16 százalékos hibaarányt produkált, szemben a Delta Lake 88 százalékos, illetve az Iceberg 89 és 94 százalék közötti értékével.
A LanceDB ezt azzal magyarázza, hogy a Lance tömör manifesteket közvetlenül a tárolóba publikál, és nem napló-visszajátszásra vagy katalógusszolgáltatásra támaszkodik.
A Lance Blob V2 csak íráskor materializálja a nagy fájlokat
A Lance Blob V2 a nagy bináris adatok, például az 50 MB-os videók kezelését alakítja át Sparkban. Egy sor címkéjének frissítésekor a rendszernek nem kell beolvasnia a videó teljes tartalmát. A bloboszlopok a lekérdezési tervben könnyű leíróként maradnak, a bájtok pedig csak az írási útvonalon materializálódnak.
Az UPDATE, MERGE, INSERT…SELECT műveletek és az összekapcsolások másolási tokeneket visznek tovább, amelyek az írás során oldódnak fel. Így ugyanabban a táblában a kis bélyegképek és a nagy videoklipek soronként eltérő elrendezést használhatnak séma módosítása nélkül. A LanceDB szerint az SQL-kód változatlan marad, miközben a Spark a tényleges adatok helyett hivatkozásokat mozgat.
Világmodell-kutatás közvetlenül objektumtárolóból
A stable-worldmodel kutatási platform Lance-alapú adatrétege a Push-T adathalmazon helyben körülbelül 4800 mintát olvasott be másodpercenként, szemben a HDF5 körülbelül 1400-as értékével. S3-ról közvetlenül olvasva a teljesítmény mintegy 3200 minta volt másodpercenként, így a tanítás helyi lemezre történő előzetes szinkronizálás nélkül is futhat.
A betöltő nem kötődik egyetlen URI-típushoz. Ugyanaz a kód használható s3:// és gs:// címekkel, HF Buckets tárolóval vagy helyi útvonalakkal. A Lance másolás nélküli adatevolúciója lehetővé teszi vektoros, teljes szöveges és hibrid indexek hozzáadását a tanítási adatokhoz.
A LanceDB közlése szerint a LeWorldModel egyetlen H200 GPU-n, órák alatt, közvetlenül képpontokból tanul. A Push-T teszten 94 százalékos sikerarányt ért el, a tervezési késleltetése pedig 50-szer alacsonyabb volt a DINO-WM értékénél.
Új ágkezelés és keresési fejlesztések vállalati környezetben
A LanceDB vállalati frissítései között szerepel a táblák git-szerű ágkezelése. Az ágak létrehozhatók, törölhetők és kiválaszthatók, miközben az indexelés, a gyorsítótárazás és az írások áganként elkülönülnek. Ez lehetővé teszi a kísérletezést a termelési adatok érintése nélkül.
A vállalat gyorsabb lekérdezésirányítást, egyenletesebb klaszterterhelést és alacsonyabb CPU-használatot is ismertetett. A frissen írt adatok tömörítés előtt már teljes szöveges kereséssel, sorszintű törléssel és részleges oszlopfrissítéssel kezelhetők.
Az open source kiadások között a Lance v8.0.0 és a LanceDB v0.34.0 szerepel. Ezek többek között FM-Indexet, továbbfejlesztett vektoros keresést, teljes szöveges keresési optimalizációkat, natív Polars-integrációt és táblaág-kezelést tartalmaznak. A bejelentések az AI-adatkészletek tárolását, keresését és tanítását egyetlen, többféle adattípust kezelő infrastruktúrában célozzák.
