Understrukna ord finns i lektionsordlistan. Tryck på ett ord för att se alla översättningar. Lägg till eller redigera ord i messages/glossary.json (alla språknycklar du lägger till visas i rutan).
Collaboration, product, and users
Data, databases, and performance
Databasen låser sig för att det finns en transaktion som inte stängts ordentligt.
Vi måste absolut lägga till ett index på den tabellen, annars kommer sökningarna bli outhärdligt långsamma.
SQL-frågan är alldeles för ineffektiv, den skannar hela tabellen varje gång (full table scan).
Vi måste planera in den stora databasmigreringen till ett fönster mitt i natten när trafiken är låg.
Datamodellen vi använder just nu är inte optimerad för den här typen av relationssökningar.
Jag tror att vi behöver normalisera den här tabellen för att undvika att vi sparar dubbletter av data.
Lasten på databasservern ligger på över nittio procent, vi måste skala upp den vertikalt omedelbart.
Jag håller på att skriva ett skript som anonymiserar all data vi drar ner till testmiljön.
Vi måste optimera vår 'N+1'-fråga, det är den som sänker prestandan i hela gränssnittet.
Genom att implementera Redis som en cache framför databasen minskade vi svarstiden enormt.
Det verkar som att vårt anslutningskluster (connection pool) har slut på lediga anslutningar.
Vi måste strukturera om tabellerna så att vi slipper använda så många komplexa JOIN-satser.
Kolla loggarna för långsamma sökningar (slow query log), det är där flaskhalsen gömmer sig.
Jag håller på att partitionera (dela upp) den gigantiska loggtabellen efter månad för att öka hastigheten.
Databasen har en deadlock-situation, vilket gör att två processer väntar på varandra i all oändlighet.
Är det någon som har en backup på databasen från igår kväll innan den där koden rullades ut?
Vi behöver köra en vakuum-process (vacuum) för att städa upp döda rader i PostgreSQL.
Datan vi tar emot är ofta felformaterad, vi behöver en striktare validering innan vi sparar ner den.
Jag överväger om vi kanske borde flytta just den här datan till en NoSQL-databas som MongoDB istället.
Vi exporterar all säljdata till ett enormt datalager (data warehouse) för vidare analys i PowerBI.
Sidineringslogiken (pagination) vi använder är väldigt ineffektiv när vi kommer till sida tusen eller mer.
Databasen replikeras asynkront till vår sekundära server, så det finns en liten fördröjning i test.
Vi måste ställa in begränsningar för hur mycket minne själva databasmotorn tillåts använda.
Transaktionsloggarna har tagit upp allt utrymme på hårddisken, vilket fick servern att krascha.
Svaret på API-anropet var tyvärr hundra megabyte stort, vi måste begränsa mängden data som returneras.
Jag kör ett förklarings-kommando (EXPLAIN) på frågan för att se exakt hur databasen väljer att hämta datan.
Prestandan dippar tyvärr avsevärt varje gång det schemalagda backup-jobbet drar igång.
Vi börjar närma oss gränsen för den maximala storleken på heltal (integer overflow) i ID-kolumnen.
Genom att använda batch-uppdateringar sparar vi enormt mycket tid jämfört med att spara en rad i taget.
Ska vi spara datan mjuk-raderad (soft delete) istället för att ta bort raden permanent från databasen?
Vi saknar en utländsk nyckel (foreign key constraint), vilket skapar problem med dataintegriteten (orphaned data).
Låt oss komprimera de äldsta tabellerna, de används väldigt sällan men tar upp onödigt mycket dyr diskplats.
Det tog mig nästan två timmar att bygga om hela databasschemat med den nya ORM-konfigurationen.
Våra vyer (materialized views) i databasen måste uppdateras oftare så att siffrorna på startsidan är färska.
Det är livsviktigt att vi stänger anslutningen (close connection) i koden så fort vi har läst klart datan.
Databasen är tyvärr källan till nästan alla våra prestandaproblem i det här gamla arvs-projektet (legacy).
Kan vi optimera laddningen av startsidan genom att bara hämta de absolut nödvändiga fälten (SELECT *)?
Vi använder en separat läs-replika (read replica) för alla våra tunga och komplexa rapporteringsjobb.
Jag skriver ett litet verktyg för att kontinuerligt tvätta och tvätta datan (data cleansing) från felaktigheter.
Schema-migreringen gick igenom utan ett enda fel, så tabellerna är nu helt redo för den nya koden.
Vi har hundratusentals rader som aldrig används längre, jag skapar ett skript som raderar all arkiverad data.
Optimering är en ständig balansgång mellan snabbhet i läsning och snabbhet vid insättning av ny data.
Genom att flytta upp den tunga logiken direkt i en lagrad procedur (stored procedure) snabbade vi upp processen rejält.
När vi uppdaterar datamodellen är det otroligt viktigt att vi inte råkar radera kolumner som fortfarande används.
Vi kan inte hantera mer trafik förrän vi har separerat vår databas i flera mindre delar (sharding).
Det fanns tyvärr mycket 'smutsig' data (dirty data) i systemet från de tidigaste åren av företagets existens.
Hur länge ska vi egentligen lagra historiken innan det är okej att radera den från databasen?
Prestandatestet visade att vi kan klara av upp till tio tusen samtidiga databasanrop i sekunden nu.
Ett väl genomtänkt och designat databasschema är den absolut bästa grunden för en högpresterande applikation.
Bra jobbat med prestandaoptimeringen, systemet känns nu blixtsnabbt för våra slutanvändare!
