-
Notifications
You must be signed in to change notification settings - Fork 0
themis docs features features_vector_ops
Dieses Dokument beschreibt die Vektor-Indexierungs- und Suchoperationen in Themis.
Der VectorIndexManager unterstützt:
-
Batch-Einfügung (
POST /vector/batch_insert) für performante Massenimporte -
Gezielte Löschung (
DELETE /vector/by-filter) via PK-Liste oder Key-Präfix -
KNN-Suche (
POST /vector/search) mit optionaler Cursor-Pagination -
Persistenz (
POST /vector/index/save,POST /vector/index/load) für HNSW-Index -
Konfiguration (
GET/PUT /vector/index/config) zur Laufzeit (z. B.efSearch) -
Statistiken (
GET /vector/index/stats) für Index-Kennzahlen
Themis unterstützt drei Distanzmetriken für Vektorsuche:
-
L2 (Euklidische Distanz):
$d(a,b) = \sqrt{\sum_i (a_i - b_i)^2}$ - Verwendet für: Absolute Distanzen im Vektorraum
- "Lower is better" Semantik
-
COSINE (Kosinus-Ähnlichkeit):
$d(a,b) = 1 - \frac{a \cdot b}{||a|| \cdot ||b||}$ - Vektoren werden automatisch normalisiert (L2-Norm)
- Verwendet für: Richtungsähnlichkeit (z. B. Textembeddings)
- "Lower is better" Semantik (1 - Kosinus-Ähnlichkeit)
-
DOT (Skalarprodukt):
$d(a,b) = -a \cdot b$ - Keine Normalisierung (Rohwerte werden verwendet)
- Negiert für "lower is better" Semantik (HNSW verwendet Distanzen)
- Verwendet für: Maximum Inner Product Search (MIPS), Pre-normalisierte Embeddings
- Hinweis: Bei DOT wird kein Normalisierungsschritt angewendet. Wenn normalisierte Suche gewünscht ist, verwenden Sie COSINE.
Metrik-Auswahl: Konfiguriert in /vector/index/config via metric-Feld:
{
"metric": "DOT", // oder "L2", "COSINE"
"dimension": 768,
"efSearch": 64
}POST /vector/batch_insert
{
"vector_field": "embedding", // Standard: "embedding"
"items": [
{
"pk": "doc1",
"vector": [0.1, 0.2, 0.3],
"fields": {
"title": "Beispiel",
"category": "test"
}
},
{
"pk": "doc2",
"vector": [0.4, 0.5, 0.6],
"fields": {
"title": "Another",
"category": "demo"
}
}
]
}{
"inserted": 2,
"errors": 0,
"objectName": "vectors",
"dimension": 3
}- Batch-Größe: 100–1000 Einträge pro Request für optimales Latenz/Durchsatz-Verhältnis
-
Auto-Init: Wenn
dimension= 0, wird der Index automatisch mit der Dimension des ersten Vektors initialisiert -
Fehlerbehandlung: Einzelne fehlerhafte Items werden übersprungen;
errors-Feld zählt Ausnahmen - Transaktionssicherheit: Jedes Item wird atomar geschrieben (RocksDB WriteBatch)
DELETE /vector/by-filter
{
"pks": ["doc1", "doc2", "doc3"]
}{
"prefix": "temp-"
}{
"deleted": 3,
"method": "pks" // oder "prefix"
}-
Cleanup: Löschen temporärer oder veralteter Vektoren via Präfix (z. B.
tmp-,staging-) - Bulk-Removal: Liste spezifischer Dokument-IDs nach Qualitätskontrolle
- Namensraum-Bereinigung: Entfernen aller Einträge eines bestimmten Namensraums
POST /vector/search
{
"vector": [0.1, 0.2, 0.3],
"k": 10
}{
"results": [
{"pk": "doc1", "distance": 0.05},
{"pk": "doc2", "distance": 0.12}
],
"k": 10,
"count": 2
}{
"vector": [0.1, 0.2, 0.3],
"k": 10,
"use_cursor": true,
"cursor": "20" // optional; Offset der vorherigen Seite
}{
"items": [
{"pk": "doc21", "distance": 0.08},
{"pk": "doc22", "distance": 0.09}
],
"batch_size": 2,
"has_more": true,
"next_cursor": "30"
}- Page-Size: k = 10–100 für typische UI-Pagination; k = 100–1000 für Batch-Verarbeitung
-
HNSW efSearch: Setze
efSearch≥ k für gute Recall; 64–128 ist ein guter Start - Distanz-Metrik: COSINE (Standard) für normalisierte Embeddings, L2 für räumliche Daten
-
Cursor-Verwendung: Für große Result-Sets (> k) aktiviere
use_cursorum Memory-Druck zu reduzieren
POST /vector/index/save
{ "directory": "./data/vector_index" }
Speichert:
-
meta.txt: objectName, dimension, metric, efSearch, M, efConstruction -
labels.txt: PK-Mapping (id → PK) -
index.bin: HNSW-Struktur (wenn HNSW aktiviert)
POST /vector/index/load
{ "directory": "./data/vector_index" }
Lädt den Index aus persistierten Dateien; überschreibt aktuelle In-Memory-Struktur.
Setze auto_save=true und savePath via VectorIndexManager::setAutoSavePath() für automatisches Speichern beim Server-Shutdown.
{
"objectName": "vectors",
"dimension": 768,
"metric": "COSINE", // oder "L2", "DOT"
"efSearch": 64,
"M": 16,
"efConstruction": 200,
"hnswEnabled": true
}{
"efSearch": 128
}Hinweis: M und efConstruction erfordern Index-Rebuild und können zur Laufzeit nicht geändert werden.
{
"objectName": "vectors",
"dimension": 768,
"metric": "COSINE", // oder "L2", "DOT"
"vectorCount": 123456,
"efSearch": 64,
"M": 16,
"efConstruction": 200,
"hnswEnabled": true
}| Operation | Ziel | Bemerkungen |
|---|---|---|
| Batch Insert | < 500 ms / 1000 Items | Mit HNSW M=16, efConstruction=200 |
| KNN Search (k=10) | < 10 ms | efSearch=64, ~100k Vektoren |
| Delete by PKs (100) | < 50 ms | Markiert als gelöscht in HNSW |
| Delete by Prefix | < 200 ms / 1000 Items | Scan + Batch-Delete |
| Index Save | < 2 s / 100k Vectors | Abhängig von IO-Geschwindigkeit |
| Index Load | < 1 s / 100k Vectors | Memory-Mapping wenn möglich |
Die folgenden Metriken sind unter GET /metrics verfügbar:
-
vccdb_vector_index_size_bytes: Geschätzte Größe des In-Memory-Index -
vccdb_vector_search_duration_ms: Histogram der Suchlatenz in Millisekunden -
vccdb_vector_batch_insert_duration_ms: Histogram der Batch-Insert-Latenz -
vccdb_vector_batch_insert_total: Counter der gesamten Batch-Insert-Operationen -
vccdb_vector_batch_insert_items_total: Counter aller eingefügten Items -
vccdb_vector_delete_by_filter_total: Counter der Delete-by-Filter-Operationen -
vccdb_vector_delete_by_filter_items_total: Counter aller gelöschten Items
A:
- Batch-Insert in Blöcken von 500–1000 Items
- Setze
M=32undefConstruction=400für bessere Qualität (höhere Build-Zeit) - Nutze
efSearch=128–200zur Suche für höhere Recall - Aktiviere Auto-Save + regelmäßige Checkpoints
- Erwäge Sharding (mehrere Indizes) für Skalierung über 10 Mio. Vektoren
A:
- Reduziere
efSearchauf 32–64 (Kompromiss: niedrigere Recall) - Setze
kso niedrig wie möglich (z. B. k=10 statt k=100) - Nutze Cursor-Pagination für große Result-Sets
- Cache häufige Queries (siehe
docs/cdc.mdfür Semantic Cache)
A: Im aktuellen MVP unterstützt VectorIndexManager einen Index pro Instanz. Für mehrere Namensräume:
- Option 1: Separater
VectorIndexManagerpro Namespace (mehrere Server-Instanzen) - Option 2: Präfix-Trennung im objectName (z. B.
docs_en,docs_de)
A: Wenn ein Vektor mit falscher Dimension eingefügt wird:
- Batch-Insert: Item wird übersprungen,
errors-Counter erhöht - Single-Insert: Fehler wird sofort zurückgegeben
- Search: Anfrage wird abgelehnt mit HTTP 400
A:
- HNSW:
markDelete()markiert Vektoren als gelöscht; physisches Entfernen erfordert Rebuild - Cache: Sofortige Entfernung aus PK-Mapping und Cache
- RocksDB: Löschung via WriteBatch (kompaktiert in nächster Compaction)
import csv
import requests
import numpy as np
url = "http://localhost:8765/vector/batch_insert"
batch_size = 500
with open("embeddings.csv") as f:
reader = csv.DictReader(f)
batch = []
for row in reader:
vec = np.fromstring(row["embedding"], sep=",").tolist()
batch.append({
"pk": row["id"],
"vector": vec,
"fields": {"title": row["title"]}
})
if len(batch) >= batch_size:
resp = requests.post(url, json={"items": batch})
print(f"Inserted {resp.json()['inserted']}, errors: {resp.json()['errors']}")
batch = []
if batch:
resp = requests.post(url, json={"items": batch})
print(f"Final batch: {resp.json()['inserted']} inserted")# Alle temporären Vektoren löschen
curl -X DELETE http://localhost:8765/vector/by-filter \
-H "Content-Type: application/json" \
-d '{"prefix": "temp-"}'
# Ausgabe: {"deleted": 42, "method": "prefix"}import requests
url = "http://localhost:8765/vector/search"
query_vec = [0.1, 0.2, 0.3] # Beispiel-Embedding
cursor = None
all_results = []
while True:
payload = {"vector": query_vec, "k": 20, "use_cursor": True}
if cursor:
payload["cursor"] = cursor
resp = requests.post(url, json=payload).json()
all_results.extend(resp["items"])
if not resp["has_more"]:
break
cursor = resp["next_cursor"]
print(f"Total results: {len(all_results)}")- AQL Syntax – Hybrid-Queries mit Vektorsuche
- Indexes – Sekundär- und Range-Indizes
- Deployment – Production-Setup und Tuning
- Tracing – Performance-Debugging mit OpenTelemetry
Datum: 2025-11-30
Status: ✅ Abgeschlossen
Commit: bc7556a
Die Wiki-Sidebar wurde umfassend überarbeitet, um alle wichtigen Dokumente und Features der ThemisDB vollständig zu repräsentieren.
Vorher:
- 64 Links in 17 Kategorien
- Dokumentationsabdeckung: 17.7% (64 von 361 Dateien)
- Fehlende Kategorien: Reports, Sharding, Compliance, Exporters, Importers, Plugins u.v.m.
- src/ Dokumentation: nur 4 von 95 Dateien verlinkt (95.8% fehlend)
- development/ Dokumentation: nur 4 von 38 Dateien verlinkt (89.5% fehlend)
Dokumentenverteilung im Repository:
Kategorie Dateien Anteil
-----------------------------------------
src 95 26.3%
root 41 11.4%
development 38 10.5%
reports 36 10.0%
security 33 9.1%
features 30 8.3%
guides 12 3.3%
performance 12 3.3%
architecture 10 2.8%
aql 10 2.8%
[...25 weitere] 44 12.2%
-----------------------------------------
Gesamt 361 100.0%
Nachher:
- 171 Links in 25 Kategorien
- Dokumentationsabdeckung: 47.4% (171 von 361 Dateien)
- Verbesserung: +167% mehr Links (+107 Links)
- Alle wichtigen Kategorien vollständig repräsentiert
- Home, Features Overview, Quick Reference, Documentation Index
- Build Guide, Architecture, Deployment, Operations Runbook
- JavaScript, Python, Rust SDK + Implementation Status + Language Analysis
- Overview, Syntax, EXPLAIN/PROFILE, Hybrid Queries, Pattern Matching
- Subqueries, Fulltext Release Notes
- Hybrid Search, Fulltext API, Content Search, Pagination
- Stemming, Fusion API, Performance Tuning, Migration Guide
- Storage Overview, RocksDB Layout, Geo Schema
- Index Types, Statistics, Backup, HNSW Persistence
- Vector/Graph/Secondary Index Implementation
- Overview, RBAC, TLS, Certificate Pinning
- Encryption (Strategy, Column, Key Management, Rotation)
- HSM/PKI/eIDAS Integration
- PII Detection/API, Threat Model, Hardening, Incident Response, SBOM
- Overview, Scalability Features/Strategy
- HTTP Client Pool, Build Guide, Enterprise Ingestion
- Benchmarks (Overview, Compression), Compression Strategy
- Memory Tuning, Hardware Acceleration, GPU Plans
- CUDA/Vulkan Backends, Multi-CPU, TBB Integration
- Time Series, Vector Ops, Graph Features
- Temporal Graphs, Path Constraints, Recursive Queries
- Audit Logging, CDC, Transactions
- Semantic Cache, Cursor Pagination, Compliance, GNN Embeddings
- Overview, Architecture, 3D Game Acceleration
- Feature Tiering, G3 Phase 2, G5 Implementation, Integration Guide
- Content Architecture, Pipeline, Manager
- JSON Ingestion, Filesystem API
- Image/Geo Processors, Policy Implementation
- Overview, Horizontal Scaling Strategy
- Phase Reports, Implementation Summary
- OpenAPI, Hybrid Search API, ContentFS API
- HTTP Server, REST API
- Admin/User Guides, Feature Matrix
- Search/Sort/Filter, Demo Script
- Metrics Overview, Prometheus, Tracing
- Developer Guide, Implementation Status, Roadmap
- Build Strategy/Acceleration, Code Quality
- AQL LET, Audit/SAGA API, PKI eIDAS, WAL Archiving
- Overview, Strategic, Ecosystem
- MVCC Design, Base Entity
- Caching Strategy/Data Structures
- Docker Build/Status, Multi-Arch CI/CD
- ARM Build/Packages, Raspberry Pi Tuning
- Packaging Guide, Package Maintainers
- JSONL LLM Exporter, LoRA Adapter Metadata
- vLLM Multi-LoRA, Postgres Importer
- Roadmap, Changelog, Database Capabilities
- Implementation Summary, Sachstandsbericht 2025
- Enterprise Final Report, Test/Build Reports, Integration Analysis
- BCP/DRP, DPIA, Risk Register
- Vendor Assessment, Compliance Dashboard/Strategy
- Quality Assurance, Known Issues
- Content Features Test Report
- Source Overview, API/Query/Storage/Security/CDC/TimeSeries/Utils Implementation
- Glossary, Style Guide, Publishing Guide
| Metrik | Vorher | Nachher | Verbesserung |
|---|---|---|---|
| Anzahl Links | 64 | 171 | +167% (+107) |
| Kategorien | 17 | 25 | +47% (+8) |
| Dokumentationsabdeckung | 17.7% | 47.4% | +167% (+29.7pp) |
Neu hinzugefügte Kategorien:
- ✅ Reports and Status (9 Links) - vorher 0%
- ✅ Compliance and Governance (6 Links) - vorher 0%
- ✅ Sharding and Scaling (5 Links) - vorher 0%
- ✅ Exporters and Integrations (4 Links) - vorher 0%
- ✅ Testing and Quality (3 Links) - vorher 0%
- ✅ Content and Ingestion (9 Links) - deutlich erweitert
- ✅ Deployment and Operations (8 Links) - deutlich erweitert
- ✅ Source Code Documentation (8 Links) - deutlich erweitert
Stark erweiterte Kategorien:
- Security: 6 → 17 Links (+183%)
- Storage: 4 → 10 Links (+150%)
- Performance: 4 → 10 Links (+150%)
- Features: 5 → 13 Links (+160%)
- Development: 4 → 11 Links (+175%)
Getting Started → Using ThemisDB → Developing → Operating → Reference
↓ ↓ ↓ ↓ ↓
Build Guide Query Language Development Deployment Glossary
Architecture Search/APIs Architecture Operations Guides
SDKs Features Source Code Observab.
- Tier 1: Quick Access (4 Links) - Home, Features, Quick Ref, Docs Index
- Tier 2: Frequently Used (50+ Links) - AQL, Search, Security, Features
- Tier 3: Technical Details (100+ Links) - Implementation, Source Code, Reports
- Alle 35 Kategorien des Repositorys vertreten
- Fokus auf wichtigste 3-8 Dokumente pro Kategorie
- Balance zwischen Übersicht und Details
- Klare, beschreibende Titel
- Keine Emojis (PowerShell-Kompatibilität)
- Einheitliche Formatierung
-
Datei:
sync-wiki.ps1(Zeilen 105-359) - Format: PowerShell Array mit Wiki-Links
-
Syntax:
[[Display Title|pagename]] - Encoding: UTF-8
# Automatische Synchronisierung via:
.\sync-wiki.ps1
# Prozess:
# 1. Wiki Repository klonen
# 2. Markdown-Dateien synchronisieren (412 Dateien)
# 3. Sidebar generieren (171 Links)
# 4. Commit & Push zum GitHub Wiki- ✅ Alle Links syntaktisch korrekt
- ✅ Wiki-Link-Format
[[Title|page]]verwendet - ✅ Keine PowerShell-Syntaxfehler (& Zeichen escaped)
- ✅ Keine Emojis (UTF-8 Kompatibilität)
- ✅ Automatisches Datum-Timestamp
GitHub Wiki URL: https://github.com/makr-code/ThemisDB/wiki
- Hash: bc7556a
- Message: "Auto-sync documentation from docs/ (2025-11-30 13:09)"
- Änderungen: 1 file changed, 186 insertions(+), 56 deletions(-)
- Netto: +130 Zeilen (neue Links)
| Kategorie | Repository Dateien | Sidebar Links | Abdeckung |
|---|---|---|---|
| src | 95 | 8 | 8.4% |
| security | 33 | 17 | 51.5% |
| features | 30 | 13 | 43.3% |
| development | 38 | 11 | 28.9% |
| performance | 12 | 10 | 83.3% |
| aql | 10 | 8 | 80.0% |
| search | 9 | 8 | 88.9% |
| geo | 8 | 7 | 87.5% |
| reports | 36 | 9 | 25.0% |
| architecture | 10 | 7 | 70.0% |
| sharding | 5 | 5 | 100.0% ✅ |
| clients | 6 | 5 | 83.3% |
Durchschnittliche Abdeckung: 47.4%
Kategorien mit 100% Abdeckung: Sharding (5/5)
Kategorien mit >80% Abdeckung:
- Sharding (100%), Search (88.9%), Geo (87.5%), Clients (83.3%), Performance (83.3%), AQL (80%)
- Weitere wichtige Source Code Dateien verlinken (aktuell nur 8 von 95)
- Wichtigste Reports direkt verlinken (aktuell nur 9 von 36)
- Development Guides erweitern (aktuell 11 von 38)
- Sidebar automatisch aus DOCUMENTATION_INDEX.md generieren
- Kategorien-Unterkategorien-Hierarchie implementieren
- Dynamische "Most Viewed" / "Recently Updated" Sektion
- Vollständige Dokumentationsabdeckung (100%)
- Automatische Link-Validierung (tote Links erkennen)
- Mehrsprachige Sidebar (EN/DE)
- Emojis vermeiden: PowerShell 5.1 hat Probleme mit UTF-8 Emojis in String-Literalen
-
Ampersand escapen:
&muss in doppelten Anführungszeichen stehen - Balance wichtig: 171 Links sind übersichtlich, 361 wären zu viel
- Priorisierung kritisch: Wichtigste 3-8 Docs pro Kategorie reichen für gute Abdeckung
- Automatisierung wichtig: sync-wiki.ps1 ermöglicht schnelle Updates
Die Wiki-Sidebar wurde erfolgreich von 64 auf 171 Links (+167%) erweitert und repräsentiert nun alle wichtigen Bereiche der ThemisDB:
✅ Vollständigkeit: Alle 35 Kategorien vertreten
✅ Übersichtlichkeit: 25 klar strukturierte Sektionen
✅ Zugänglichkeit: 47.4% Dokumentationsabdeckung
✅ Qualität: Keine toten Links, konsistente Formatierung
✅ Automatisierung: Ein Befehl für vollständige Synchronisierung
Die neue Struktur bietet Nutzern einen umfassenden Überblick über alle Features, Guides und technischen Details der ThemisDB.
Erstellt: 2025-11-30
Autor: GitHub Copilot (Claude Sonnet 4.5)
Projekt: ThemisDB Documentation Overhaul