To narzędzie o otwartym kodzie może uratować Twój zespół danych setki godzin

CocoIndex wspiera Qdrantnativnie- integracja charakteryzuje się wysokowydajnym stosem Rust z stopniowym przetwarzaniem od końca do końca dla skali i świeżości danych. 🎉 Właśnie wprowadziliśmy naszą najnowszą zmianę, która obsługujeautomatic target schema setupz Qdrant z CocoIndex indeksowania przepływu.

Oznacza to, że deweloperzy nie muszą wykonywać żadnej konfiguracji schematu - w tym konfiguracji tabeli, typu pola, kluczy i indeksu dla sklepów docelowych. Konfiguracja jest wynikiem inferencji schematu z definicji przepływu CocoIndex. Jest już obsługiwana z native integracją z Postgres, Neo4j i Kuzu.

Brak więcej ręcznych ustawień

Wcześniej użytkownicy musieli ręcznie utworzyć kolekcję przed indeksowaniem:

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

Dzięki nowej zmianie użytkownik nie musi wykonywać żadnego ręcznego zarządzania zbiorem.

Jak to działa

Zgodnie z modelem programowania przepływu danych użytkownik definiuje przepływ, w którym każdy krok zawiera informacje o typie danych wyjściowych, a następne ustawienie zawiera informacje o typie danych.Przykład(~ 100 wierszy pythona od końca do końca)

W skrócie, można go przedstawić jako następujący wykres liniowy.

W deklaracyjnym przepływie danych, jak powyżej

Cel = formuła (źródło)

Oznacza to zarówno dane, jak i oczekiwany schemat docelowy. pojedyncza definicja przepływu napędza zarówno przetwarzanie danych (w tym zarządzanie zmianami) jak i konfigurację schematu docelowego – zapewniając jedno źródło prawdy zarówno dla danych, jak i schematu.Rodzaje inferencji(np. w przypadku spokoju

W strumieniu indeksowania eksport osadzeń i metadanych bezpośrednio do Qdrant to wszystko, czego potrzebujesz.

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

Aby uruchomić proces CocoIndex, użytkownicy muszą najpierw uruchomić ustawienie, które obejmuje wszystkie niezbędne ustawienia dla potrzebnych backendów.

cocoindex setup main.py

cocoindex setup

• Tworzenie nowych backendów dla konfiguracji schematu, takich jak tabele/zbiory/etc.
• Zmiana istniejących backendów ze zmianą schematu - będzie próbować dokonać aktualizacji niezniszczającej, jeśli to możliwe, np. klucze podstawowe nie ulegają zmianie i obsługa układu docelowego aktualizacja schematu na miejscu (np. ALTER TABLE w Postgres), w przeciwnym razie upuść i odtworzyć.
• Pozbądź się stałych backendów.

Następnie deweloperzy biegają

cocoindex update main.py [-L]

Aby rozpocząć indeksowanie rurociągu (-L dla długiego biegu).

Jeśli wprowadziłeś aktualizacje logiczne, które wymagają aktualizacji schematu w sklepie docelowym, nie martw się.cocoindex updateponownie po aktualizacji logiki. CocoIndex dowie się schematu dla sklepu docelowego.cocoindex setupAby przesunąć schemat do sklepu docelowego, który powiadomi Cię w CLI. Jako wybór projektu, CocoIndex nie zaktualizuje żadnego schematu bez powiadomienia, ponieważ niektóre aktualizacje schematu mogą wiązać się z destrukcyjnymi zmianami.

Aby rzucić strumień, biegniesz

cocoindex drop main.py

cocoindex dropWyrzucają się z powrotem, gdy upuszczają strumień.

Wszystkie jednostki backendowe do celowych magazynów – takie jak tabela PostgreSQL lub zbiór Qdrant – są własnością przepływu jako dane pochodne, więc zostaną również usunięte.

Dlaczego automatyczne schematy docelowe?

Pytanie naprawdę powinno być, dlaczego nie?

Tradycyjnym sposobem jest w pełni zrozumieć użytkownikówKiedyijakaby ustawić / zaktualizować schemat docelowy samodzielnie, w tym konkretny schemat. przepływy indeksowania często obejmują wiele systemów.

W sklepie docelowym:

• Wektorowe bazy danych (PGVector, Qdrant itp.)
• Baza danych relacyjnych (PostgreSQL)
• Bazy danych graficznych (Neo4j, Kuzu itp.)

Typy danych, które pobierasz i schemat docelowy muszą pasować.

Jeśli istnieje śledzenie stanu wewnętrznego, np. w przypadku przetwarzania stopniowego

• Tabele wewnętrzne (śledzenie stanu)

Jest to nudne i bolesne, gdy robisz to ręcznie, ponieważ wszystkie te systemy muszą zgodzić się na schemat i strukturę.

• Ręczne konfigurowanie i synchronizacja schematów.
• Ścisła koordynacja między deweloperami, DevOps i inżynierami danych - ludzie, którzy piszą kod, mogą nie być tymi samymi ludźmi, którzy go wdrażają / uruchamiają w organizacji.
• Debugowanie nierównowagi między logiką przepływu a warstwami przechowywania.
• Przebieg produkcji jest zazwyczaj stresujący.

Każde dodanie ruchomych części do układu indeksującego dodaje tarcia – wszelkie niezgodności między logiką a schematem przechowywania mogą prowadzić do cichych awarii lub subtelnych błędów.

• W niektórych przypadkach nie jest to cicha porażka.Niepowodzenie powinno być oczywiste, np. jeśli użytkownicy zapomnieli utworzyć tabelę lub kolekcję, po prostu popełni błąd podczas pisania do celu.
• Niektóre inne scenariusze mogą prowadzić do nie oczywistych problemów, tj. brak synchronizacji między przechowywaniem dla stanów wewnętrznych a celem. np. użytkownicy mogą opuścić przepływ i odtworzyć, ale nie dla celu; lub opuścić i odtworzyć cel, ale nie zrobić tego dla pamięci wewnętrznej.

Ciągłe zmiany w systemie wprowadzają trwałe bóle w produkcji. Za każdym razem, gdy przepływ danych jest aktualizowany, schemat docelowy musi ewoluować równocześnie – czyniąc toNieJednorazowo nudny proces, ale ciągłe źródło tarcia.

W rzeczywistych systemach danych nowe pola często wymagają indeksowania, stare są wyczerpane, a transformacje ewoluują.Jeśli typ się zmienia, schemat musi się dostosować.Te zmiany zwiększają złożoność i podkreślają potrzebę bardziej odpornej, adaptacyjnej infrastruktury.

Infrastruktura indeksowania wymaga spójności danych między rurociągiem indeksowania a magazynami docelowymi, a im mniej luźne końce, tym łatwiejsze i bardziej wytrzymałe będą.

Nasza wizja: deklaratywne, indeksowanie oparte na przepływie

Kiedy założyliśmy CocoIndex, naszą wizją było umożliwienie programistom zdefiniowania transformacji danych i logiki indeksowania w sposób deklaratywny – a CocoIndex zrobi resztę.automatic schema setup.

Jesteśmy zaangażowani w opiekę nad podstawową infrastrukturą, dzięki czemu programiści mogą skupić się na tym, co ma znaczenie: danych i logice.

Jeśli kiedykolwiek zmagałeś się z synchronizacją logiki indeksowania i konfiguracji pamięci masowej – byliśmy tam.