Оваа алатка со отворен код може да го спаси вашиот тим за податоци стотици часови

CocoIndex го поддржува Qdrantроденден- интеграцијата се карактеризира со високи перформанси Rust стек со континуирана обработка крај до крај за скала и свежината на податоците. 🎉 Само што ја лансиравме нашата најнова промена која се занимава соautomatic target schema setupсо Qdrant од CocoIndex индексирање на протокот.

Тоа значи дека програмерите не треба да направат никаква конфигурација на шемата - вклучувајќи го и поставувањето на табелата, типот на полето, клучевите и индексот за целните продавници.

Нема повеќе рачно поставување

Претходно, корисниците морале рачно да ја креираат колекцијата пред да ја индексираат:

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

Со новата промена, корисникот не треба да прави никакви рачни управување со собирање.

Како функционира

Следејќи го моделот за програмирање на протокот на податоци, корисникот дефинира проток, каде што секој чекор има информации за излезниот тип на податоци, а следната инсталација ги зема информациите за типот на податоци.Пример(~ 100 линии на python крај до крај)

На кратко, може да се претстави како следната линеарна графика.

Во декларативниот проток на податоци како погоре

Цел = Формула (Извор)

Тоа подразбира и податоци и очекуваната целна шема. Еден поток дефиниција управува и со обработка на податоци (вклучувајќи обработка на промени) и поставување на целна шема – обезбедување на единствен извор на вистина за двете податоци и шема. Сличен начин да се размислува за тоа е како системи со тип заклучување на тип на податоци од оператори и влезови -Тип на инфериорност(На пример, за одмор)

Во протокот за индексирање, извозот на вградувањата и метаподатоците директно во Qdrant е се што ви треба.

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

За да започнете процес на CocoIndex, корисниците прво треба да ја извршат инсталацијата, која ги опфаќа сите потребни инсталации за сите потребни задни завршетоци.

cocoindex setup main.py

cocoindex setup

• Креирајте нови позадина за конфигурацијата на шемата, како што се табели / колекции / итн.
• Променете ги постоечките позадина со промена на шемата - тоа ќе се обиде да направи не-деструктивно ажурирање ако е можно, на пример, примарните клучеви не се менуваат и целта за складирање поддршка на локално ажурирање на шемата (на пример, ALTER TABLE во Postgres), во спротивно фрлање и рекреација.
• Избегнувајте постојани задници.

Развивачите потоа трчаат

cocoindex update main.py [-L]

за да започнете индексирање на цевката (-L за долго траење).

Ако сте направиле логички ажурирања кои бараат да се ажурира шемата на целната продавница, не грижете се.cocoindex updateCocoIndex ќе ја заклучи шемата за целната продавница.cocoindex setupКако избор на дизајн, CocoIndex нема да ажурира никаква шема без ваше известување, бидејќи некои ажурирања на шемата може да вклучуваат деструктивни промени.

За да фрлиш поток, ќе трчаш

cocoindex drop main.py

cocoindex dropИсфрлете ги задните краеви кога ќе го исфрлите протокот.

Сите резервни ентитети за целните продавници - како што се Табела на PostgreSQL или колекција на Qdrant - се во сопственост на протокот како деривати на податоци, така што тие исто така ќе бидат исфрлени.

Зошто автоматска инференција на целната шема?

Прашањето навистина треба да биде, зошто не?

Традиционалниот начин е корисниците целосно да се разбереКогаиКакода се постави / ажурира самата целна шема, вклучувајќи ја и специфичната шема. Потоците за индексирање често опфаќаат повеќе системи.

Во целната продавница:

• Векторски бази на податоци (PGVector, Qdrant, итн.)
• Релациона база на податоци (PostgreSQL)
• Графички бази на податоци (Neo4j, Kuzu итн.)

Типовите на податоци што ги извлекувате и вашата целна шема мора да се совпаѓаат.

Ако постои внатрешно следење на состојбата, на пример, во случај на концентрична обработка

• Внатрешни табели (државно следење)

Тоа е досадно и болно да се направи ова рачно, бидејќи сите овие системи мора да се согласат за шема и структура.

• Рачно поставување и синхронизирање на шеми.
• Тесна координација помеѓу програмерите, DevOps и инженерите за податоци - луѓето кои го пишуваат кодот можеби не се истите луѓе кои го распоредуваат / извршуваат во една организација.
• Дебагирање на неправилностите помеѓу логиката на протокот и слоевите на складирање.
• Развојот на производството е типично стресен.

Секое додавање на движечки делови во системот за индексирање на цевките додава триење - секое несогласување помеѓу логиката и шемата за складирање може да резултира со тивки неуспеси или суптилни грешки.

• Во некои случаи тоа не е тивки неуспеси. неуспехот треба да биде очигледен, на пример, ако корисниците заборавиле да креираат табела или колекција, тоа само ќе биде грешка кога пишување на целта.
• Некои други сценарија може да доведат до не-очигледни проблеми, т.е. надвор од синхронизација помеѓу складирањето за внатрешни состојби и целта. на пример, корисниците може да го напуштат протокот и да го рекреираат, но не го прават тоа за целта; или да го напуштат и рекреираат целта, но не го прават тоа за внатрешно складирање.

Постојаните промени во системот воведуваат упорни болки во производството. Секој пат кога се ажурира протокот на податоци, целната шема мора да се развива заедно – правејќи го тоаНеЕднократен досаден процес, но постојан извор на триење.

Во системите за податоци во реалниот свет, новите полиња често треба да се индексираат, старите се намалуваат, а трансформациите се развиваат.Ако типот се менува, шемата мора да се прилагоди.Овие промени ја зголемуваат комплексноста и ја нагласуваат потребата за повеќе отпорна, прилагодлива инфраструктура.

Инфраструктурата за индексирање бара конзистентност на податоците помеѓу индексирањето и целните складишта, а колку помалку лабавите краеви, толку полесно и посилно ќе биде.

Нашата визија: Декларативно, индексирање врз основа на протокот

Кога го започнавме CocoIndex, нашата визија беше да им овозможиме на програмерите да ја дефинираат трансформацијата на податоците и логиката за индексирање декларативно – а CocoIndex го прави остатокот.automatic schema setup.

Ние сме посветени на грижата за основната инфраструктура, така што програмерите можат да се фокусираат на она што е важно: податоците и логиката.

Ако некогаш сте се бореле со одржување на вашата логика за индексирање и поставувањето на складирањето во синхронизација - ние сме таму.