Tietokantasuunnittelu ja optimointi

Useimmat hitaat tietokannat puuttuvat ilmeisen indeksin

Kun sovellus hidastuu kasvessaan, syy on yleensä ei palvelimessa tai tietokantamoottorissa. Se on kourallinen kyselyitä, jotka skannaavat koko taulukoita, koska mikään indeksi ei vastaa tapaa, jolla ne hakevat. Kysely, joka kesti 20 millisekuntia 1 000 rivillä, voi kestää sekunteja miljoonalla rivillä, eikä kukaan huomaa sitä, kunnes asiakkaat tekevät.

Aloitamme todisteista: tietokannan omista tilastoista siitä, mitkä kyselyt ajetaan useimmiten ja kestävät pisimpään. Se osoittaa yleensä lyhyen luettelon korjauksista, kuten indeksin sarakkeille, joita yleinen suodatin käyttää, kyselyn uudelleenkirjoittamisesta välttääkseen koko taulukoiden lataamisen, tai puuttuvan linkin taulukoiden välillä, joka pakottaa toistetut haun. Mittaamme jokaisen kyselyn ennen ja jälkeen, joten parannus on näkyvä eikä väitetty.

Rajoitteet estävät huonon datan ovella

Monet tietokannat luottavat sovelluksen varaan datan siisteydestä. Sovellus tarkistaa, että sähköpostiosoite on uniikki, tilaus kuuluu aidolle asiakkaalle ja määrä ei ole negatiivinen. Toinen sovellus, tuontikäsittely tai kiireinen manuaalinen korjaus ohittaa nämä tarkastukset, jolloin duplikaatit ja irralliset tietueet pääsevät sisään. Raportit alkavat erota toisistaan, eikä kukaan tiedä, mikä luku on oikea.

Hyvin suunniteltu tietomalli toteuttaa tärkeät säännöt itse: uniikkirajoitteet, ulkoiset avaimet, tarkistusrajotteet ja järkevät oletusarvot. Kaiken, joka kirjoittaa tietokantaan, on noudatettava niitä. Olemassa olevassa järjestelmässä etsimme kohdat, joissa data on jo viallista, suunnittelemme puhdistuksen ja lisäämme rajoitteet, jotta virheet eivät toistu.

• Uniikkirajoitteet asioille, jotka eivät saa toistua, kuten sähköposteille tai laskunumeroille
• Ulkoinen avain, jotta tietueet eivät viittaa olemattomiin kohteisiin
• Tarkistusrajotteet arvoille, jotka pysyvät tietyssä välissä
• Indeksit valittuja todellisista kyselykuvioista, ei lisätty kaikkialle