Ky mjet me burim të hapur mund të shpëtojë ekipin tuaj të të dhënave qindra orë

CocoIndex mbështet Qdrantnatën- integrimi karakterizohet nga një grumbull i lartë i performancës Rust me përpunim incremental nga fundi në fund për shkallë dhe freskinë e të dhënave. 🎉 Ne sapo kemi zbuluar ndryshimin tonë të fundit që merret meautomatic target schema setupQdrant nga rrjedha e indeksimit CocoIndex.

Kjo do të thotë se zhvilluesit nuk kanë nevojë të bëjnë ndonjë konfigurim skemash - duke përfshirë konfigurimin e tabelës, llojit të fushës, çelësave dhe indeksit për dyqanet e synuara. Konfigurimi është rezultat i inferencës së skemave nga përkufizimi i rrjedhës së CocoIndex. Ajo tashmë mbështetet me integrimin nativ me Postgres, Neo4j dhe Kuzu. Kjo lejon një funksionim më të qetë midis indeksimit dhe dyqaneve të synuara.

Jo më manuale

Më parë, përdoruesit duhej të krijonin manualisht koleksionin para indeksimit:

curl -X PUT 'http://localhost:6333/collections/image_search' \
  -H 'Content-Type: application/json' \
  -d '{
    "vectors": {
      "embedding": {
        "size": 768,
        "distance": "Cosine"
      }
    }
  }'

Me ndryshimin e ri, përdoruesi nuk ka nevojë të bëjë ndonjë menaxhim manual të mbledhjes.

Si funksionon

Pas modelit të programimit të rrjedhës së të dhënave, përdoruesi përcakton një rrjedhë, ku çdo hap ka informacion të tipit të të dhënave të prodhimit dhe konfigurimi i ardhshëm merr informacion të tipit të të dhënave.shembull(~100 rreshta të python fund në fund)

Me pak fjalë, ajo mund të paraqitet si grafin e linjave të mëposhtme.

Në rrjedhën deklarative të të dhënave si më sipër

Qëllimi = Formula (Burimi)

Ajo nënkupton të dyja të dhënat dhe skemën e synuar të synuar. Një përkufizim i vetëm i rrjedhës drejton si përpunimin e të dhënave (duke përfshirë trajtimin e ndryshimeve) dhe vendosjen e skemës synuar – duke siguruar një burim të vetëm të së vërtetës për të dy të dhënat dhe skemën.Tipi i inferencës(Për shembull, në mënyrë të qetë)

Në rrjedhën e indeksimit, eksporti i embeddings dhe metadata direkt në Qdrant është e gjitha që ju nevojitet.

doc_embeddings.export(
    "doc_embeddings",
    cocoindex.storages.Qdrant(collection_name=QDRANT_COLLECTION),
    primary_key_fields=["id"],
)

Për të nisur një proces CocoIndex, përdoruesit duhet së pari të drejtojnë instalimin, i cili mbulon të gjithë instalimin e nevojshëm për çdo backend të nevojshëm.

cocoindex setup main.py

cocoindex setup

• Krijo backends të reja për konfigurimin e skemës, të tilla si tabelat / koleksionet / etj.
• Ndrysho backend ekzistuese me ndryshimin e skemës - ajo do të përpiqet të bëjë një përditësim jo-shkatërrues nëse është e mundur, p.sh. çelësat primare nuk ndryshojnë dhe mbështetja e ruajtjes në shënjestër përditëson skemën në vend (p.sh. ALTER TABLE në Postgres), përndryshe tërhiqet dhe ripërtërihet.
• Largimi i mbrapshtave të vazhdueshme

Zhvilluesit pastaj të drejtuar

cocoindex update main.py [-L]

për të filluar një tubacion indeksimi (-L për funksionim të gjatë).

Nëse keni bërë përditësime logjike që kërkojnë që skema në dyqanin e synuar të përditësohet, mos u shqetësoni.cocoindex updatepërsëri pas përditësimit logjik. CocoIndex do të përfundojë skemën për dyqanin e synuar.cocoindex setupSi një zgjedhje e dizajnit, CocoIndex nuk do të përditësojë ndonjë skemë pa njoftimin tuaj, pasi disa përditësime të skemës mund të përfshijnë ndryshime shkatërruese.

Për të lënë një rrjedhë, ju do të vraponi

cocoindex drop main.py

cocoindex dropLëshohet rrjedha kur bie rrjedha.

Të gjitha entitetet backend për dyqanet e synuara - të tilla si një tabelë PostgreSQL ose një koleksion Qdrant - janë në pronësi të rrjedhës si të dhëna të derivuara, kështu që do të hiqen gjithashtu.

Pse skema e synuar automatike inferencë?

Pyetja me të vërtetë duhet të jetë, pse jo?

Mënyra tradicionale është që përdoruesit të kuptojnë plotësishtKurdheSipër të vendosur / përditësuar vetë skemën e synuar, duke përfshirë skemën specifike. rrjedhat e indeksimit shpesh mbulojnë sisteme të shumta. Për shembull:

Në dyqanin e synuar:

• Bazat e të dhënave të vektorëve (PGVector, Qdrant, etj.)
• Bazat e të Dhënave Relative (PostgreSQL)
• Bazat e të dhënave grafike (Neo4j, Kuzu etj.)

Llojet e të dhënave që po nxjerrni dhe skema juaj e synuar duhet të përputhen.

Nëse ka ndonjë gjurmim të brendshëm të gjendjes, p.sh. në rastin e përpunimit incremental

• Tabela e brendshme e gjurmimit (state tracking)

Është e mërzitshme dhe e dhimbshme ta bëni këtë manualisht, pasi të gjitha këto sisteme duhet të bien dakord për skemën dhe strukturën.

• Konfigurimi manual dhe sinkronizimi i skemave.
• Koordinimi i ngushtë midis zhvilluesve, DevOps dhe inxhinierëve të të dhënave - njerëzit që shkruajnë kodin mund të mos jenë të njëjtët njerëz që e vendosin / drejtojnë atë në një organizatë.
• Debugging malalignments midis logjikës rrjedhës dhe shtresat e ruajtjes.
• Rruga e prodhimit është zakonisht stresuese.

Çdo shtim i pjesëve të lëvizshme në sistemin e tubacionit të indeksimit shton fërkime - çdo mosmarrëveshje midis logjikës dhe skemës së ruajtjes mund të rezultojë në dështime të heshtura ose bugs delikate.

• Në disa raste nuk janë dështime të heshtura. dështimi duhet të jetë i dukshëm, p.sh. nëse përdoruesit harruan të krijojnë një tabelë ose koleksion, thjesht do të gabojë kur shkruajnë në objektiv.
• Disa skenarë të tjerë mund të çojnë në probleme jo të dukshme, d.m.th. jashtë sinkronizimit midis ruajtjes për gjendjet e brendshme dhe objektivin. p.sh. përdoruesit mund të lënë rrjedhën dhe të riprodhojnë, por nuk e bëjnë këtë për objektivin; ose të lënë dhe të riprodhojnë objektivin, por nuk e bëjnë këtë për ruajtjen e brendshme.

Ndryshimet e vazhdueshme në një sistem sjellin dhimbje të vazhdueshme në prodhim. Çdo herë që një rrjedhë e të dhënave përditësohet, skema e synuar duhet të evoluojë së bashku – duke e bërë atëjoNjë proces i mërzitshëm, por një burim i vazhdueshëm i fërkimit.

Në sistemet e të dhënave të botës reale, fushat e reja shpesh kanë nevojë për indeksim, fushat e vjetra dobësohen dhe transformimet evoluojnë.Nëse një lloj ndryshon, skema duhet të përshtatet.Këto ndryshime rritin kompleksitetin dhe theksojnë nevojën për infrastrukturë më të qëndrueshme, të adaptueshme.

Duke ndjekur modelin e programimit të rrjedhës së të dhënave, çdo hap rrjedh të dhëna deri në fund.Infrastruktura e indeksimit kërkon konsistencën e të dhënave midis tubacionit të indeksimit dhe magazinave të synuar, dhe sa më pak fundet e lirshme, aq më e lehtë dhe më e fuqishme do të jetë.

Vizioni ynë: Declarative, Flow-Based Indexing

Kur filluam CocoIndex, vizioni ynë ishte të lejonim zhvilluesit të përcaktojnë transformimin e të dhënave dhe logjikën e indeksimit deklarativisht – dhe CocoIndex do të bëjë pjesën tjetër.automatic schema setup.

Ne jemi të përkushtuar të kujdesemi për infrastrukturën themelore, kështu që zhvilluesit mund të përqëndrohen në atë që ka rëndësi: të dhënat dhe logjika.

Nëse keni pasur ndonjëherë vështirësi për të mbajtur logjikën tuaj të indeksimit dhe konfigurimin e ruajtjes në sinkronizim – ne kemi qenë atje.