semadb
v2.0.2
Keine FUSS-Multi-Index-Hybridvektor-Datenbank / Suchmaschine
Semadb ist eine Multi-Index-, Multi-Vektor-Vektor-Vektor-Datenbank / Suchmaschine. Es soll eine klare und benutzerfreundliche JSON-API-API anbieten. Die ursprünglichen Komponenten von Semadb wurden für ein Wissensmanagementprojekt bei Semafind erstellt, bevor es zu einem eigenständigen Projekt entwickelt wurde. Ziel ist es, eine einfache, moderne und effiziente Suchmaschine bereitzustellen, die in einer Vielzahl von Anwendungen verwendet werden kann.
Auf der Suche nach einer gehosteten Lösung? Semadb Cloud Beta ist auf Rapidapi verfügbar.
Um von der Quelle aus zu beginnen, befolgen Sie bitte die Anweisungen, um Go zu installieren. Dies ist die einzige Abhängigkeit, die zum Ausführen von Semadb erforderlich ist. Wir versuchen, Semadb so in sich geschlossen wie möglich und mit den neuesten GO-Veröffentlichungen auf dem neuesten Stand zu halten.
Semadb liest die gesamte Konfiguration aus einer YAML -Datei, es gibt einige Beispiele im config . Sie können einen einzelnen Server mit:
SEMADB_CONFIG=./config/singleServer.yaml go run ./Wenn Sie VS-Code als Editor verwenden, gibt es bereits vorgefertigte Aufgaben, die dasselbe erledigen, aber auch einen Cluster lokal im Debug-Modus starten.
Nachdem Sie einen Server ausgeführt haben, können Sie mit der Beispiel -Datei einige Beispielanforderungen an den Server angezeigt werden. Um das Beste daraus zu machen, installieren Sie die REST -Client -Erweiterung, mit der Sie Anfragen direkt im Editor stellen und die Ergebnisse anzeigen können.
Sie können die neueste Version von SemadB über das folgende Repository -Containerbild ausführen:
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:maindas wird die Hauptzweige betreiben. Es gibt auch markierte Versionen für bestimmte Veröffentlichungen. Siehe die Containerregistrierung des Repository Stable und der Produktionsbereitversionen.
Sie können das Containerbild lokal erstellen und ausführen mit:
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 Datenpersistenz: SEMADB speichert Daten in einem Verzeichnis auf der Festplatte, das in der Konfigurationsdatei als rootDir angegeben ist. /data / semadb Datenverzeichnis ./data
Bitte beachten Sie, dass bei Verwendung von Docker das Hostname und die Whitelisting von IPS je nach Netzwerkkonfiguration von Docker möglicherweise angepasst werden müssen. Hostname als leere Zeichenfolge lassen und die Whitelisting auf '*' einstellen, öffnet Semadb für jede Verbindung, wie in der singleServer.yaml -Konfiguration.
Beiträge sind willkommen! Weitere Informationen lesen Sie die Datei mit beitragender Handbuch für weitere Informationen. Der beitragende Leitfaden enthält auch Informationen über die Architektur von Semadb und den Einstieg mit der Entwicklung.
Der Kern -Vektor -Suchalgorithmus von Semadb basiert auf den folgenden hervorragenden Forschungsarbeiten:
Andere Indizes wie Zeichenfolge oder Text folgen einem umgekehrten Indexansatz. Der umgekehrte Index ist eine Datenstruktur, die eine Zuordnung von Inhalten wie Wörtern oder Zahlen, zu ihren Stellen in einer Datenbankdatei oder in einem Dokument oder einer Reihe von Dokumenten speichert. Der Zweck eines umgekehrten Index besteht darin, schnelle Volltext-Suchanfragen, String-Präfix-Lookups, ganzzahlige Bereichsuche usw. zu ermöglichen.
SEMADB mit Standardkonfigurationswerten in einem Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz Commodity Workstation mit 16 GB RAM erreicht einen guten Rückruf über Standard-Benchmarks, ähnlich wie bei den angegebenen Ergebnissen:
| v1 | v2 | v2-pq | V2-BQ | |||||
|---|---|---|---|---|---|---|---|---|
| Datensatz | Abrufen | QPS | Abrufen | QPS | Abrufen | QPS | Abrufen | QPS |
| Handschuh-100-Winkel | 0,924 | 973.6 | 0,853 | 773.9 | 0,526 | 628.6 | ||
| dbpedia-openai-100k-angenular | 0,990 | 519.9 | 0,920 | 240,8 | 0,766 | 978.6 | ||
| Handschuh-25-Winkel | 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-angen | 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 |
Die Ergebnisse werden unter Verwendung von Ann-Benchmarks erhalten. Die Abfragen pro Sekunde (QPS) verwenden den Speichercache mit einem einzelnen Thread, der anderen Methoden ähnelt, ist jedoch kein guter Hinweis auf die Gesamtleistung. Die vollständige Pipeline wäre langsamer, da die End-to-End-Reise einer Anfrage den Overhead der HTTP-Handhabung, -Codierung, Dekodierung von Abfragen, Parsen, Validierung, Cluster-Routing, Remote-Verfahrensanrufen, Ladedaten aus der Festplatte usw. enthält. Die rohe Leistung des Suchalgorithmus innerhalb eines einzelnen Shards wäre jedoch theoretisch der in den Forschungsarbeiten gemeldeten.
Version 1 (V1) ist die ursprüngliche Implementierung der reinen Vektorsuche von Semadb. Version 2 (V2) ist die Multi-Index-, Hybrid-, Schlüsselwortsuche usw.-Implementierung, die einen viel höheren Aufwand für Decodierung, Versand von Daten in Indizes und Verwendung von Quantizern aufweist. Version 2 mit Produktquantisierung (V2-PQ) und binärer Quantisierung (V2-BQ) Verwenden Sie die jeweiligen Quantisierungsmethoden, um die Speicherverwendung zu verringern. Wir erwarten, dass der Rückruf niedriger ist, da die Quantisierungsmethoden verlustweise und die Suche annähernd sind.
Kaltscheibe kann sehr langsam sein. Am Ende der Kette befindet sich die Festplatte, auf der alle Daten gespeichert sind. Es gibt zwei Caches im Spiel: den In-Memory-Cache und den Cache "Betriebssystemdatei". Der Betriebssystem -Cache ist nicht in unserem Steuerelement und wird besiedelt, wenn Dateien gelesen oder geschrieben werden. Wenn eine Anforderung gestellt wird, wird das Indexdiagramm durchquert und die Punkte werden von der Festplatte zum Betriebssystem-Cache geladen und in einen Memory-Satz dekodiert. Die Suchoperation führt häufig zufällige Lesevorgänge von der Festplatte durch, während sie das Ähnlichkeitsgrafik durchquert. Während eines kalten Starts kann es je nach Hardware lange (1 Sekunde, 10 Sekunden oder mehr) dauern. Solid-State-Scheiben (SSDs) werden aus diesem Grund dringend empfohlen, da sie zufällige Lesevorgänge besser dienen. Für einzelne Anwendungsbereitstellungen ist dies kein Hauptanliegen, da wir erwarten, dass ein Teil des Daten / des Index während des Betriebs entweder in Memory oder vom Betriebssystem zwischengespeichert wird. Eine Alternative besteht darin, ein benutzerdefiniertes graphorientiertes Speicherlayout auf der Festplatte zu verwenden, sodass Blöcke / Seiten besser mit Nachbarn von Knoten im Ähnlichkeitsgraphen ausgerichtet sind.
Automatische horizontale Skalierung : Die Anzahl der Server in Semadb kann angepasst werden, aber nur beim Start synchronisiert. Das verwendete Rendezvous -Hashing verschiebt 1/N -Datenmenge auf den neuen Server oder verschiebt die entfernten Serverdaten wieder auf die verbleibenden. Da dies nur beim Start geschieht, ist es eher darauf ausgerichtet, die Bereitstellungen im Voraus zu skalieren, als bei Live -Ladungen. Live -automatische Skalierung ist schwierig, sich sicher aufzutreten, während die Datenbank aufgrund von Rennbedingungen über Server betrieben wird. Einige Fallstricke sind: Ein Server, der in der Konfiguration zurückbleibt und Daten an alte Server sendet, während die Datenübertragung Benutzeranfragen erledigt werden muss. Alle Fehlgegnerdaten müssen schließlich zum richtigen Server gelangen. Das System muss sich von einem Split-Hirn-Szenario wiederherstellen, wenn das Netzwerk verteilt ist. Viele verteilte Datenbanken enthalten zusätzliche Maschinerie, die den damit verarbeitenden Tasten, Vektoruhren usw. erhebliche Komplexität hinzufügen, die Server anpassen und den Cluster neu starten, um die Daten neu zu verteilen.
Kein Schreiben hoher Verfügbarkeit : Semadb ist für die Suche nach schwerer Workloads optimiert. Erfordern einer Beteiligung von Sammlungen und Punktschreibvorgängen (Server, die verteilte Daten) teilnehmen. Auf dem Suchpfad können Fehler toleriert werden, da es sich um eine stochastische Suche handelt und gelegentliche Leistungsabfälle aufgrund nicht verfügbarer Scherben akzeptabel sein können. Wir laden ein gesundes System über physische Serverausfälle in ein Container -Orchestrierungs -Tool wie Kubernetes ab. Wir gehen davon aus, dass der konfigurierte Status von Semadb aktiv aufrechterhalten wird und infolgedessen keine Peer -Entdeckung oder Konsensalgorithmen im Design enthalten. Diese Designauswahl vereinfacht erneut die Architektur von Semadb und hilft mit einer schnellen Entwicklung. Zu den ursprünglichen Konstruktionen gehörten Konsensmechanismen wie Floß und ein vollständig in sich geschlossenes verteiltes System mit Peer-Entdeckung, dies wurde jedoch als übertrieben eingestuft.
Es gibt viele Open-Source-Vektor-Such- und Suchmaschinenprojekte. Es kann hilfreich sein, Semadb mit einigen von ihnen zu vergleichen, um festzustellen, ob man zu Ihrem Anwendungsfall besser passt:
