semadb
v2.0.2
No hay una base de datos vectorial híbrida de múltiples énfasis de Forma / motor de búsqueda
SEMADB es una base de datos / búsqueda vectorial múltiple, múltiple vector, basada en documentos. Está diseñado para ofrecer una API JSON RESTful clara y fácil de usar. Los componentes originales de SEMADB se construyeron para un proyecto de gestión de conocimiento en Semafind antes de convertirse en un proyecto independiente. El objetivo es proporcionar un motor de búsqueda simple, moderno y eficiente que pueda usarse en una variedad de aplicaciones.
¿Buscas una solución alojada? Semadb Cloud Beta está disponible en Rapidapi.
Para comenzar desde la fuente, siga las instrucciones para instalar Go. Esa es la única dependencia requerida para ejecutar SEMADB. Tratamos de mantener a SemADB lo más autónomo posible y actualizado con los últimos lanzamientos de Go.
SEMADB lee toda la configuración de un archivo YAML, hay algunos ejemplos contenidos en la carpeta config . Puede ejecutar un solo servidor usando:
SEMADB_CONFIG=./config/singleServer.yaml go run ./Si está utilizando el código VS como su editor, entonces ya hay tareas prefabricadas que hacen lo mismo pero también lanzan un clúster localmente en modo de depuración.
Después de que se ejecute un servidor, puede usar el archivo de muestras para ver algunas solicitudes de ejemplo que se pueden hacer en el servidor. Para aprovecharlo al máximo, instale la extensión del cliente REST que le permitirá realizar solicitudes directamente en el editor y mostrar los resultados.
Puede ejecutar la última versión de SEMADB utilizando la siguiente imagen del contenedor del repositorio:
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:mainque ejecutará la rama principal. También hay versiones etiquetadas para versiones específicas. Consulte el Registro de contenedores del repositorio estable y las versiones de producción listas.
Puede construir y ejecutar localmente la imagen del contenedor usando:
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 Persistencia de datos: SEMADB almacena datos en un directorio en el disco que se especifica en el archivo de configuración como rootDir . De manera predeterminada, el directorio de datos es ./data y el ejecutable semadb se encuentra en / ded /data como el punto de montaje en el contenedor.
Tenga en cuenta que al usar Docker, el nombre de host y la lista blanca de IPS es posible que deba ajustarse según la configuración de red de Docker. Dejar el nombre de host como una cadena en blanco y configurar la lista blanca en '*' abre SEMADB a cada conexión como se hace en la configuración singleServer.yaml .
¡Las contribuciones son bienvenidas! Lea el archivo de la Guía de contribución para obtener más información. La guía contribuyente también contiene información sobre la arquitectura de SEMADB y cómo comenzar con el desarrollo.
El algoritmo de búsqueda vectorial de SemADB se basa en los siguientes excelentes trabajos de investigación:
Otros índices como cadena o texto siguen un enfoque de índice invertido. El índice invertido es una estructura de datos que almacena una asignación de contenido, como palabras o números, a sus ubicaciones en un archivo de base de datos, o en un documento o un conjunto de documentos. El propósito de un índice invertido es permitir búsquedas rápidas de texto completo, búsquedas de prefijo de cadena, búsqueda de rango de enteros, etc.
SEMADB con valores de configuración predeterminados en una estación de trabajo Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz de trabajo de productos básicos con 16 GB de RAM logra un buen retiro de referencia estándar, similar a los resultados informados:
| V1 | V2 | V2-PQ | V2-BQ | |||||
|---|---|---|---|---|---|---|---|---|
| Conjunto de datos | Recordar | QPS | Recordar | QPS | Recordar | QPS | Recordar | QPS |
| guante-100-ángulo | 0.924 | 973.6 | 0.853 | 773.9 | 0.526 | 628.6 | ||
| dbpedia-openai-100k-angular | 0.990 | 519.9 | 0.920 | 240.8 | 0.766 | 978.6 | ||
| guante 25-angular | 0.999 | 1130.3 | 0.992 | 914.4 | 0.989 | 805.8 | ||
| mnist-784-euclidiano | 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 | ||
| sif-128-euclidiano | 0.999 | 1537.7 | 0.991 | 1272.9 | 0.696 | 967.4 |
Los resultados se obtienen utilizando ann-benchmarks. Las consultas por segundo (QPS) usan el caché de memoria completo con un solo hilo similar a otros métodos, pero no es una buena indicación del rendimiento general. La tubería completa sería más lenta debido al viaje de extremo a extremo de una solicitud tiene la sobrecarga del manejo de HTTP, la codificación, la decodificación de la consulta, el análisis, la validación, el enrutamiento del clúster, las llamadas de procedimientos remotos, la carga de datos desde el disco, etc. Esto depende aún más del hardware, especialmente el disco duro de SSD VS. Sin embargo, el rendimiento en bruto del algoritmo de búsqueda dentro de un solo fragmento sería, en teoría, similar al informado en los trabajos de investigación.
La versión 1 (V1) es la implementación original de búsqueda de vector puro de SEMADB. La versión 2 (V2) es la implementación de búsqueda múltiple, híbrida, búsqueda de palabras clave, etc., que tiene una sobrecarga mucho más alta de decodificación, envío de datos a índices y utilizando cuantizadores. Versión 2 con cuantización del producto (V2-PQ) y cuantización binaria (V2-BQ) Utilice los métodos de cuantización respectivos para reducir el uso de la memoria. Esperamos que el retiro sea menor porque los métodos de cuantización son con pérdida y la búsqueda es aproximada.
El disco frío comienza puede ser realmente lento. En la parte inferior de la cadena se encuentra el disco donde se almacenan todos los datos. Hay dos cachés en juego: el caché en memoria y el caché del archivo del sistema operativo. El caché del sistema operativo no está en nuestro control y se pobla a medida que los archivos se leen o escriben. Cuando se realiza una solicitud, el gráfico de índice se atraviesa y los puntos se cargan desde el disco hasta el caché del sistema operativo y se decodifican en un conjunto de puntos en memoria. La operación de búsqueda a menudo realiza lecturas aleatorias desde el disco a medida que atraviesa el gráfico de similitud; Por lo tanto, durante un inicio en frío, puede llevar mucho tiempo (1 segundo, 10 segundos o más) dependiendo del hardware. Los discos de estado sólido (SSD) se recomiendan encarecidamente por este motivo, ya que sirven lecturas aleatorias mejor. Para las implementaciones de aplicaciones individuales, esto no es una preocupación importante porque esperamos que una parte de los datos / índice se almacene en caché en la memoria o por el sistema operativo durante la operación. Una alternativa es utilizar un diseño de almacenamiento orientado a gráficos personalizado en el disco para que los bloques / páginas estén mejor alineados con los vecinos de los nodos en el gráfico de similitud.
Escala horizontal automática : el número de servidores en SEMADB se puede ajustar, pero solo se sincroniza con el inicio. El Rendezvous Hashing utilizado se moverá 1/n de la cantidad de datos al nuevo servidor o moverá los datos del servidor eliminados a los restantes. Dado que esto solo sucede en el inicio, está más orientado a escalar despliegues hacia arriba o hacia abajo por adelantado en lugar de estar en vivo. La escala automática en vivo es difícil de funcionar de manera segura mientras la base de datos funciona debido a las condiciones de carrera en los servidores. Algunas trampas son: un servidor que se retrasa en la configuración de envío de datos a servidores antiguos, mientras que la transferencia de datos está ocurriendo las solicitudes del usuario deben ser manejadas, cualquier datos incorrectos debe llegar al servidor correcto, el sistema debe recuperarse de un escenario de cerebro dividido si la red está dividida. Muchas bases de datos distribuidas incorporan maquinaria adicional que agrega una complejidad significativa a las manejas, tales como claves de versiones, relojes vectoriales, etc. En este momento, puede ajustar los servidores y reiniciar el clúster para redistribuir los datos.
No escriba una alta disponibilidad : SEMADB está optimizado para buscar cargas de trabajo pesadas. Las operaciones de recopilación y escritura de puntos requieren que todos los involucrados (servidores que se han distribuido datos) participen. En la ruta de búsqueda, las fallas se pueden tolerar porque es una búsqueda estocástica y las caídas ocasionales en el rendimiento debido a fragmentos no disponibles pueden ser aceptables. Descargamos manteniendo un sistema saludable a través del servidor físico fallas en una herramienta de orquestación de contenedores como Kubernetes. Suponemos que el estado configurado de SEMADB se mantendrá activamente y, como resultado, no contiene ningún algoritmos de descubrimiento de pares o consenso en el diseño. Esta elección de diseño nuevamente simplifica la arquitectura de SEMADB y ayuda con el rápido desarrollo. Los diseños originales incluyeron mecanismos de consenso como la balsa y un sistema distribuido totalmente autónomo con el descubrimiento de pares, pero esto se consideró exagerado.
Existen muchos proyectos de búsqueda de vectores de código abierto y motores de búsqueda. Puede ser útil comparar SEMADB con algunos de ellos para ver si uno se ajusta mejor a su caso de uso:
