Datubāzu dizains un optimizācija

Vairumā lēno datubāzu trūkst acīmredzamā indeksa

Kad lietotne palēninās, augot, cēlonis parasti nav serveris vai datubāzes dzinējs. Tā ir daži vaicājumi, kas skenē veselas tabulas, jo neviens indekss neatbilst tam, kā tie meklē. Vaicājums, kas ilga 20 milisekundes ar 1 000 rindām, var ilgt sekundes ar miljonu, un neviens to nepamanītu, līdz to nepamanīs klienti.

Mēs sākam no pierādījumiem: datubāzes pašas statistikas par to, kuri vaicājumi darbojas visbiežāk un ilgst visilgāk. Tas parasti norāda uz īsu labojumu sarakstu, piemēram, indeksu kolonnās, ko izmanto izplatīts filtrs, vaicājumu pārrakstīšanu, lai izvairītos no visu tabulu ielādes, vai trūkstošo saiti starp tabulām, kas piespiež atkārtotas meklēšanas. Mēs izmeram katru vaicājumu pirms un pēc, tāpēc uzlabojums ir redzams, nevis tikai apgalvots.

Apgrozījumi aptur sliktos datus pie durvīm

Daudzas datu bāzes paļaujas uz lietotni, lai uzturētu datus tīrus. Lietotne pārbauda, ka e-pasta adrese ir unikāla, pasūtījums pieder reālam klientam un daudzums nav negatīvs. Tad otra lietotne, importēšanas skripts vai steidzams manuāls labojums izlaiž šīs pārbaudes, un parādās dublikāti un vientuļie ieraksti. Atskaites sāk nesakrist, un neviens nav pārliecināts, kurš skaitlis ir pareizais.

Pareizi izstrādāta shēma pati piespiedu kārtā piemeno svarīgus noteikumus: unikālas constraints, ārējās atslēgas, check constraints un saprātīgas noklusējuma vērtības. Jebkuram, kas raksta datu bāzē, jāievēro tieši šie noteikumi. Esošai sistēmai mēs atrodam vietas, kur dati jau ir kļuvuši nepareizi, plānojam to sakopšanu un pēc tam pievienojam constraints, lai tas neatkārtotos.

• Unikāli ierobežojumi lietai, kas nedrīkst atkārtoties, piemēram, e-pastiem vai rēķinu numuriem
• Ārējās atslēgas, lai ieraksti nevarētu norādīt uz kaut ko, kas neeksistē
• Check constraints vērtībām, kas jāpaliek noteiktā diapazonā
• Indeksi, kas izvēlēti, balstoties uz reālajiem vaicājumu modeļiem, nevis pievienoti visur