Vektorlagringar (Qdrant)
Kör en Qdrant-vektordatabas i en resursgrupp för embeddings och likhetssökning, och förstå hur den skyddas, exponeras och bevaras.
En vektorlagring är ett Qdrant-kluster som plattformen kör åt dig i en resursgrupp. Applikationer lagrar embeddings i det och söker bland dem efter likhet — lagringen bakom semantisk sökning och retrieval-augmented generation. I portalen finns vektorlagringar under Vektorlagring i sidomenyn.
Vad du får
- En eller flera Qdrant-servrar (replikerna), var och en med en egen beständig volym, dimensionerade av en beräkningsplan.
- Slutpunkter för Qdrants REST-API (port 6333) och gRPC-API (port 6334) inne i klustret, och valfritt även utifrån — se Anslut till en vektorlagring.
- En API-nyckel som klienter skickar med varje anrop.
Med Qdrant självt — samlingar, punkter, sökningar — arbetar du via Qdrants eget API och dess klientbibliotek. Plattformen hanterar servrarna, inte det som lagras i dem.
API-nyckeln är den enda inloggningsuppgiften
Qdrant har inga användare och inga behörigheter per samling: den som visar upp API-nyckeln kan läsa, ändra och radera allt i klustret. Portalen skapar varje vektorlagring med API-nyckelautentisering påslagen. Du kan stänga av den, men då kan varje arbetslast som når klustret göra detsamma utan nyckel, och plattformen vägrar att exponera ett kluster utan API-nyckel utanför Kubernetes-klustret.
När nyckeln visas i portalen registreras det i vektorlagringens aktivitetslogg. Plattformens roller avgör vem som får se eller rotera nyckeln, inte vad en klient som har den får göra.
Repliker och sharding
Varje replik är en Qdrant-server, och en vektorlagrings servrar bildar ett distribuerat Qdrant-kluster. Hur data fördelas över dem bestäms per samling, när du skapar den med Qdrants API:
shard_number— hur många shards samlingen delas upp i. Utelämnar du den använder Qdrant antalet servrar vid den tidpunkt då samlingen skapas.replication_factor— hur många kopior av varje shard som hålls. Den är 1 om du inte anger något, vilket betyder att varje shard finns en gång: en vektorlagring med tre repliker har då varje del av en samling på bara en server, och förlorar åtkomsten till den delen medan servern är nere.
För att en samling ska klara att en server försvinner skapar du den med replication_factor 2 eller
mer, på en vektorlagring med minst så många repliker. Plattformen ber inte Kubernetes att placera
servrarna på olika noder.
Att lägga till repliker i efterhand flyttar inte befintliga shards till de nya servrarna, och att ta bort repliker stoppar servrar utan att först flytta bort deras shards. Se Ändra antalet repliker.
Exponering
Inne i Kubernetes-klustret nås en vektorlagring av de arbetslaster som boundaryns nätverksregler släpper igenom. Två oberoende val öppnar den utåt:
- HTTPS-ingress — REST-API:t och Qdrants instrumentpanel över HTTPS på ett värdnamn, med ett hanterat certifikat. Skapa-guiden slår på det som standard.
- Lastbalanserare — en extern adress som betjänar REST- och gRPC-portarna direkt, utan TLS.
Båda kräver API-nyckelautentisering, och båda kan begränsas till en lista med tillåtna nätverk. Se Nätverk och API-nyckeln.
HTTPS-slutpunkten nås också av arbetslaster i andra boundaries på samma kluster, vars nätverksregler tillåter utgående HTTPS till alla adresser — se Anslut från en arbetslast.
Data och säkerhetskopior
Plattformen tar inga säkerhetskopior eller ögonblicksbilder av en vektorlagring och kan inte återställa en. Datan ligger på servrarnas volymer. För att behålla en kopia tar du ögonblicksbilder av samlingar med Qdrants eget API och sparar dem någon annanstans — se Säkerhetskopiera en samling.