> A LanceDB értékelése: Apache-2.0 beágyazott vektoros könyvtár szerver helyett, az IVF és HNSW indexválasztás, hibrid keresés rangsoregyesítéssel, és mit ad hozzá az Enterprise.
>
> Web page: https://balazscsorba.com/hu/blog/lancedb · Language: Magyar · Also available in: [English](https://balazscsorba.com/blog/lancedb.md) · [Deutsch](https://balazscsorba.com/de/blog/lancedb.md)
> Author: Balázs Csorba · Published: 2026-09-21 · Keywords: lancedb, lancedb review, lance vector database, embedded vector database, lancedb vs qdrant, hybrid search rrf, lancedb indexing, lance data format

[Blog](https://balazscsorba.com/hu/blog)/Retrieval és keresés

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

A LanceDB értékelése: Apache-2.0 beágyazott vektoros könyvtár szerver helyett, az IVF és HNSW indexválasztás, hibrid keresés rangsoregyesítéssel, és mit ad hozzá az Enterprise.

[Balázs Csorba](https://balazscsorba.com/hu/about)·2026\. szeptember 21.·9 perc olvasás

-   Vector search
-   Hybrid search
-   Embedded database
-   RAG

![Egymásba ágyazott doboz három lappal, két nyíl egyesül négyzetes és kerek tálcáról.](https://balazscsorba.com/images/blog/lancedb/cover.webp?v=c30c96ee48)

## A lényeg röviden

-   A LanceDB 0.40.0, 2026. október 7-én kiadva, Apache-2.0 licencű Rust-könyvtár az alkalmazás folyamatában, Python, JavaScript és Rust kliensekkel, futtatandó szerver nélkül.
-   Körülbelül egymillió sor alatt a vektorindex opcionális: a gyártó FAQ-ja 100 000 pár 1000 dimenziós vektort 20 ms alatt mér, és kis tábláknál kihagyni ajánlja az indexet.
-   Az HNSW itt nem álló szintű index — csak az IVF-partíciókon belül létezik —, és a dokumentáció figyelmeztet, hogy a HNSW-alapú indexek metaadatfilter alatt nagyobb latenciaszórást mutatnak.
-   A hibrid keresés a legerősebb funkció: BM25 teljes szöveges és vektoros keresés, amelyet reciprocal rank fusion reranker olvaszt össze, alapértelmezett prefilterrel.
-   A gyártó saját összehasonlítása szerint az open-source kiadás 10-50 lekérdezés másodpercenként és 500-1000 ms objektumtárolóról, szemben az Enterprise legfeljebb 10 000 lekérdezésével és 50-200 ms-ával.

Ezen az oldalon

1.  [Mi az a LanceDB](https://balazscsorba.com/#what-it-is)
2.  [Hogyan fut egy lekérdezés](https://balazscsorba.com/#how-it-works)
3.  [Milyen indexet érdemes építeni](https://balazscsorba.com/#indexes)
4.  [Első lépések](https://balazscsorba.com/#getting-started)
5.  [Ahol hibádzik](https://balazscsorba.com/#where-it-shingles)
6.  [Árazás](https://balazscsorba.com/#pricing)
7.  [Ítélet](https://balazscsorba.com/#verdict)
8.  [Források](https://balazscsorba.com/#sources)

Cikk meghallgatása

0:000:00

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.

![Hibrid lekérdezés futása Balról jobbra haladó folyamat: a sorok egy, helyi lemezen vagy objektumtárolón lévő Lance-táblába kerülnek. A tábla párhuzamosan két indexet táplál: egy vektorindexet az embedding oszlop fölött és egy BM25 teljes szöveges indexet a szövegoszlop fölött, a reciprocal rank fusion lépés pedig összefésül mindkét listát egy rangsorolt top-k-ba.](https://balazscsorba.com/images/blog/lancedb/diagram-7.webp?v=27f00da6e7)

Hibrid keresés: egy Lance-tábla táplálja a vektorindexet és a BM25-indexet, a rangsor-egyesítés pedig egyetlen listává vonja őket.

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:

Elsődleges

Index

Tömörítés

Megjegyzés

Maximális tömörítés

IVF\_RQ

A nyers méret kb. 1/32-e

RaBitQ kvantizálás IVF fölött

Pontosság 256 dimenzióig

IVF\_PQ

A nyers méret 1/64-e és 1/16-e között

Termékkvantizálás, a recall a refine\_factorral hangolva

Legjobb recall-latencia arány

IVF\_HNSW\_SQ

Valamivel több mint a nyers méret 1/4-e

IVF-partíciók benne HNSW-vel, skalárkvantizálás

Legnagyobb recall, kvantizálás nélkül

IVF\_HNSW\_FLAT

Nyers méret plusz gráf-overhead

A drága, hűséges opció

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.

**Előbb nprobes, aztán ef**

IVF\_RQ és IVF\_PQ esetén az irányelv: hagyja az `nprobes`\-t alapértelmezésben, és csak akkor emelje, ha a recall kevés; az IVF\_HNSW-változatoknál hagyja az `nprobes`\-t, és előbb az `ef`\-et hangolja, kb. 1,5-szörös k-től akár 10-szeres k-ig. A `refine_factor` 5 és 50 között legyen, és a kevés sort találó filterhez lehet, hogy feljebb kell vinni a `maximum_nprobes`\-t, hogy egyáltalán `limit` eredmény szülessen.

## 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.

**Az építés után érkező sorok**

Az új sorok addig maradnak ki a meglévő indexből, amíg a `optimize()` be nem hajtja őket, és addig a normál keresés lassabb tartalékscan-t fizet, miközben a `fast_search()` kihagyja. Az open-source kiadásban ez a beosztás az Öné: a kompaktálást és az újraindexelést valakinek ütemeznie kell.

## 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.

Motor

Licenc

Indexelési opciók

Üzemeltetési forma

LanceDB

Apache-2.0, beágyazott

IVF és IVF-HNSW, BM25, skalár

Könyvtár a saját folyamatban

Qdrant

Apache-2.0, szerver

Szűrhető HNSW, skalár- és termékkvantizálás

Konténer vagy menedzselt felhő

pgvector

PostgreSQL-licenc

HNSW és IVFFlat Postgresben

Kiterjesztés egy amúgy is futó adatbázisban

Weaviate

BSD-3-Clause

HNSW, flat és dynamic

Egyetlen bináris, opcionális klaszter

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.

**Egy mérés a kötés előtt**

Építse fel az indexet valódi adaton, és mérje a recallt a `bypass_vector_index()` ellen, amely pontos scant futtat, és megadja az igazságot. A két válasz közti rés az approximáció tényleges ára — és ez az a szám, amiből a latenciaköltségvetést írni kell.

## Források

1.  [LanceDB-gyorsindítás](https://docs.lancedb.com/quickstart)
2.  [A LanceDB vektorindexei](https://docs.lancedb.com/indexing/vector-index)
3.  [A LanceDB indexelési útmutatója](https://docs.lancedb.com/indexing/index)
4.  [A LanceDB hibrid keresése](https://docs.lancedb.com/search/hybrid-search)
5.  [LanceDB Enterprise](https://docs.lancedb.com/enterprise)
6.  [A LanceDB gyakori kérdései](https://docs.lancedb.com/faq/faq-oss)
7.  [A LanceDB árai](https://lancedb.com/pricing)
8.  [LanceDB a PyPI-n](https://pypi.org/project/lancedb/)

## Gyakori kérdések

Szükségem van vektorindexre a LanceDB-ben?

Egyelőre nem. Az FAQ szerint a brute-force keresés 20 ms alatt teljesít 100 000 pár 1000 dimenziós vektornál, és azt mondja, hogy vektorindex körülbelül egymillió sor vagy magasabb dimenzió felett éri meg; ez alatt a scan általában elég gyors.

Miért nincs sima HNSW-index?

A LanceDB-ben az HNSW az IVF-partíciókon belüli alépítmény, nem álló szintű index — ez ötvözi az IVF skálázhatóságát és az HNSW recallját. Az elérhető típusok: IVF\_HNSW\_FLAT, IVF\_HNSW\_PQ és IVF\_HNSW\_SQ az IVF-változatok mellett, kvantizálással és anélkül.

Hogyan marad egészséges az index az open-source kiadásban?

Az indexépítések aszinkron futnak, a hozzáfűzött sorok pedig addig maradnak ki, amíg az optimize() be nem hajtja őket. A create\_index azonnal visszatér, a wait\_for\_index a lefedettség készüléséig vár, a fast\_search() pedig kihagyja a lassabb tartalék scan-t a még nem indexelt sorokon.

Mennyibe kerül a LanceDB Enterprise?

Nincs nyilvános árlista: az ároldal kapcsolati űrlap, az Enterprise csomagot pedig managed telepítésként vagy bring-your-own-cloudként árulják SOC 2 Type II és HIPAA lefedettséggel. A gyártó közzétett benchmarkja körülbelül 779 dollár havonta 100 millió vektorra.

Írta: Csorba Balázs

Senior fullstack és AI mérnök Stájerországban – több mint 10 év Vue, Nuxt, Node.js és PHP, ma AI-ügynököknek építek eszközöket.

[AI fejlesztés és MCP szerverek →](https://balazscsorba.com/hu/expertise/ai-engineer)[Rólam →](https://balazscsorba.com/hu/about)

## További cikkek

-   [Embedding-modell választása 2026-ban: ranglisták, költségek és összehasonlító teszt a saját adatokon](https://balazscsorba.com/hu/blog/embedding-model-selection-2026)
-   [Kontextuális visszakeresés és késleltetett chunkolás: a RAG-chunkok visszakapják a kontextusukat](https://balazscsorba.com/hu/blog/contextual-retrieval-late-chunking)
-   [Hozzáférés-kezelés RAG-hoz: jogosultságtudatos visszakeresés dokumentumszivárgás nélkül](https://balazscsorba.com/hu/blog/rag-access-control-permissions)
-   [RAG termékkatalógusra: PIM-adatokból megbízható válaszok](https://balazscsorba.com/hu/blog/rag-product-catalog-pim-data)

## Pont erre van szükséged?

Írj a projektedről vagy a pozícióról – szívesen hallok felőled.

[Lépj velem kapcsolatba](mailto:contact@balazscsorba.com) [Kapcsolódjunk LinkedInen](https://www.linkedin.com/in/balazs-csorba)