I en relationel MySQL-struktur med køretøjer, ejere, værksteder, sager og skader hængt på.
Når datamængden i sig selv er opgaven
Et par millioner rækker er ikke noget problem. Det bliver det, når de skal spørges på tværs af seks relationer, opdateres hver nat og svare på under et sekund. Det er der, jeg bliver hentet ind.
FIG. 01
Målestok
Hvad jeg har haft under hænderne
Tallene er fra systemer, jeg selv har bygget og haft driftsansvaret for. Det er ikke tal fra en testdatabase.
Heraf 1,2 millioner synonymer. 1,5 millioner billeder er knyttet til det samme taksonomiske hierarki.
På én salgstype. Tilbud, ordrer, fakturaer og kreditnotaer har hver deres af samme størrelse.
FIG. 02
Relationer
Antallet af rækker er sjældent det svære
En tabel med tyve millioner rækker er ikke i sig selv et problem. Det bliver det, når en helt almindelig forespørgsel skal igennem seks relationer for at give et svar, og når hver af de seks tabeller også er vokset.
Det er den slags, jeg har arbejdet med i årevis. Taksonomiske hierarkier med synonymer på hvert niveau. Køretøjer med stelnumre, nummerplader, ejere, sager og skader. Salgsdata hvor en enkelt linje hænger på kunde, afdeling, vare og økonomi på én gang.
ZiiX
- Nummerplade
- Køretøj
- Bruger
- Sag
- Skade
PlantGeekz
- Billede
- Art
- Slægt
- Familie
- Orden
Skorstensgaard
- Varelinje
- Ordre
- Faktura
- Kunde
- Afdeling
Tre kæder fra systemer, jeg har bygget. Hvert led er en relation, forespørgslen skal igennem, før den kan svare.
FIG. 03
Konsekvenser
Hvad det koster ikke at have styr på det
Det her sker ikke på dag ét. Det sker, når datamængden er vokset stille og roligt i tre år, og ingen har kigget på modellen siden den blev lavet.
To tal på det samme
Salg og økonomi regner forskelligt, fordi der er to steder at hente tallet. Møderne går med at blive enige om, hvem der har ret, i stedet for at træffe beslutningen.
Dubletter der koster penge
Den samme kunde tre gange, det samme køretøj to gange. Rabatter bliver givet forkert, og rykkere bliver sendt til nogen, der har betalt.
Så langsomt at folk holder op
En forespørgsel, der tog 200 millisekunder ved hundrede tusind rækker, tager fyrre sekunder ved ti millioner. Så laver folk deres eget regneark ved siden af, og så er I tilbage, hvor I startede.
Natjobbet bliver ikke færdigt
Importen skal være kørt klokken syv. Ved den datamængde tager den ni timer, og så møder man ind til gårsdagens tal uden at vide det.
Ingen tør ændre noget
En skemaændring på tyve millioner rækker låser tabellen, mens den kører. Så bliver ændringen udskudt, og udskudt igen, og til sidst er systemet stivnet.
I kan ikke slette det, I skal
GDPR kræver, at I kan fjerne en person fra jeres systemer. Når ingen længere ved, hvad der hænger sammen med hvad, er der heller ingen, der tør trykke på knappen.
FIG. 04
Håndværket
Hvad jeg gør ved det
Datamodellering
Relationerne lagt rigtigt fra starten og normaliseret præcis så langt, det giver mening. Nogle gange er den rigtige beslutning at duplikere med vilje, og så skal det være et valg og ikke et uheld.
Indeksering og forespørgsler
At læse en query plan og se, hvorfor MySQL vælger det forkerte indeks. Det er tit forskellen på fyrre sekunder og fyrre millisekunder.
Migrationer uden nedetid
Skemaændringer på tabeller med millioner af rækker, uden at lukke butikken imens.
Søgning ved siden af databasen
Meilisearch og Sphinxsearch tager fritekstsøgningen, så databasen kan passe det, den er god til.
Jobs der kan genstartes
Batch og baggrundskørsler i bidder med checkpoints, så en fejl klokken tre om natten ikke koster hele importen.
Overvågning og gendannelse
Zabbix på det, der betyder noget, så I opdager det, før brugerne gør. Og en backup, nogen har prøvet at rulle tilbage og taget tid på.
Har I noget, der skal bygges ordentligt?
Skriv et par linjer om, hvad I sidder med. Så vender jeg tilbage med, hvad jeg tænker. Også hvis svaret er, at en anden løser det bedre.