LanceDB: vektoros keresés, amely könyvtárként indul

A LanceDB egy beágyazott vektordatbázis: egy Rust-könyvtár, amely beágyazódik az alkalmazás folyamatába, és vektorokat, metaadatokat és forrásszöveget tárol a Lance oszlopos formátumban. Nincs telepítendő szerver, nincs méretezendő klaszter és nincs hangolni kellő kapcsolatkészlet — ez a legegyértelműbb érv mellette, és ezért érdemes inkább SQLite-szal, mint Qdranttal összehasonlítani.

A beágyazott megoldásokkal versenyez — SQLite vektoros kiterjesztéssel, Chroma, folyamaton belüli index —, és objektumtárolóra mutatva a hosztolt szolgáltatásokkal. Kiváltja azt a mintát, hogy egy egy gépre férő korpuszhoz külön keresőklasztert üzemessenek.

Mi az a LanceDB

A legfrissebb kiadás a 0.40.0, amely 2026. október 7-én jelent meg, és Python 3.10-et vagy újabbat igényel, JavaScriptes és Rustos kliensekkel ugyanazon a Rust magon. Az adatok ott élnek, ahová a csatlakozási URI mutat: helyi könyvtár, s3://, gs://, az:// vagy db:// az Enterprise klaszterhez — és ugyanazokat a Lance-fájlokat mindkét kiadás olvassa.

• Licenc: Apache-2.0 a könyvtárhoz; az Enterprise kereskedelmi termék, managed vagy bring-your-own-cloud formában.
• Forma: beágyazva a saját folyamatban — nincs daemon, nincs sharding, nincs külön lekérdezési nyelv.
• Tárolás: a Lance formátum vektorokat, metaadatokat és nyers adatot tart egyetlen táblában, verziózással és zero-copy olvasással Apache Arrowon át.
• Indexek: IVF_RQ, IVF_PQ, IVF_HNSW_SQ és IVF_HNSW_FLAT vektorokhoz, BM25 teljes szöveghez, plusz skalárindexek.
• Keresés: vektoros, teljes szöveges és hibrid lekérdezések rerankinggel, alapértelmezett prefilterrel, távolsági korlátokkal és pontos scannel.
• Skálázás: kényelmesen egyetlen csomóponton; az FAQ körülbelül 10-50 milliárd sort és 10-30 TB-ot jelöl meg, mielőtt az Enterprise jönne szóba.
• Kliensek: Python, JavaScript és Rust, pippel, npmmel vagy cargóval telepítve.

Hogyan fut egy lekérdezés

Index nélküli keresés az scan: minden vektor összehasonlításra kerül a lekérdezéssel, és a legközelebbi k tér vissza — pontos, és elég gyors, amíg a kicsi a tábla. Az IVF-index edzési időt fordít a vektorok partíciókba rendezésére, így a lekérdezés előbb néhány centroiddal hasonlít, majd azokban a partíciókban nyers erővel számol; az nprobes, alapértelmezésben 20, annyi partíciót nyit meg. Az HNSW aztán partíciónként második szintű gráfként ül benne — ezért mondhatja a dokumentáció, hogy az HNSW nem álló szintű index a LanceDB-ben.

A teljes szöveges keresés külön BM25-index, amelyet a create_fts_index épít, a hibrid keresés pedig mindkét ágat futtatja és összefésüli őket: alapértelmezésben RRF-rerankerral, amely listánként rangokká alakít és összead, így az a találat nyer, amelyik ágban jól rangsorol, anélkül hogy bármelyik pontszám-skálya dominálna. A where filterek alapértelmezésben prefilterek, a pontozás előtt alkalmazva; a prefilter=False a filtert a részlekérdezések mögé teszi, amelyek így kevesebb mint limit sort adhatnak vissza.

A tárolási réteg dönt a latenciaprofilról. Helyi lemezen az olvasás memóriatérképezett és gyors; S3-ra, GCS-re vagy Azure Blobra minden hideg olvasás hálózati roundtrip, és a gyártó saját összehasonlítása szerint ez az open-source kiadásnál 500-1000 ms, az Enterprise-nál 50-200 ms, ahol egy NVMe-gyorsítótár szívja fel az ismétlődő olvasásokat.

Milyen indexet érdemes építeni

Az indexválasztás először tömörítési döntés, és a dokumentáció ehhez egyenes:

Két szabály a dokumentációból fontosabb a táblánál. Az HNSW sosem áll egyedül: mindig csak az IVF-partíciókon belüli alépítmény, tehát nincs sima HNSW-index, amit létre lehetne hozni. És ha a terhelés metaadatfiltert hordoz, a dokumentáció az IVF_RQ-t vagy IVF_PQ-t ajánlja, mert a HNSW-változatok szűrt keresésnél nagyobb latencia-szórást mutatnak.

Első lépések

Telepítse a csomagot, mutasson egy könyvtárra, és a tábla a lemezen van. Az alábbi kódrészlet mindkét indexet felépíti és lefuttatja a hibrid keresést, ahogy a dokumentáció ajánlja, a metaadatfilterrel a pontozás előtt.

import lancedb
from lancedb.rerankers import RRFReranker

db = lancedb.connect("./data")            # a local directory, no server
table = db.open_table("documents")
table.create_fts_index("text")            # BM25, built in the background

results = (
    table.search(query_type="hybrid")
    .vector(embed(query))                 # your embedding model
    .text("refunds within 14 days")
    .where("lang = 'en'", prefilter=True)  # default: filter before scoring
    .rerank(RRFReranker())                # the default hybrid reranker
    .limit(5)
    .to_list()
)
for row in results:
    print(round(row["_relevance_score"], 3), row["text"][:80])

Ebben a kódrészletben nem kell szerver, konténer és API-kulcs sem, és ugyanez a kód s3:// ellen is fut, ha a csatlakozási URI megváltozik. A teljes szöveges és vektoros indexépítések azonnal visszatérnek, és a háttérben fejeződnek be; a wait_for_index és az index_stats együtt az, amivel egy feladat ellenőrzi, hogy nem maradt indexelatlan sor.

Ahol hibádzik

A gyengeségek az architektúrából következnek. Egy folyamat egyetlen gépet jelent: a gyártó saját összehasonlítása az open-source kiadást 10-50 lekérdezésre korlátozza másodpercenként, gyorsítótár nélkül, és minden karbantartási feladat — kompaktálás, újraindexelés, törlés utáni indexfragmentáció — olyan munka, amit valakinek ütemeznie kell. A párhuzamos írásokat a commit újrapróbálásainak száma korlátozza, a Pythonos felhasználókat pedig arra figyelmeztetik, hogy ne forkoljanak.

Az őszinte összefoglaló: a LanceDB a legolcsóbb üzemeltetni és a legtöbb karbantartást igényli. A gyártó táblája egyetlen folyamatra 10-50 lekérdezést ad másodpercenként és 500-1000 ms-t objektumtárolóról, miközben a terjesztett keresés és a platformkezelt kompaktálás az Enterprise oldalon még mindig következőként van jelölve — érdemes tudni, mielőtt egy vásárlási döntés az útitervre támaszkodna.

A másik buktató az API aszimmetriája: egy Enterprise RemoteTable-n a táblaszintű to_arrow és to_pandas hívásokat elutasítja, így az anyagosításnak a query builderen kell átmennie, és egy művelet szolgálati szabályon bukhat meg, nem az adatokon. Az OSS-ről Enterprise-ra vivő kód közel ugyanaz, de nem ugyanaz.

Árazás

A könyvtár Apache-2.0, és minden értelemben ingyenes: pip install, nincs fiók, nincs mérés. Az ároldal nem közöl árlistát — kapcsolati űrlap —, az Enterprise csomagot pedig managed vagy bring-your-own-cloud formában árulják SOC 2 Type II, HIPAA-lefedettség és OpenTelemetry metrikák és nyomkövetések mellett. Az egyetlen konkrét szám, amit a gyártó közzétesz, egy benchmark: körülbelül 779 dollár havonta 100 millió vektorra.

• Open source: a könyvtár, az indexek, a hibrid keresés és a CLI-karbantartási hívások Apache-2.0 alatt, közösségi támogatással.
• Enterprise: managed vagy BYOC, terjesztett lekérdezési csomópontok, NVMe-gyorsítótár, platformon futó indexelés és kompaktálás, valamint SOC 2 Type II és HIPAA megfelelőség.
• Következőként, a gyártó saját táblájában: terjesztett keresés, terjesztett indexelés és kompaktálás.

Ítélet

A LanceDB a jó válasz, ha a korpusz és a forgalom egyetlen gépre fér, és rossz válasz, ha nem — ezt a gyártó saját összehasonlító táblája mondja. Az ereje abban van, hogy a lekérdezés könyvtárhívássá válik, nem infrastrukturális projektté; az ára pedig abban, hogy az adatbázis minden üzemeltetési kötelessége az alkalmazáscsapatra száll. A markáns olvasat: egymillió chunk alatti RAG-pipeline-nál külön vektordatbázist üzemeltetni felesleges szolgáltatás, és a LanceDB az, amit ehhez először érdemes megcélozni.

1. Prototípushoz, egyetlen csomópontú RAG-pipeline-hoz vagy edge-telepítéshez használja, ahol az adatbáziszerver lenne a stack legnehezebb komponense.
2. Használja, ha az adat már objektumtárolón van, és a Lance formátum verziózása és zero-copy olvasása megspórolja a korpusz második példányát.
3. Gondolja meg kétszer, ha a lekérdezéseknek S3-ról 100 ms alatt kell maradniuk valódi párhuzamosság mellett — a gyártó saját száma OSS-re 500-1000 ms és 10-50 lekérdezés másodpercenként.
4. Tervezzen karbantartást: az optimize, a kompaktálás és az újraindexelés az open-source kiadásban nem ütemezett munka, és az indexfragmentáció minden törléssel nő.
5. Az Enterprise csomagot csak a terjesztett részekért válassza; az API-különbségek, a RemoteTable anyagosítási korlátaitól a klaszteroldali guardrail-ekig, ez a valódi kötés.

Források

1. LanceDB-gyorsindítás
2. A LanceDB vektorindexei
3. A LanceDB indexelési útmutatója
4. A LanceDB hibrid keresése
5. LanceDB Enterprise
6. A LanceDB gyakori kérdései
7. A LanceDB árai
8. LanceDB a PyPI-n