Этот инструмент с открытым исходным кодом может сэкономить вашу команду данных сотни часов
9 июня 2025 г.Кокоиндекс поддерживает Qdrantизначально- Интеграция имеет высокопроизводительный стек ржавчины с инкрементной обработкой конец до конца для масштаба и свежести данных. 🎉 Мы только что развернули наше последнее изменение, которое обрабатываетАвтоматическая настройка целевой схемыс Qdrant из потока индексации кокосоиндекса.
Это означает, что разработчикам не нужно делать какую -либо схему, в том числе настройку таблицы, тип поля, ключи и индекс для целевых магазинов. Настройка является результатом вывода схемы из определения потока кокосоиндекса. Он уже поддерживается нативной интеграцией с Postgres, Neo4j и Kuzu. Это обеспечивает более беспрепятственную работу между индексацией и целевыми магазинами.
Больше нет ручной установки
Ранее пользователям приходилось вручную создавать коллекцию перед индексацией:
curl -X PUT 'http://localhost:6333/collections/image_search' \
-H 'Content-Type: application/json' \
-d '{
"vectors": {
"embedding": {
"size": 768,
"distance": "Cosine"
}
}
}'
С новым изменением пользователю не нужно выполнять никакого ручного управления коллекцией.
Как это работает
Следуя модели программирования DataFlow, пользователь определяет поток, где каждый шаг имеет информацию о типе данных, а следующая настройка принимает информацию типа данных. Увидетьпример(~ 100 линий питона конец до конца)
Короче говоря, он может быть представлен как следующий график линии.
В декларативном потоке данных, как указано выше
Target = формула (источник)
Это подразумевает как данные, так и ожидаемую целевую схему. Определение единого потока способствует обработке данных (включая обработку изменений), так и настройку целевой схемы - обеспечивая единственный источник истины как для данных, так и для схемы. Аналогичный способ подумать об этом - это как системы типов, выводящие тип данных от операторов и входов -Тип вывод(например, ржавчина)
В индексационном потоке экспортные встроения и метаданные непосредственно в Qdrant - это все, что вам нужно.
doc_embeddings.export(
"doc_embeddings",
cocoindex.storages.Qdrant(collection_name=QDRANT_COLLECTION),
primary_key_fields=["id"],
)
Чтобы запустить процесс кокосоиндекса, пользователям необходимо сначала запустить настройку, которая охватывает всю необходимую настройку для любых необходимых бэкэндов.
cocoindex setup main.py
cocoindex setup
- Создайте новые бэкэнды для настройки схемы, например, таблицы/коллекции/и т. Д.
- Измените существующие бэкэнды с изменением схемы - он попытается сделать неразрушающее обновление, если это возможно, например, Основные ключи не изменяются и не изменяют и целевую поддержку хранения на месте обновления схемы (например,
ALTER TABLEв Postgres), в противном случае брось и воссоздайте. - Drop устаревшие бэкэнды.
Затем разработчики бегут
cocoindex update main.py [-L]
Чтобы запустить индексацию конвейера (-l для долгого пробега).
Если вы сделали обновления логики, которые требуют обновления схемы в целевом магазине, не беспокойтесь. Когда вы бежитеcocoindex updateснова после обновления логики. Кокоиндекс выведет схему для целевого магазина. Это требуетcocoindex setupЧтобы подтолкнуть схему в магазин Target, который уведомит вас в CLI. В качестве выбора дизайна, кокосоиндекс не будет обновлять какую -либо схему без вашего уведомления, поскольку некоторые обновления схемы могут включать разрушительные изменения.
Чтобы сбросить поток, вы бегали
cocoindex drop main.py
cocoindex dropОтбрасывает бэкэнды при сбрасывании потока.
Все объекты бэкэнд для целевых магазинов - такие как таблица PostgreSQL или коллекция Qdrant - принадлежат потоку в качестве полученных данных, поэтому также будут отброшены.
Почему автоматический вывод с схемой целевой схемы?
Вопрос должен быть действительно, почему бы и нет?
Традиционный способ - это пользователи полностью выясняюткогдаикакЧтобы настроить/обновить сами целевую схему, включая конкретную схему. Индексационные потоки часто охватывают несколько систем. Например:
В целевом магазине:
- Векторные базы данных (PGVector, Qdrant и т. Д.)
- Реляционные базы данных (PostgreSQL)
- Графические базы данных (neo4j, kuzu и т. Д.)
Типы данных, которые вы выводите, и ваша целевая схема должна соответствовать.
Если есть какое -либо внутреннее отслеживание состояний, например, в случае постепенной обработки
- Внутренние таблицы (отслеживание состояний)
Это утомительно и болезненно делать это вручную, так как все эти системы должны согласовать схему и структуру. Обычно это требует:
- Ручная настройка и синхронизация схем.
- Прямая координация между разработчиками, DevOps и инженерами данных - люди, пишущие код, могут быть не теми же людьми, которые развертывают / запускают его в организации.
- Отладка смещений между логикой потока и уровнями хранения.
- Производственное развертывание, как правило, стресс.
Любое добавление движущихся частей к системе индексации трубопровода добавляет трения - любое несоответствие между логикой и схемой хранения может привести к молчаливым сбоям или тонким ошибкам.
- В некоторых случаях это не молчаливые неудачи. Неудача должна быть очевидной, например, Если пользователи забыли создать таблицу или коллекцию, она просто ошибся при записи в цель. В этом случае способ выяснить точную схему/конфигурацию для цели, все еще тонкий.
- Некоторые другие сценарии могут привести к неочевидным вопросам, то есть из-за синхронизации между хранением для внутренних состояний и целью. например Пользователи могут отбросить поток и воссоздать, но не делать это для цели; Или брось и воссоздайте цель, но не сделайте это для внутренней хранения. Тогда они не синхронизированы и будут трудно разоблачить. Суть в том, что трубопровод обычно нуждается в нескольких бэкэндах, и он может быть подвержен ошибке, чтобы держать их в ручную синхронизацию вручную.
Непрерывные изменения в системе вносят постоянные боли в производстве. Каждый раз, когда обновляется поток данных, целевая схема должна развиваться вместе - делать еенетЕдинственный утомительный процесс, но продолжающийся источник трения.
В реальных системах данных новым полям часто нужны индексация, старые устарели, а преобразования развиваются. Если тип меняется, схема должна адаптироваться. Эти сдвиги увеличивают сложность и подчеркивают необходимость в более устойчивой, адаптируемой инфраструктуре.
Следуя модели программирования DataFlow, каждый шаг является полученным данных до конца. Индексирующая инфраструктура требует согласованности данных между индексацией трубопровода и целевыми запасами, а также менее свободными концами, тем проще и более надежными.
Наше видение: декларативная индексация на основе потока
Когда мы начали кокосочех, наше видение заключалось в том, чтобы позволить разработчикам определить преобразование данных и логику индексации, а кокосоиндекс делает все остальное. Один большой шаг к этомуАвтоматическая схема настройкаПолем
Мы стремимся заботиться о базовой инфраструктуре, чтобы разработчики могли сосредоточиться на том, что имеет значение: данные и логика. Мы серьезно, когда мы говорим, вы можете иметь готовый к производству конвейер данных для ИИ с ~ 100 строк кода Python.
Если вы когда -либо боролись с тем, чтобы сохранить свою логику индексации и настройку хранилища в синхронизации - мы были там. Дайте нам знать, что вы хотели бы увидеть дальше.
Оригинал