PostgreSQL afstemmen voor pgvector

  • 15 minuten

Vectorzoekworkloads stellen verschillende eisen aan PostgreSQL in vergelijking met traditionele transactionele of analytische query's. Als u deze verschillen begrijpt, kunt u configuratieparameters afstemmen om de querylatentie, het geheugengebruik en de rekenefficiëntie voor AI-toepassingen te optimaliseren.

Opmerking

Codevoorbeelden in deze les demonstreren configuratiepatronen voor PostgreSQL en pgvector. Parameterwaarden die worden weergegeven, zijn uitgangspunten voor het afstemmen. Optimale instellingen zijn afhankelijk van uw specifieke workload, de grootte van de gegevensset en de hardware. Benchmark wijzigingen altijd in een testomgeving voordat u ze toepast in de productieomgeving.

Pgvector-reken- en geheugenvereisten

Het zoeken naar overeenkomsten tussen vectoren omvat het berekenen van afstanden tussen een queryvector en mogelijk miljoenen opgeslagen vectoren. Dit rekenkundige patroon verschilt fundamenteel van traditionele databasebewerkingen die rijen filteren op basis van geïndexeerde kolommen of tabellen samenvoegen op sleutelwaarden.

Wanneer u een vector-overeenkomstenquery uitvoert, moet pgvector de afstand tussen uw queryvector en kandidaatvectoren berekenen. Voor een 1536-dimensionale insluiting (gemeenschappelijk met OpenAI-modellen) omvat elke afstandsberekening 1536 drijvendekommabewerkingen. Voor het doorzoeken van één miljoen vectoren zonder een index zijn meer dan 1,5 miljard drijvendekommabewerkingen per query vereist. De drie afstandsfuncties hebben verschillende rekenkosten die van invloed zijn op uw keuze op basis van uw gegevenskenmerken en prestatievereisten.

  • L2 (Euclidische) afstand: Gebruikt de <-> operator en berekent de vierkantswortel van de som van kwadratische verschillen. Dit is de meest dure optie voor rekenkracht.
  • Cosinusafstand: Gebruikt de <=> operator en meet de hoek tussen vectoren. Het normaliseert vectoren intern, wat extra berekeningen meebrengt, maar wel zorgt voor schaal-invariante similariteit.
  • Binnenste product: Gebruikt de <#> operator en berekent het puntproduct. Dit is de snelste bewerking, maar vereist vooraf genormaliseerde vectoren voor zinvolle overeenkomstenvergelijkingen.

Voor aanbevelingsengines en semantische zoekopdrachten heeft cosinusafstand vaak de voorkeur omdat deze vectoren van verschillende grootten consistent verwerkt. Als uw insluitingen al zijn genormaliseerd (veel insluitings-API's retourneren genormaliseerde vectoren), levert het interne product gelijkwaardige resultaten met minder berekeningen.

Vectorkolommen verbruiken aanzienlijke opslag in vergelijking met traditionele gegevenstypen. Eén 1536-dimensionale vector die is opgeslagen als float4 (enkele precisie) vereist 6.144 bytes, plus overhead. Voor een tabel met één miljoen productsluitingen is ongeveer 6 GB nodig, alleen voor de vectorkolom. Wanneer PostgreSQL vectorquery's verwerkt, worden vectorgegevens in het geheugen geladen. De relatie tussen het beschikbare geheugen en de grootte van vectorgegevens is rechtstreeks van invloed op het feit of query's efficiënt in het geheugen kunnen worden uitgevoerd of herhaaldelijk moeten worden gelezen vanaf de schijf.

Hogere dimensionale insluitingen bieden meer semantische resolutie, maar verhogen zowel opslag- als rekenkosten kwadratisch. Een 3072-dimensionale vector (gebruikt door sommige nieuwere insluitingsmodellen) vereist vier keer het werk van de berekening van de afstand en tweemaal de opslag van een 1536-dimensionale vector. Houd rekening met uw nauwkeurigheidsvereisten bij het kiezen van insluitingsdimensies. Voor veel aanbevelings- en zoektoepassingen bieden 768 of 1024 dimensies voldoende kwaliteit met zinvol lager resourceverbruik.

Geheugenconfiguratie voor vectorworkloads

De geheugenparameters van PostgreSQL zijn aanzienlijk van invloed op de prestaties van vectorquery's. De juiste afstemming zorgt ervoor dat vectorindexen en vaak gebruikte gegevens in het geheugen blijven, waardoor dure schijfbewerkingen worden verminderd.

De parameter bepaalt de shared_buffers gedeelde geheugencache van PostgreSQL, waar vaak geopende gegevenspagina's zich bevinden. Voor vectorworkloads moet deze cache groot genoeg zijn om uw vectorindexen en dynamische gegevens op te slaan. Een cachetrefferverhouding van minder dan 99% voor vector zware workloads geeft aan dat shared_buffers mogelijk te klein is. In Azure Database for PostgreSQL wordt deze parameter automatisch afgestemd op basis van uw rekenlaag, maar u kunt deze binnen het toegestane bereik voor uw laag aanpassen. Voor toegewijde vectorzoekworkloads moet u ervoor zorgen dat shared_buffers groot genoeg is om uw vectorindexen plus een marge voor andere gegevens in de cache op te slaan. Een beginpunt is 25% van het beschikbare geheugen, met toenames op basis van monitoring. Met de volgende query's kunt u de huidige instellingen en cacheprestaties controleren.

-- Check current setting
SHOW shared_buffers;

-- View buffer cache hit ratio
SELECT
    sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read)) AS cache_hit_ratio
FROM pg_statio_user_tables;

De work_mem parameter bepaalt het geheugen dat beschikbaar is voor afzonderlijke querybewerkingen, zoals sorteringen en hash-joins. Vectorvergelijkingsquery's, met name die vectorzoekopdrachten combineren met filteren en ordenen, profiteren van voldoende work_mem. De standaardwaarde work_mem (meestal 4 MB) is vaak te klein voor vectorbewerkingen die resultaten moeten sorteren op gelijkenis. U kunt deze waarde verhogen voor sessies of query's die vectorzoekopdrachten uitvoeren met grote resultatensets met behulp van SET work_mem = '256MB';. Wees voorzichtig met globale toenames van work_mem omdat de instelling per bewerking per verbinding wordt toegepast. Een server die 100 gelijktijdige verbindingen met complexe queries verwerkt, kan daardoor 100 × work_mem × bewerkingen-per-query in het geheugen verbruiken. Voor vectorworkloads kunt u overwegen om op sessieniveau in te stellen work_mem voor specifieke query's in plaats van wereldwijd.

De effective_cache_size parameter vertelt de queryplanner hoeveel geheugen beschikbaar is voor caching, inclusief zowel postgreSQL's shared_buffers als de bestandscache van het besturingssysteem. Deze instelling wijst geen geheugen toe, maar beïnvloedt of de planner indexscans kiest boven sequentiële scans. Ingesteld effective_cache_size op ongeveer 75% van het totale systeemgeheugen op toegewezen databaseservers. Hogere waarden stimuleren de planner om indexen te gebruiken, wat doorgaans nuttig is voor vectorzoekopdrachten. In Azure Database for PostgreSQL wordt dit automatisch geconfigureerd op basis van uw laag.

De queryplanner van PostgreSQL neemt beslissingen over het uitvoeren van query's op basis van kostenramingen. Verschillende parameters zijn van invloed op deze schattingen en het afstemmen ervan voor moderne SSD-opslag verbetert de planning van vectorquery's.

De random_page_cost parameter maakt een schatting van de kosten voor het lezen van een willekeurige schijfpagina ten opzichte van een sequentiële pagina. De standaardwaarde van 4.0 weerspiegelt draaiende schijfkenmerken waarbij willekeurige toegang aanzienlijk langzamer is dan sequentiële toegang. Azure Database for PostgreSQL maakt gebruik van SSD-opslag waarbij willekeurige en sequentiële toegang vergelijkbare prestaties heeft. random_page_cost Verlagen tot 1.1-1.5 moedigt de planner aan om indexscans gemakkelijker te gebruiken, wat voordelen biedt voor vectorzoekopdrachten die toegang hebben tot verspreide gegevenspagina's. U kunt deze instelling aanpassen met SET random_page_cost = 1.1;.

De effective_io_concurrency parameter vertelt PostgreSQL hoeveel gelijktijdige schijf-I/O-bewerkingen het opslagsysteem kan verwerken. Met hogere waarden kunnen bitmap-heap-scans meer pagina's parallel vooraf laden. SSD-opslag verwerkt gelijktijdige I/O goed, dus stel effective_io_concurrency in op 200 voor SSD-gebaseerde Azure Database voor PostgreSQL-exemplaren. Dit verbetert de prestaties voor query's die vector-overeenkomsten combineren met het filteren van metagegevens.

Het parallel_tuple_cost en parallel_setup_cost parameters bepalen wanneer PostgreSQL parallelle uitvoering van query's gebruikt. Vectorbewerkingen kunnen profiteren van parallelle uitvoering, met name voor sequentiële scans op grote tabellen. Lagere waarden voor parallel_tuple_cost (standaard 0.1) en parallel_setup_cost (standaard 1000) stimuleren parallelle uitvoering. Voor vectorworkloads met grote tabellen kan parallellisme de querytijd aanzienlijk verminderen wanneer indexen niet worden gebruikt. U kunt uw huidige parallelle instellingen controleren met behulp van SHOW parallel_tuple_cost;, SHOW parallel_setup_cost;en SHOW max_parallel_workers_per_gather;.

Pgvector-specifieke parameters configureren

De pgvector-extensie biedt configuratieparameters waarmee de nauwkeurigheidssnelheid wordt bepaald voor zoekopdrachten op basis van indexen. Deze parameters zijn essentieel voor het afstemmen van de prestaties van vectorquery's.

Wanneer u IVFFlat-indexen gebruikt, bepaalt de ivfflat.probes parameter hoeveel indexpartities (lijsten) voor elke query worden doorzocht. Hogere waarden verhogen de recall (het vinden van meer van de juiste dichtstbijzijnde buren) maar vertragen de queries. Deze afweging staat centraal bij het afstemmen van de prestaties van IVFFlat. U balanceert het risico dat er goede overeenkomsten ontbreken ten opzichte van de kosten voor het zoeken naar meer partities. De standaardwaarde van 1 doorzoekt slechts de meest veelbelovende partitie, die snel is, maar mogelijk geen relevante resultaten mist die zijn opgeslagen in aangrenzende partities. Voor aanbevelingsengines waarbij het ontbreken van een goede overeenkomst de gebruikerservaring verslechtert, begint u met ivfflat.probes ingesteld op 5-10% van uw lists-parameter en past u deze aan op basis van gemeten recall.

-- Configure IVFFlat search depth
SET ivfflat.probes = 10;

-- Execute vector search
SELECT id, name, embedding <=> $1 AS distance
FROM products
ORDER BY embedding <=> $1
LIMIT 10;

Voor HNSW-indexen bepaalt de hnsw.ef_search parameter de grootte van de dynamische kandidaatlijst tijdens de zoekopdracht. Grotere waarden verkennen meer van de graaf, wat de recall verbetert ten koste van snelheid. In tegenstelling tot de discrete partities van IVFFlat, betekent de grafiekstructuur van HNSW dat deze parameter van invloed is op hoe grondig het algoritme burenverbindingen verkent voordat resultaten worden geretourneerd. De standaardwaarde van 40 biedt een redelijk saldo voor veel workloads. Voor hoge nauwkeurigheidsvereisten (zoals het vinden van de werkelijke top-10-overeenkomsten), verhoog dit tot 100-200. Voor latentiekritische toepassingen waarbij geschatte resultaten acceptabel zijn, kunnen waarden van laag als 20 werken. Configureer hnsw.ef_search met SET hnsw.ef_search = 100; voordat u uw vectorzoekopdracht uitvoert. De optimale waarde is afhankelijk van uw nauwkeurigheidsvereisten en latentiebudget. Benchmark met representatieve query's om het optimale evenwicht voor uw toepassing te bepalen.

Prestaties bewaken en meten

Afstemming zonder meten is giswerk. Gebruik de ingebouwde hulpprogramma's van PostgreSQL en Azure Monitor om inzicht te hebben in het querygedrag en om configuratiewijzigingen te valideren.

De EXPLAIN ANALYZE opdracht laat zien hoe PostgreSQL een query uitvoert en werkelijke tijdsinstellingen biedt. Voor vectorquery's geeft dit aan of indexen worden gebruikt en waar de tijd wordt besteed. Als u het uitvoeringsplan begrijpt, kunt u vaststellen of er slechte prestaties optreden als gevolg van ontbrekende indexen, suboptimale parameterinstellingen of problemen met gegevensdistributie. Voer EXPLAIN ANALYZE uit vóór de vectorquery om het uitvoeringsplan te bekijken. Zoek naar indexscan met behulp van [index_name] (geeft aan dat de vectorindex wordt gebruikt), Seq Scan (geeft een sequentiële scan aan, wat traag is voor grote tabellen), werkelijke tijdwaarden (weergeven waar de uitvoeringstijd wordt besteed) en aantal rijen (help te bepalen of filteren efficiënt werkt). Als u opeenvolgende scans ziet wanneer u indexgebruik verwacht, controleert u of de operator voor afstand van de query overeenkomt met de operatorklasse van de index (bijvoorbeeld met <=> een index die is gemaakt met behulp van vector_cosine_ops).

Soms kiest PostgreSQL ervoor om geen beschikbare index te gebruiken. Veelvoorkomende redenen voor vectorquery's zijn query's die een groot deel van de tabel retourneren (indexoverhead overschrijdt sequentiële scan), verouderde statistieken na belangrijke gegevenswijzigingen of een operator voor afstand die niet overeenkomt met de operatorklasse van de index. Uitvoeren ANALYZE products; om statistieken bij te werken voor nauwkeurige planning. U kunt indexinformatie controleren met SELECT indexname, indexdef FROM pg_indexes WHERE tablename = 'products';.

Azure Database for PostgreSQL maakt metrische gegevens beschikbaar via Azure Monitor waarmee knelpunten in de prestaties kunnen worden geïdentificeerd. Bewaak het CPU-percentage (hoge aanhoudende CPU geeft rekenvectorbewerkingen aan), geheugenpercentage (benaderende limieten suggereren dat de rekenlaag toeneemt of query's optimaliseert), opslag-IO-percentage (hoge waarden geven aan dat gegevens niet in de cache passen) en Actieve verbindingen (het benaderen van limieten geeft aan dat pooling van verbindingen kan helpen). Stel waarschuwingen in voor deze metrische gegevens om prestatievermindering te ondervangen voordat dit van invloed is op gebruikers.

Aanbevolen procedures voor het afstemmen van pgvector

Effectieve afstemming volgt een systematische benadering in plaats van willekeurige parameterwijzigingen.

  • Stel eerst basislijnen in: Meet de querylatentie en het resourcegebruik voordat u wijzigingen aanbrengt. Zonder basislijnen kunt u niet bepalen of wijzigingen helpen of pijn doen.
  • Eén parameter tegelijk wijzigen: Meerdere gelijktijdige wijzigingen maken het onmogelijk om verbeteringen of regressies toe te passen op specifieke instellingen.
  • Testen met productieachtige gegevens: Queryprestaties variëren aanzienlijk met de gegevensgrootte en distributie. Het afstemmen op kleine testgegevenssets produceert vaak instellingen die op schaal mislukken.
  • Controleren op regressies: Parameters die vectorzoekopdrachten verbeteren, kunnen een negatieve invloed hebben op andere werkbelastingen. Controleer de algehele systeemstatus na wijzigingen.
  • Documenteer uw instellingen: Noteer wat u hebt gewijzigd, waarom en welk effect het had. Deze documentatie is van groot belang bij het oplossen van toekomstige problemen.

Aanvullende bronnen