CocoIndex palaiko Qdrant - integracija pasižymi aukštos kokybės "Rust stack" su didesniu apdorojimu nuo galo iki galo, kad būtų užtikrintas duomenų mastelis ir šviežumas. 🎉 Mes ką tik pristatėme naujausius pakeitimus, kurie sprendžia Qdrant iš CocoIndex indeksavimo srauto. natūraliai automatic target schema setup Tai reiškia, kad kūrėjams nereikia atlikti jokios schemos diegimo - įskaitant lentelės, lauko tipo, raktų ir indeksų nustatymą tikslinėms parduotuvėms. Įdiegimas yra schemos išvados iš CocoIndex srauto apibrėžimo rezultatas. Jis jau palaikomas su natūralia integracija su Postgres, Neo4j ir Kuzu. Nėra daugiau rankinių Anksčiau vartotojai turėjo rankiniu būdu sukurti kolekciją prieš indeksavimą: curl -X PUT 'http://localhost:6333/collections/image_search' \ -H 'Content-Type: application/json' \ -d '{ "vectors": { "embedding": { "size": 768, "distance": "Cosine" } } }' Su nauju pakeitimu, vartotojui nereikia atlikti jokių rankinių kolekcijų valdymo. Kaip veikia Vadovaudamasis duomenų srauto programavimo modeliu, vartotojas apibrėžia srautą, kuriame kiekvienas žingsnis turi išvesties duomenų tipo informaciją, o kitas nustatymas įveda duomenų tipo informaciją. (~ 100 eilutės python pabaiga iki pabaigos) Pavyzdys Trumpai tariant, jis gali būti pateiktas kaip ši linija grafikas. Duomenų srauto deklaracijoje, kaip ir aukščiau Tikslas = formulė (šaltinis) Tai reiškia tiek duomenis, tiek numatomą tikslinę schemą. Vieno srauto apibrėžimas skatina duomenų apdorojimą (įskaitant pokyčių tvarkymą) ir tikslinės schemos nustatymą, suteikiant vieną tiesos šaltinį tiek duomenims, tiek schemai. (Pavyzdžiui, jei norite atsipalaiduoti Inferencijos tipai Indeksavimo sraute tiesiogiai į Qdrant eksportuojami įterpimai ir metaduomenys yra viskas, ko jums reikia. doc_embeddings.export( "doc_embeddings", cocoindex.storages.Qdrant(collection_name=QDRANT_COLLECTION), primary_key_fields=["id"], ) Norėdami paleisti pradėti CocoIndex procesą, vartotojai pirmiausia turi paleisti diegimą, kuris apima visą būtiną diegimą bet kokiems reikalingiems atsarginiams galūnėms. cocoindex setup main.py cocoindex setup Sukurkite naują schemos nustatymą, pvz., lenteles / kolekcijas / ir tt. Pakeiskite esamus atsarginius langelius keičiant schemą - jei įmanoma, bandysite atlikti nesunaikinamą atnaujinimą, pvz., pirminiai raktai nesikeičia ir tikslinė saugykla palaiko vietos schemos atnaujinimą (pvz., ALTER TABLE "Postgres"), kitaip nuleiskite ir atkurkite. Atsikratykite nuolatinių galūnių. Vėliau kūrėjai cocoindex update main.py [-L] norėdami pradėti indeksavimo vamzdyną (-L ilgai veikti). Jei atlikote loginius atnaujinimus, kuriems reikia atnaujinti tikslinės parduotuvės schemą, nesijaudinkite. vėl po logikos atnaujinimo. „CocoIndex“ padarys išvadą apie tikslinės parduotuvės schemą. kaip dizaino pasirinkimą, "CocoIndex" neatnaujins jokios schemos be jūsų įspėjimo, nes kai kurie schemos atnaujinimai gali reikšti destruktyvius pakeitimus. cocoindex update cocoindex setup Norint išmesti srautą, tu bėgtum cocoindex drop main.py Nuleidžiama, kai nuleidžiamas srautas. cocoindex drop Visi tikslinių saugyklų "backend" subjektai, pvz., "PostgreSQL" lentelė ar "Qdrant" kolekcija, priklauso srautui kaip išvestiniai duomenys, todėl jie taip pat bus išmesti. Kodėl taikoma automatinė tikslinė schema? Klausimas iš tikrųjų turėtų būti, kodėl gi ne? Tradicinis būdas yra visiškai išsiaiškinti vartotojus ir norėdami nustatyti / atnaujinti tikslinę schemą patys, įskaitant konkrečią schemą. Kada Kaip Apie tikslinę parduotuvę: Vektorinės duomenų bazės (PGVector, Qdrant ir kt.) Reliacinės duomenų bazės (PostgreSQL) Grafinių duomenų bazės (Neo4j, Kuzu ir kt.) Duomenų tipai, kuriuos gaunate, ir jūsų tikslinė schema turi atitikti. Jei yra bet koks vidinis būsenos stebėjimas, pvz., kai apdorojimas didinamas Vidinės lentelės (valstybės stebėjimas) Tai nuobodu ir skausminga tai padaryti rankiniu būdu, nes visos šios sistemos turi susitarti dėl schemos ir struktūros. Rankinis schemų nustatymas ir sinchronizavimas. Glaudus koordinavimas tarp kūrėjų, DevOps ir duomenų inžinierių - žmonės, kurie rašo kodą, gali būti ne tie patys žmonės, kurie jį diegia / paleidžia organizacijoje. Debugging nesuderinamumas tarp srauto logikos ir saugojimo sluoksnių. Gamybos plėtra paprastai yra stresinė. Bet koks judančių dalių pridėjimas prie indeksavimo vamzdynų sistemos prideda trinties - bet koks nesuderinamumas tarp logikos ir saugojimo schemos gali sukelti tylų gedimą ar subtilius klaidas. Kai kuriais atvejais tai nėra tylios klaidos. Nesėkmė turėtų būti akivaizdi, pvz., jei vartotojai pamiršo sukurti lentelę ar kolekciją, tai tik klaida, kai rašoma į tikslą. Kai kurie kiti scenarijai gali sukelti ne akivaizdžių problemų, t. y. nesinkronizuoti tarp vidinių būsenų saugojimo ir tikslo. pvz. vartotojai gali nuleisti srautą ir atkurti, bet to nepadaryti tikslui; arba nuleisti ir atkurti tikslą, bet to nedaryti vidinei saugojimui. Nuolatiniai sistemos pokyčiai sukelia nuolatinį gamybos skausmą.Kiekvieną kartą, kai duomenų srautas atnaujinamas, tikslinė schema turi vystytis lygiagrečiai. Vienkartinis nuobodus procesas, bet nuolatinis trinties šaltinis. Ne Realaus pasaulio duomenų sistemose nauji laukai dažnai turi būti indeksuojami, senieji išnyksta, o transformacijos vystosi.Jei tipas keičiasi, schema turi prisitaikyti.Šie pokyčiai padidina sudėtingumą ir pabrėžia atsparesnės, prisitaikančios infrastruktūros poreikį. Indeksavimo infrastruktūra reikalauja duomenų nuoseklumo tarp indeksavimo vamzdžio ir tikslinių saugyklų, o kuo mažiau laisvų galų, tuo lengviau ir patikimesnis jis bus. Mūsų vizija: deklaratyvus, srautų pagrindu pagrįstas indeksavimas Kai mes pradėjome „CocoIndex“, mūsų vizija buvo leisti kūrėjams deklaratyviai apibrėžti duomenų transformaciją ir indeksavimo logiką, o „CocoIndex“ atliks likusią dalį. . automatic schema setup Mes esame įsipareigoję rūpintis pagrindine infrastruktūra, kad kūrėjai galėtų sutelkti dėmesį į tai, kas svarbu: duomenis ir logiką. Jei kada nors kovojote, kad jūsų indeksavimo logika ir saugojimo nustatymas būtų sinchronizuoti, mes buvome ten.
