Kort genomgång av databaser

ClearSense I dagsläget finns endast ett reellt databasalternativ för hemsidor som ska hostas på vanliga webbhotell, MySQL.

För de flesta mindre hemsidor eller webbapplikationer fungerar det tillfredställande med MySQL, det är en stabil, snabb databas. Dock, för de behov som denna typ av hemsidor/applikationer har är MySQL egentligen lite väl resurskrävande. Om det inte vore för att det är en de facto-standard, i den mening att närmast alla Open Source CMS/Frameworks antingen kräver, eller kraftigt rekommenderar MySQL (vilket i sin tur ger att närmast all community support fokuserar på eventuella problem mellan CMS/Framework:et och MySQL), så skulle det räcka med att använda SQLite för den databashantering som behövs.

SQLite är inte en SQL-server, så som t.ex. MySQL, utan istället ett filformat, med associerad mjukvara, till för att möjliggöra SQL operationer.

SQLite är betydligt mindre resurskrävande än MySQL, men inte optimalt för stora mängder data, vid hög trafik och stora förändringar av datan I databasen hamnar SQLite också i en del problem i förhållande till SQL-server varianter. Men på en mindre hemsida kan man ofta tänka sig att när väl sidan är skapad så sker endast mindre och sporadiska ändringar i databasen. En fördel är också att ifall man vill flytta datan från en maskin till en annan, så är det bara att kopiera databasfilen.

För större hemsidor/webbapplikationer är det fortfarande möjligt att använda MySQL, men i de flesta fall kommer man vilja se till att MySQL servern är konfigurerad för att köra InnoDB istället för MySQLs standard MyISAM för datahanteringen.

Om man själv installerar databasmjukvaran, så följer InnoDB med som standard, men det är inte alla webbhotell som har stöd för det.

InnoDB och MyISAM är olika backends till MySQL servern med olika struktur för hur de lagrar data, hanterar planering vid SQL-förfrågningar etc.

Den stora bristen med MyISAM är att den ej stödjer Foreign Keys. Denna funktionnalitet krävs för att garantera dataintegritet, givet att det används korrekt.

En grundfunktion för SQL är Primary Keys, alltså en kolumn i en tabell som garanterar ett unikt värde för varje rad och alltså kan användas som identifikation för en specifik rad. Ofta är en PK bara ett löpnummer, alltså är PK för första raden i en tabell 1.

Men man kan också ha t.ex. användarnamn för inloggningssystem som primärnyckel för en tabell med användarinformation. Foreign Key är en referens i tabell A till tabell B:s PK, i de fall det finns en logisk koppling mellan två tabeller, t. ex. en tabell med användarnamn, lösenord och inloggningstid (tabell B) å ena sidan och en tabell med användarnas förnamn och efternamn (tabell A) å andra sidan.

Om tabell A har en extra kolumn för användarnamn med FK till tabell B
så garanteras det att så vida denna kolumn inte är NULL (utan data), så finns det en motsvarande rad i tabell A. InnoDB är den mest använda backend:en för MySQL när denna typ av funktionallitet behövs, eftersom MyISAM helt saknar detta.

Förutom MySQL finns det i praktiken endast två alternativ som ibland finns tillgängliga. Postgresql (Open Source) och MSSQL (Microsoft SQL server). Båda dessa brukar anses vara kraftfullare än MySQL och till skillnad från MySQL implementerar båda dessa funktionallitet som FK som standard. Ofta brukar det hävdas att MySQL dock är snabbare än de två alternativen, denna typ av argument är dock svåra att ta ställning till, eftersom det är väldigt beroende av vilken hårdvaru-mjukvarukombination som används och vilken typ av data som ska hanteras samt vilken typ av krav som ställs på t. ex. dataintegritet. Generellt kan man säga att både Postgresql och MSSQL är strukturerade för storskaliga applikationer där behovet för dataintegritet är stort och de kan tyckas långsamma i de fall användaren inte tar hänsyn till detta.

Både Postgresql och MSSQL klara sig bra vid väldigt hög datamängd, men vid väldigt stora databaser kan det behövas ett steg upp, till Oracle DB. T. ex. system för företag med 500+ anställda, där mycket information om lön, avdrag, personuppgifter etc ska hanteras, kan Oracle DB nästan vara det enda alternativet, även om Postgresql och MSSQL fortfarande är gångbara.

Samtliga databaser ovan är SQL-databaser. SQL är ett förfrågningsspråk (Q, query, L, language) för strukturerad (S, structured) data. Alltså, när data förs in, så formateras den efter regler som ställts upp när tabellen definierades. Det är strukturen som i mångt och mycket gör att datan lätt går att nå och det är också genom strukturen som det går att optimera planeringen för hur datan ska hämtas.

Sökmotorer och databaser

När databaser blir för stora blir strukturen problematisk. För t. ex. sökmotorer eller liknande blir det i längden ohållbart att använda standard SQL system, alternativen brukar samlas under beteckningen NoSQL. Detta är lite av en problematisk term eftersom vissa databassystem som kategoriseras här faktiskt använder delar av SQL, men också för att det ger sken av att teknikerna har något gemensamt (vilket de inte alls behöver ha).

Grovt sett finns det två vanliga NoSQL tekniker, som båda funnits sedan 1970-talet, men som fått lite av en revival på senare år; Dokumentbaserad och Key-Valuebaserad. den senare kan beskrivas som en databas med en enda jättetabell och ett index, det enda kravet på struktur är på nyckeln, som används för indexet. Vad som ligger som värde måste applikationen som använder sig av databasen sköta. Denna typ av system ligger ofta i grunden för SQL-databaser, och sköter sista steget datan lagras fysiskt på mediet. Ett exempel på denna typ av databas är BerkeleyDB, ett annat Cassandra som t.ex. används av Facebook.

Denna typ av databas är lite av en digital tagning på de beryktade elevpärmarna med information om elever förehavanden under studietiden samt betyg etc. Anledningen till att använda denna typ av system är enkelt, den data man hanterar går inte, eller är väldigt resurskrävande för att strukturera. Om vi tar exemplet med elevpärmen kan vi tydligare se problemet, varje elev har papper i pärmen som är förutsägbart, vi förväntar oss bland annat betyg. Men strukturen på betygen är helt avhängigt vilken klass och vilka kurser eleven har läst. Dessutom kanske vissa elever har anmärkningar från rektorn, noteringar från sjuksyster etc. Frågan om betygen kan hanteras i SQL med lite ansträngning, men för att t. ex. få in anmärkningar från rektorn måste vi antingen anta att varje elev kan ha en anmärkning från rektorn (i SQL skulle detta innebära en kolumn i elevtabellen), vilket innebär att vi slösar utrymme för varje elev som inte har någon anmärkning, eftersom de flesta inte har någon anmärkning, så blir detta slöseri ganska påtagligt. Alternativet är att sätta upp en ny tabell, anmärkningstabellen, som refererar till elevtabellen. Här används endast det utrymme som behövs, men det gör att varje gång vi vill ta reda på information om de elever som har anmärkningar, så måste vi ladda båda tabellerna, vilket ger visst slöseri av processorkraft. I fallet med en skola är detta negligerbart, och de skulle nog göra bäst i att använda en SQL databas, men när man skalar upp det till 500 miljoner användare och närmast oändligt med variationer på vilken typ av data som finns och inte finns för varje given användare så blir det mer påträngande.

  • Linus

    tack för lektionen!