semadb
v2.0.2
Без суеты многоиндексная гибридная векторная база данных / поисковая система
SEMADB-многоиндекс, многоветроятная векторная база данных / поисковая система на основе документов. Он предназначен для того, чтобы предложить четкий и простой в использовании JSON RESTFUL API. Первоначальные компоненты SEMADB были построены для проекта управления знаниями в SemaFind, прежде чем он был превращен в автономный проект. Цель состоит в том, чтобы обеспечить простую, современную и эффективную поисковую систему, которую можно использовать в различных приложениях.
Ищете размещенное решение? Semadb Cloud Beta доступна на Rapidapi.
Чтобы начать с источника, пожалуйста, следуйте инструкциям для установки GO. Это единственная зависимость, необходимая для запуска semAdb. Мы стараемся, чтобы SEMADB максимально использовался как можно более автономным и актуальным с последними выпусками GO.
SEMADB считывает всю конфигурацию из файла YAML, в папке config содержатся некоторые примеры. Вы можете запустить один сервер, используя:
SEMADB_CONFIG=./config/singleServer.yaml go run ./Если вы используете VS-код в качестве редактора, то уже есть предварительные задачи, которые делают то же самое, но также также запускают кластер локально в режиме отладки.
После того, как у вас работает сервер, вы можете использовать файл образцов, чтобы увидеть некоторые примеры запросов, которые можно сделать на сервере. Чтобы максимально использовать его, установите расширение клиента REST, которое позволит вам делать запросы непосредственно в редакторе и показать результаты.
Вы можете запустить последнюю версию SEMADB, используя следующее изображение контейнера репозитория:
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 ghcr.io/semafind/semadb:main
# If using podman
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 ghcr.io/semafind/semadb:mainкоторый будет управлять главной ветвью. Есть также тегические версии для конкретных выпусков. См. Контейнерный реестр репозитория стабильных и производственных версий.
Вы можете локально построить и запустить изображение контейнера, используя:
docker build -t semadb ./
docker run -it --rm -v ./config:/config -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data -p 8081:8081 semadb
# If using podman
podman build -t semadb ./
# The :Z argument relabels to access: see https://github.com/containers/podman/issues/3683
podman run -it --rm -v ./config:/config:Z -e SEMADB_CONFIG=/config/singleServer.yaml -v ./data:/data:Z -p 8081:8081 semadb Постоянство данных: SEMADB сохраняет данные в каталоге на диске, который указан в файле конфигурации как rootDir . По умолчанию каталог данных составляет ./data , а исполняемый файл semadb расположен при / дает /data в качестве точки крепления в контейнере.
Обратите внимание, что при использовании Docker имени хоста и белого списка IPS может потребоваться скорректировать в зависимости от конфигурации сети Docker. Оставляя имя хоста в качестве пустой строки и настройка белого списка для '*' открывает SemAdB для каждого соединения, как это сделано в конфигурации singleServer.yaml .
Взносы приветствуются! Пожалуйста, прочитайте файл руководства для получения дополнительной информации. Руководство также содержит информацию об архитектуре SEMADB и о том, как начать работу с разработкой.
Основной алгоритм поиска вектора SEMADB основан на следующих превосходных исследовательских документах:
Другие индексы, такие как строка или текст, следует за инвертированным индексным подходом. Индекс инвертированного - это структура данных, которая хранит отображение из контента, например, слова или числа, в его местоположение в файле базы данных, или в документе или набор документов. Цель инвертированного индекса состоит в том, чтобы разрешить быстрые полнотекстовые поиски, поиск префиксов строки, поиск целочисленного диапазона и т. Д.
SEMADB со значениями конфигурации по умолчанию на Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz ОЗУ обеспечивает хороший отзыв по стандартным контрольным показателям, аналогично сообщаемым результатам:
| v1 | v2 | V2-PQ | V2-BQ | |||||
|---|---|---|---|---|---|---|---|---|
| Набор данных | Отзывать | QPS | Отзывать | QPS | Отзывать | QPS | Отзывать | QPS |
| GLOVE-100-ANGULAR | 0,924 | 973,6 | 0,853 | 773,9 | 0,526 | 628.6 | ||
| Dbpedia-Openai-100K-Ангуляр | 0,990 | 519.9 | 0,920 | 240.8 | 0,766 | 978.6 | ||
| Glove-25-Angular | 0,999 | 1130.3 | 0,992 | 914.4 | 0,989 | 805.8 | ||
| MNIST-784-Euclidean | 0,999 | 1898.6 | 0,999 | 1267.4 | 0,928 | 571.6 | 0,667 | 2369,7 |
| NYTIMES-256-ANGULAR | 0,903 | 1020.6 | 0,891 | 786.7 | 0,438 | 983,6 | ||
| SIFT-128-Euclidean | 0,999 | 1537.7 | 0,991 | 1272,9 | 0,696 | 967.4 |
Результаты получаются с использованием Ann-Benchmarks. Запросы в секунду (QPS) используют полную в кеше памяти с одним потоком, аналогичным другим методам, но не являются хорошим показателем общей производительности. Полный трубопровод будет медленнее из-за сквозного путешествия запроса имеет накладные расходы на обработку HTTP, кодирование, декодирование запроса, анализ, проверка, маршрутизацию кластера, удаленные вызовы процедуры, загрузку данных с диска и т. Д. Тем не менее, необработанная производительность алгоритма поиска в пределах одного осколка, теоретически, будет аналогична тем, что сообщается в исследовательских работах.
Версия 1 (v1) - оригинальная реализация чистого вектора SemADB. Версия 2 (v2)-это многоиндексная, гибридная, ключевая поиска и т. Д., Который имеет гораздо более высокий накладной наклад, посвященный данным в индексах и использует квантовые средства. Версия 2 с квантованием продукта (V2-PQ) и бинарной квантованием (V2-BQ) используют соответствующие методы квантования для снижения использования памяти. Мы ожидаем, что отзыв будет ниже, потому что методы квантования являются потерянными, а поиск приблизительна.
Запуск холодного диска может быть очень медленным. В нижней части цепи находится диск, где хранятся все данные. В игре есть два кэша: кэш в памяти и кэш файла операционной системы. Кэш ОС не находится в нашем управлении и заполняется, когда файлы читаются или записаны. При выполнении запроса индексный график пересекается, а точки загружаются с диска в кэш операционной системы и декодируют в набор точек в памяти. Операция поиска часто выполняет случайные чтения с диска, когда она пересекает график сходства; Следовательно, во время холодного старта это может занять много времени (1 секунда, 10 секунд или более) в зависимости от оборудования. Твердовые диски (SSD) настоятельно рекомендуются по этой причине, так как они лучше служат случайным чтениям. Для развертывания отдельных приложений это не является серьезной проблемой, потому что мы ожидаем, что часть данных / индекса будет кэширована либо в памяти, либо операционной системой во время работы. Альтернатива состоит в том, чтобы использовать настраиваемую графическую компоновку хранения на диске, чтобы блоки / страницы лучше выровнены с соседями узлов на графике сходства.
Автоматическое горизонтальное масштабирование : количество серверов в SemADB может быть отрегулировано, но оно синхронизируется только при запуске. Используемый хэширование Rendezvous будет перемещать сумму данных 1/n на новый сервер или перенести данные снятого сервера на оставшиеся. Поскольку это происходит только при запуске, он больше ориентирован на расширение развертываний или вниз, чем под прямой нагрузкой. Живое автоматическое масштабирование сложно работать безопасно, в то время как база данных работает из -за условий гонки на серверах. Некоторые подводные камни: сервер, отстающий в конфигурации, отправляя данные на старые серверы, в то время как передача данных происходит, необходимо обрабатывать запросы пользователей, любые неправильные данные должны в конечном итоге поступать на правильный сервер, система должна восстановиться из сценария разделенного мозга, если сеть разделена. Многие распределенные базы данных включают в себя дополнительную технику, которая добавляет значительную сложность, чтобы обрабатывать их, такие как клавиши с версией, векторные часы и т. Д. На данный момент вы можете настроить серверы и перезапустить кластер для перераспределения данных.
Нет высокой доступности записи : SEMADB оптимизирован для поиска тяжелых рабочих нагрузок. Операции сбора и точечной записи требуют всех участия (серверы, которые были распределенными данными) для участия. В пути поиска сбои могут быть допущены, потому что это стохастический поиск, и случайные падения производительности из -за недоступных осколков могут быть приемлемыми. Мы разгружаем поддержание здоровой системы по сбоям физических серверов на инструмент оркестровки контейнера, такой как Kubernetes. Мы предполагаем, что настроенное состояние SEMADB будет активно поддерживаться, и в результате не содержат никаких алгоритмов обнаружения или консенсуса в дизайне. Этот выбор дизайна снова упрощает архитектуру SEMADB и СПИДа с быстрой разработкой. Оригинальные конструкции включали консенсусные механизмы, такие как плот и полностью автономная распределенная система с открытием сверстников, но это было признано излишним.
Есть много векторных поисковых и поисковых проектов с открытым исходным кодом. Может быть полезно сравнить semAdb с некоторыми из них, чтобы увидеть, лучше ли он подходит вашему варианту использования:
