CocoIndexがQdrantをサポートネイティブ- 統合は、スケールとデータの新鮮さのために、端から端まで増加処理を有する高性能のRust Stackを特徴としています。automatic target schema setupココインデックス指数流のQdrant
つまり、開発者は、ターゲットストアのテーブル、フィールドタイプ、キー、インデックスを設定するなど、スケジュール設定を行う必要はありません。 設定は、CocoIndexのフロー定義からのスケジュール推測の結果です。 Postgres、Neo4j、Kuzuとのネイティブ統合で既にサポートされています。 これにより、インデックスとターゲットストアの間のよりシームレスな操作が可能になります。
もはやマニュアル設定なし
以前は、ユーザーがインデックスする前にコレクションを手動で作成する必要がありました。
curl -X PUT 'http://localhost:6333/collections/image_search' \
-H 'Content-Type: application/json' \
-d '{
"vectors": {
"embedding": {
"size": 768,
"distance": "Cosine"
}
}
}'
新しい変更により、ユーザーは手動のコレクション管理を行う必要はありません。
どのように機能する
データフロープログラミングモデルに従って、ユーザはフローを定義し、各ステップには出力データ型情報が含まれ、次のセットアップではデータ型情報が含まれます。例(Python end to endの100行)
要するに、次の線形グラフとして示すことができます。
上記のようなデータフローで、
ターゲット = 公式(ソース)
単一フロー定義は、データ処理(変更処理を含む)とターゲットスケジュール設定の両方を駆動し、データとスケジュールの両方に単一の真実の源を提供します。INFERENCY タイプ(例えば、リラックス)
インデックス フローでは、インベーディングとメタデータを直接 Qdrant にエクスポートすることはあなたが必要とするすべてです。
doc_embeddings.export(
"doc_embeddings",
cocoindex.storages.Qdrant(collection_name=QDRANT_COLLECTION),
primary_key_fields=["id"],
)
CocoIndex プロセスを起動するには、ユーザーが最初に必要なバックエンドのための必要なすべてのセットアップをカバーするセットアップを実行する必要があります。
cocoindex setup main.py
cocoindex setup
- テーブル/コレクション/etc などのスケジュール設定のための新しいバックエンドを作成します。
- Schema change で既存のバックエンドを変更する - 可能な限り非破壊的なアップデートを実行しようとします。 primary keys don't change. and target storage support in-place schema update (e.g. ALTER TABLE in Postgres), otherwise drop and recreate.
- スタイリッシュなバックエンドをダウンロード
開発者が走る
cocoindex update main.py [-L]
インデックスパイプラインを起動するために(L for long run)
ターゲットストアのスケジュールを更新する必要がある論理更新を行った場合は、心配しないでください。cocoindex updateCocoIndexはターゲットストアのスケジュールを推定します。cocoindex setup設計の選択として、CocoIndexはあなたの通知なしにスケジュールを更新しません、いくつかのスケジュールの更新には破壊的な変更が含まれる可能性があります。
流れを落とすには、あなたは走る
cocoindex drop main.py
cocoindex drop流れを落とすときにバックエンドを落とします。
ターゲットストアのすべてのバックエンドエンティティ(PostgreSQL テーブルや Qdrant コレクションなど)は、リベラルデータとしてフローに所有されているため、削除されます。
なぜ自動ターゲットスケジュールを推測するのか?
本当に問うべきは、なぜそうでないのか。
伝統的な方法は、ユーザーが完全に把握していることです。いつそしてどう特定のスケジュールを含むターゲットスケジュール自体を設定/更新するため、インデックス フローはしばしば複数のシステムをカバーします。
ターゲットショップについて:
- ベクターデータベース(PGVector、Qdrantなど)
- 関連データベース(PostgreSQL)
- グラフデータベース(Neo4j、Kuzuなど)
出力しているデータ型とターゲットスケジュールは一致しなければなりません。
内部状態の追跡がある場合、例えば、増加処理の場合
- 内部テーブル(ステータス・トラッキング)
これを手動で行うのは退屈で痛ましいので、これらのすべてのシステムはスケジュールと構造に合意しなければなりません。
- スケジュールの手動設定と同期
- 開発者、DevOps、およびデータエンジニア間の緊密な連携 - コードを書く人々は、組織内でそれを展開 / 実行する同じ人々ではありません。
- フローロジクスとストレージ層の間の誤差をデバッグする。
- 生産ロールアウトは通常ストレスです。
インデックスパイプラインシステムに移動部品を追加する場合、摩擦が加わります - 論理とストレージ スケジュールの間の不一致は、静かな失敗や微妙なバグにつながる可能性があります。
- たとえば、ユーザーがテーブルやコレクションを作成するのを忘れた場合、ターゲットに書き込むときにエラーが出るだけです。
- 他のいくつかのシナリオは、明らかな問題を引き起こす可能性があります、すなわち、内部状態のストレージとターゲットの間の同期がなくなります. たとえば、ユーザーはフローを落とし、再生することができますが、ターゲットのためにそうすることはありません; または落とし、ターゲットを再生しますが、内部ストレージのためにそうしません。
システムの継続的な変更は、生産に持続的な痛みをもたらします. データフローが更新されるたびに、ターゲット・スケジュールは並行して進化しなければなりません。ノー一度の退屈なプロセスですが、継続的な摩擦の源です。
現実世界のデータシステムでは、新しいフィールドはしばしばインデックスを必要とし、古いフィールドは削減され、変換が進化する。
インデックスインフラストラクチャは、インデックスパイプラインとターゲットストアの間のデータの一貫性を必要とし、より緩やかな端末ほど、より簡単で強力になります。
私たちのビジョン: Declarative, Flow-Based Indexing
当社がCocoIndexを立ち上げたとき、当社のビジョンは、開発者がデータ変換とインデックス化の論理を宣言的に定義できるようにすることでした。automatic schema setup.
私たちは、基本的なインフラストラクチャを管理することに専念していますので、開発者は、データと論理に焦点を当てることができます.We are serious when we say, you can have production-ready data pipeline for AI with ~100 lines of Python code.
インデックスロジックとストレージ設定を同期するのに苦労したことがあるならば、私たちはそこにいました。
