Vind de dure aanvraag voordat je de database wijzigt
Begin bij een gebruikersactie: categorie laden, artikel zoeken, toevoegen aan winkelwagen of bestelling plaatsen. Leg de route vast, het aantal queries, db-duur, teruggegeven rijen en verzoekduur. Een trage pagina kan ook wachten op applicatiecode of een andere afhankelijkheid; diagnoseer dus niet alleen op paginalaadtijd.
Een queryplan is de databasetocht door tabellen, indexen, joins, sorteringen en aggregaties. In PostgreSQL toont EXPLAIN dat pad. EXPLAIN ANALYZE voert de statement uit en rapporteert werkelijke rijen en timings, gebruik dus een veilig representatieve query. Een groot verschil tussen geschatte en werkelijke rijen is een reden om statistieken of condities te onderzoeken, niet automatisch een reden voor een indexaanvraag.
Koppel een kandidaat-query aan een route en resultaat, zodat enkel een dashboardrapport een trage checkout niet overstemt.
Leg timings en vergelijkbaar verkeer vast vóór wijziging zonder klantidentificatoren, tokens of kaartwaarden te loggen.
Ontwerp indexen voor het pad dat je echt gebruikt
Een index is een onderhouden structuur die kan helpen rijen te vinden of in volgorde terug te geven; het is geen universele snelheidsknop. Begin bij de filters, join-sleutels en sortering van een belangrijke query en bevestig het voorgestelde indexontwerp in een plan. PostgreSQL documenteert dat een passende B-tree-index ORDER BY kan voldoen zonder aparte sortering, vooral bij een kleine LIMIT.
Indexen voegen opslag en schrijfwerk toe omdat inserts, updates en deletes ze bijhouden. Voor een query die een groot deel van een tabel nodig heeft, kan een sequentiële scan met expliciete sortering sneller zijn. Test op productielijke data en behoud een index alleen als het voordeel de kosten rechtvaardigt.
Gebruik de feitelijke filters en ORDER BY van de query, inclusief een deterministische tie-breaker waar de interface stabiele volgorde nodig heeft.
Bekijk of een index gebruikt wordt en wat het kost bij writes; hercontroleer naarmate data en verkeer veranderen.
Maak paginering stabiel en betaalbaar
Paginering met paginanummer gebruikt meestal LIMIT plus OFFSET. Leg altijd een voorspelbare order op. PostgreSQL waarschuwt dat zonder ORDER BY LIMIT een onvoorspelbare subset kan teruggeven; verschillende LIMIT- of OFFSET-waarden kunnen inconsistente subsets opleveren omdat de optimizer verschillende plannen kan kiezen.
Grote offsets verdienen aandacht omdat overgeslagen rijen toch berekend moeten worden. Voor diepe catalogus-, bestelhistorie- of archiefnavigatie overweeg cursor- of keyset-paginering: vraag rijen na de laatst geziene stabiele sorteervalue en unieke tie-breaker op. Definieer hoe nieuwe of verwijderde records verschijnen vóórdat je de interface verandert.
Geef de kleinste nuttige pagina terug in plaats van een onbeperkt resultaat.
Bepaal of de interface bij elk verzoek werkelijk een exacte totaliteit nodig heeft.
Cacheer leeswerk zonder het verkeerde antwoord te serveren
Caching hergebruikt een eerder resultaat in plaats van het opnieuw uit de database op te bouwen. Begin op HTTP-niveau voor openbare, herhaalbare pagina’s en versieerbare assets, omdat een cache-hit applicatie- en databasewerk kan vermijden. web.dev raadt aan langlevende caching voor versieerde URL’s; het veranderen van de URL is de praktische invalidatiemechaniek.
Cachebeleid is een juistheidsbeslissing. Een gedeelde cache kan één antwoord voor meerdere gebruikers hergebruiken, dus deel geen account-, winkelwagen-, prijs- of autorisatiespecifieke output tenzij dit ontworpen en getest is voor die scope. Cache-Control private beperkt hergebruik tot de browsercache, terwijl no-store caches instrueert om het niet te bewaren.
Scheid publieke catalogus- of artikeloutput van sessiespecifieke, locatie-specifieke en permissiegevoelige output.
Definieer wie een verouderde waarde mag zien, hoe lang en wat de invalidatie- of revalidatieroute is.
Bescherm connectiecapaciteit in plaats van alleen het plafond te verhogen
Een connectie is een actieve clientsessie naar de database. Workers, cron-jobs, previews of retries kunnen slots uitputten, zelfs als individuele queries acceptabel lijken. PostgreSQL’s max_connections regelt gelijktijdige verbindingen, wordt bij serverstart ingesteld en een hogere waarde reserveert meer resources waaronder gedeeld geheugen. Het hoger zetten zonder workloadmodel kan het falen verplaatsen.
Stel één budget in voor webworkers, achtergrondtaken, administratie en replica’s. Gebruik begrensde pooling waar passend, behoud ruimte voor herstel en pas timeouts toe zodat vastgelopen werk niet onbeperkt wacht. Veilige getallen hangen af van engine, geheugen, querymix en providerbeperkingen; bevestig ze met de operator.
Inclusief webprocessen, queues, geplande taken, migraties, rapportagetools en deployment-jobs.
Beperk gelijktijdigheid en gebruik backoff zodat een fout de connectievraag niet vermenigvuldigt.
Observeer querykosten met context en privacycontroles
Rangschik databasewerk naar totale impact, niet naar één traag monster. Een matig trage query die duizenden keren wordt aangeroepen kan belangrijker zijn dan een zeldzaam rapport. PostgreSQL’s pg_stat_statements aggregeert planning- en uitvoeringsdata inclusief calls, totale en gemiddelde uitvoeringstijd, rijen en bufferactiviteit. Het vereist serverconfiguratie en een herstart om toe te voegen of te verwijderen; plannings-tracking kan overhead toevoegen.
Koppel querygroepen aan route, releaserversie en tijdvenster. OpenTelemetry adviseert querytekst standaard alleen te verzamelen na sanitatie die literalwaarden vervangt en een samenvatting met lage cardinaliteit voor groepering te gebruiken. Dit helpt eigenaren trends te zien zonder klantgegevens te exporteren of voor elke waarde een label te creëren.
Controleer duur, totaal tijd, calls, fouten, connecties en rijen; elk onthult een ander faalpatroon.
Gebruik geparametriseerde queries en verifieer dat literals zijn verwijderd voordat traces of logs de applicatie verlaten.
Rol databasewijzigingen uit als omkeerbaar betrouwbaarheidswerk
Behandel een index, herschrijving, cachebeleid, poolinstelling of schemawijziging als een productieverandering met een eigenaar, succesmaat en rollback-beslissing. Valideer in een representatieve omgeving, rol uit naar een beperkte slice en monitor het getroffen traject. Sneller is geen succes als de wijziging onjuiste, ontbrekende, dubbele of verouderde data teruggeeft.
Schemawijzigingen vragen zorg omdat applicatieversies kunnen overlappen. Google Cloud-richtlijnen beschrijven een compatibiliteitsvolgorde: zet eerst een applicatie uit die oud en nieuw schema aankan, wijzig het schema, en zet vervolgens de feature die het gebruikt uit. Dit behoudt een applicatieterugkeerroute. Locking en online-wijzingsgedrag verschillen per engine en managed service; vraag gekwalificeerde review voor hoogvolume- of betalingsgerelateerde systemen.
Naam het traject, prestatie- en correctheidsignalen en de drempel die de rollout stopt.
Verifieer performance en correctheid in een gecontroleerde slice vóór uitbreiding; oefen de terugkeerroute buiten een incident.