1. Alusta kasutusmustritest
Praktiline harjutus
Pane kirja 10 kõige olulisemat päringut, mida rakendus teeb.
Igaühele:
- milliseid tabeleid ta puudutab,
- mis on WHERE / JOIN / ORDER BY väljad,
- mitu rida ta tagastab,
- kui tihti ta käib.
See list on sinu indekseerimise ja skeemi tegelik lähteülesanne.
2. Normaliseerimine vs denormaliseerimine: tee teadlik kompromiss
3. Indeksid: väikseim muutus, suurim võit
Kuidas leida õiged indeksid
- Võta „top 10“ kuumad päringud (vt ptk 1).
- CPU/IO poolest kallimad päringud = esimesed kandidaadid.
- Vaata query plan’e (EXPLAIN / ANALYZE).
- Indekseeri ainult seda, mida päring reaalselt kasutab.
Kui lisad indeksi „igaks juhuks“, maksad sa sellest iga kirjutuse peal.
4. Päringud: skaleeruvus sureb N+1 ja „SELECT *“ kätte
Praktiline reegel tiimile
„Üks API = üks põhipäring + (vajadusel) üks lisapäring.“
Kui ühe API jaoks läheb üle 3-4 päringu, on suur tõenäosus, et kuskil on N+1 või vale mudel.
5. Transaktsioonid ja lukud: nähtamatu jõudluse killer
6. Skaleerimine samm-sammult (odavast kallini)
Cache’i rusikareegel
Cache’i lisa siis, kui:
- sama päring käib väga tihti,
- andmed ei muutu iga sekund,
- valed cache-hitid ei riku äri.
Cache ei ole plaastriks halbadele päringutele - see on võimendi headele.
7. Partitioning ja arhiivimine: ära hoia kõike ühes kuhjas
Kui tabelis on sadu miljoneid ridu, hakkavad ka head indeksid oma piire nägema. Siin aitab partitsioneerimine (nt kuupäeva, kliendi või regiooni järgi).
Miks see töötab:
- päring loeb ainult vajalikku osa,
- indeksid on väiksemad ja kiiremälus paremini hoitavad,
- vanu osi saab arhiivida ilma teenust seisata.
Tee see varem, mitte siis, kui tabel on juba hiiglaslik. Hiljem on migratsioon valusam.
8. Mõõtmine ja monitooring: ilma numbriteta ei ole optimeerimist
Suures koormuses on „tunnetus“ vale mõõdik. Vajad nähtavust.
Miinimum, mida monitoorida:
- aeglasemad päringud (p95/p99)
- lock wait / deadlock’id
- ühenduste arv ja pooli tervis
- cache hit rate
- write latency eraldi read latency’st
- replikatsiooni viivitus
Kui sul pole seda pilti, oled sa koormuse kasvades alati samm maas.
9. Migratsioonid ja skeemi muutused ilma downtime’ita
10. Millal on aeg arhitektuuri muuta?
Kokkuvõte
Skaleeruv andmebaas ei ole peamiselt „suure riistvara“ küsimus. See on disaini tulemus: õiged kasutusmustrid, teadlik normaliseerimine, täpsed indeksid, korralikud päringud ja selge skaleerimisjärjekord.
Kui need asjad on varakult paigas, saab äri kasvada ilma, et andmebaas muutuks piduriks. Ja kui kasv lõpuks nõuab keerulisemaid samme (replikad, partitioning, sharding), on sul selleks tugev vundament olemas.
Vajad tuge andmebaasi arhitektuuri või jõudluse parandamisel?
Oleme aidanud SaaS-platvormidel, e-poodidel ja finantslahendustel skaleerida andmebaase nii, et kasv ei jookseks infrastruktuuri taha kinni. Kui tahad teada, kus sinu skeemi ja päringute kitsaskohad on, teeme auditi ja viime parandused ellu.