Beslut, val av databashanterare för nya Ladok

Dokument:
Version
Beslut, val av databashanterare
för nya Ladok
Författare
Ulrika Ringeborn
1.0
Sida 1 av 1
Datum 2014-05-16
Ringeborn / Åström
Beslut, val av databashanterare för nya Ladok
Ladok3-projektet har från den tidiga utvecklingsfasen, med grund i genomförda
utredningar inom projektet, använt IBMs DB2 som databashanterare. I samband
med första leveransen från Ladok3-projektet till Ladokförvaltningen har Ladok3projektet begärt förvaltningsorganisationens slutgiltiga beslut avseende val av
databashanterare.
Förvaltningsorganisationens beslut grundar sig på underlag från dels Ladok3projektet och dels särskild utredning av Ladokkonsortiets tekniska förvaltare hos
Universitets och högskolerådet (UHR), underlagen lämnas som bilagor till detta
beslut.
Objektägarna beslutar tillsammans efter föredragning av ärendet,
att: IBMs DB2 ska användas som databashanterare för nya Ladok.
För fortsatt möjlighet att omvärdera detta beslut i framtiden uppmanas Ladok3projektet och kommande förvaltningsorganisation att endast där så är absolut
nödvändigt, för att säkerställa nödvändig prestanda, använda produktspecifika
lösningar som inte enkelt kan migreras till annan databashanterare.
Urika Ringeborn
Objektägare-IT
Karin Åström
Objektägare
Bilagor:
1 Rekommendation och beslutsunderlag till databashanterare
2 PM Möjliga DBMS för Ladok3
3 PM Val av driftmiljö
Rekommendation Databashanterare
Ladoks förvaltning
Anna-Karin Bergman
Version 1.0
2014-05-16
Sida: 1 (8)
Beslutsunderlag för val av databashanterare i det
nya Ladoksystemet
Rekommendation Databashanterare
Ladoks förvaltning
Anna-Karin Bergman
Version 1.0
2014-05-16
Sida: 2 (8)
Innehåll
1
Inledning ............................................................................................................................. 3
2
Syfte .................................................................................................................................... 3
3
Urvalskriterier för databasval ............................................................................................ 3
4
Bedömning av databashanterare utifrån givna frågeställningar ..................................... 3
4.1 Bedömd kvalitet i förhållande till nya Ladoks behov................................................ 4
4.2 Bedömning av produkternas långsiktiga överlevnad ............................................... 6
4.3 Bedömning av produktens mognad ......................................................................... 6
4.4 Bedömning av inlåsningseffekter med risk för okontrollerade prisjusteringar
(support- och licensavtal) ................................................................................................... 6
4.5 Kostnadsjämförelser mellan lösningarna för ett normalår efter sista
produktionssättningen av nya Ladok. ................................................................................. 7
4.6 Konsekvenser hos vald driftleverantör (ekonomiska, kvalitativa eller andra) ......... 7
5
Slutsatser och rekommendation ....................................................................................... 8
Rekommendation Databashanterare
Ladoks förvaltning
Anna-Karin Bergman
Version 1.0
2014-05-16
Sida: 3 (8)
Rekommendation och beslutsunderlag för val
av databashanterare
1
Inledning
För att kunna optimera prestandan i det nya Ladoksystemet är det nödvändigt att
använda databasspecifika konfigurationer. Hittills har utvecklingsprojektet Ladok3
använt generiska databasfunktioner för att undvika inlåsningseffekter mot en specifik
databas och därmed att bli leverantörsberoende.
Så snart databasspecifika konfigurationer användas minskar möjligheterna att byta till
andra databashanterare.
2
Syfte
Dokumentet är ett beslutsunderlag inför val av databashanterare i det nya
Ladoksystemet.
3
Urvalskriterier för databasval
Uppdragsdirektivet till beslutsunderlaget nämner sex aspekter som ska beaktas vid val
av databashanterare.






Bedömd kvalitet i förhållande till nya Ladoks behov
Bedömning av produkten långsiktiga överlevnad
Bedömning av produktens mognad
Bedömning av inlåsningseffekter med risk för okontrollerade prisjusteringar
Kostnadsjämförelser mellan lösningarna för ett normalår efter sista
produktionssättningen av nya Ladok.
Konsekvenser hos vald driftleverantör (ekonomiska, kvalitativa eller andra)
Valet bör också baseras utifrån ett helhetsperspektiv på kort och lång sikt, med den ITstrategiska planen som grund.
De tre databashanterarna som skall utvärderas är: IBMs DB2, MySql och Maria DB
4
Bedömning av databashanterare utifrån givna
frågeställningar
Rekommendation Databashanterare
Ladoks förvaltning
2014-05-16
Anna-Karin Bergman
4.1
Version 1.0
Sida: 4 (8)
Bedömd kvalitet i förhållande till nya Ladoks behov
IBM DB2
DB2 bedöms svara mot alla krav som ställs på databasen under utvecklingsfasen,
förvaltning och drift. I dag använder Ladok3s utvecklingsorganisation DB2. De tester som
hittills är genomförda är gjorda mot DB2.
DB2 är en kraftfull och omfattande databas. Db2 kategoriseras som en så kallad
”Enterprise” databas, vilket innebär att databasen är dimensionerad för att användas i
större affärskritiska system. Db2 är en stabil databas, men all funktionalitet som finns att
tillgå i produkten kommer troligtvis inte vara relevant att implementera för det nya
Ladoksystemet.
MySql och MariaDb
MySql och MariaDb erbjuder mer begränsad funktionalitet än DB2, men anses svara mot
de funktionella krav som Ladok3 ställer på databashanterare. Det är dock inte verifierat
och testat. I dagsläget har leverantören ITS inte någon praktisk erfarenhet av MariaDb.
MariaDb skall vara en så kallad ”drop-in-replacement” till MySql 5.1. Teoretiskt så skall
MariaDb och MySql vara i princip identiska.
En stor fråga är om MySql och MariaDb kommer räcka till kapacitetsmässigt i
produktionssatt drift. Det är inte testat. Det är fullt möjligt att skala upp och ner
kapaciteten för MySql på virituella plattformar. Det som kan bli problematiskt vid haveri
och vid hård belastning är att MySql och MariaDB inte klarar av konsistent
klusterhantering. I ett databaskluster så fördelas lasten mot databaserna. I MySql så
görs detta genom att en av databaserna är huvuddatabas (master) och håller reda på
vilka transaktioner och i vilken ordning dessa körs på de olika databaserna i klustret.
MySql-”kluster”
Stöddatabas
(Slave)
Huvuddatabas
(Master)
Stöddatabas
(Slave)
Rekommendation Databashanterare
Version 1.0
Ladoks förvaltning
2014-05-16
Anna-Karin Bergman
Sida: 5 (8)
Skulle huvuddatabasen krascha så vet inte stöddatabaserna i klustret vad som är
genomfört av de andra databaserna. Dvs. lastbalansering på databasnivå fungerar inte
om huvuddatabasen kraschar.
I DB2 är klusterstödet bättre utbyggt. Det finns möjlighet att låta mer än en databas vara
huvuddatabas. Skulle en huvuddatabas slås ut finns det fortfarande databaser i klustret
som håller reda på vilka transaktioner som är genomförda och i vilken ordning.
Det är en stor fördel att kunna köra databaskluster, speciellt då vi den framtida lasten på
Ladoksystemet inte är känd.
DB2-”kluster”
Huvuddatabas
(Master)
Huvuddatabas
(Master)
Huvuddatabas
(Master)
Rekommendation Databashanterare
Ladoks förvaltning
Anna-Karin Bergman
4.2
Version 1.0
2014-05-16
Sida: 6 (8)
Bedömning av produkternas långsiktiga överlevnad
DB2
Inga indikationer finns på att IBMs DB2 skulle fasas ut eller införlivas i en annan produkt.
IBM brukar vanligtvis annonsera denna typ av förändring 3-4 år i förväg. DB2 bedöms
finnas kvar på marknaden lång tid framöver.
MySql
Oracles intention verkar vara att fortsätta låta MySql vara en öppen databas. Produkten
utvecklas fortfarande, även om vissa menar att utvecklingstakten avtagit. MySql är en
populär och vanligt förekommande databas i mellanstora system. Bedömningen är att
MySql kommer att leva vidare lång tid framöver. Skulle Oracle välja att helt
kommersialisera MySql finns ett antal öppna alternativ som är baserade på MySql.
MariaDb
MariaDb är till stor del utvecklad av samma personer som utvecklat MySql. MariaDb
uppges vara i princip identisk med MySqls version 5.1. Värt att tillägga är att det även
finns andra öppna avknoppningar av MySql såsom till exempel Percona. Det är svårt att
säga vilken av avknoppningarna av MySql som blir mest framgångsrik. Att det är ett
erkänt duktigt utvecklingsteam bakom MariaDb kan sannolikt bidra till att användingen
av MariaDb kommer att öka. Många är positivt inställda till MariaDb och databasen
verkar lovande, men många avvaktar med att köra databasen i skarp drift.
4.3
Bedömning av produktens mognad
DB2
DB2 är en väl beprövad och stabil produkt som funnit länge på marknaden. Databasen
har hög kapacitet. Produkten vidareutvecklas kontinuerligt.
MySql
Även MySql är välbeprövad och har visats sig fungera väl i mellanstora system.
MariaDB
Maria Db är en avknoppning (”drop-in-replacement”) av MySql version 5.1.
Teoretiskt sett så skall det mesta i MariaDb fungera på samma sätt som i tidigare
versioner av MySql. Då produkten är så pass ny är det svårt att hitta referenskunder i
Sverige som kan berätta om sina erfarenheter av databasen. ITS planerar att sätta upp
en testinstans av befintligt Ladok med MariaDb som databas för att utvärdera om
MariaDb kan ersätta MySql.
4.4
Bedömning av inlåsningseffekter med risk för okontrollerade
prisjusteringar (support- och licensavtal)
DB2
DB2 är en kommersiell databas som utvecklas av IBM. Då produktspecifik funktionalitet
börjar användas kommer leverantörsberoendet öka. Hur hård inlåsningen skulle bli mot
IBM är svår att avgöra utan vidare utredning. IBM DB2 uppges följa standards i stor
utsträckning.
IBMs prissättning har inte förändrats särskilt mycket de senaste åren och det finns inget
som indikerar att licensmodellen och prissättning kommer att förändras drastiskt.
MySql
Rekommendation Databashanterare
Ladoks förvaltning
Anna-Karin Bergman
Version 1.0
2014-05-16
Sida: 7 (8)
Oracle äger kodbasen för MySql och det går därför inte säkert att säga MySql kommer
att vara fritt att använda framöver. I dagsläget finns det både öppna och kommersiella
licensierade versioner av MySql som tillhandahålls av Oracle. Den öppna versionen är
enklare och innehåller inte lika mycket funktionalitet som den kommersiella versionen
av MySql. Skulle MySql kommersialiseras av Oracle finns det flera intressanta öppna
avknoppningar av MySql som skulle kunna ersätta MySql.
MariaDB
MariaDb uppges vara en direkt avknoppning av MySqls version 5.1. Eftersom MariaDB är
ett öppet alternativ är risken för leverantörsberoende i princip obefintlig. Risken kan
snarare bli den motsatta, dvs. svårigheter i att få support och föra dialog med en tydlig
motpart om vilket stöd som finns i produkten. I dagsläget finns det möjlighet att köpa
support från SkySql. Så länge det finns en stark uppslutning bakom produkten är
chanserna goda att produkten håller god kvalitet. Hur stor uppslutning MariaDb
kommer att få är för tidigt att säga då produkten är så pass ny.
4.5
Kostnadsjämförelser mellan lösningarna för ett normalår efter
sista produktionssättningen av nya Ladok.
IBM DB2
I Umeå Universitets anbud för driften av Ladok uppges att den årliga
underhållslicenskostnaden kommer uppgå till 263 000 kr/per år då systemet är fullt
produktionssatt.
MySql
Då infrastrukturplattformen kan komma att se annorlunda ut jämfört med om DB2
används är det svårt att säga exakt vad kostnaden för support av MySql skulle bli för det
nya ladoksystemet. Ändringar i infrastrukturplattformen kan också i sig medföra
kostandsökningar. I dag kostar support för MySql i befintligt Ladok 240 000 kr/år.
Denna support avser den öppna enklare versionen som Oracle tillhandahåller.
MariaDB
Supporten för MariaDb i befintligt Ladok beräkas till 240 000 kr/år.
Då MariaDb är en avknoppning av MySql är det precis som för MySql svårt att säga vad
supportkostnaden för det nya Ladoksystemet blir.
4.6
Konsekvenser hos vald driftleverantör (ekonomiska, kvalitativa
eller andra)
Anbudet från ITS är baserat på antagandet att DB2 kommer att användas som databas.
Driftmiljön i anbudet är helt och hållet anpassad efter DB2 och kostnaderna beräknade
enligt dessa premisser. ITS besitter kompetens om både DB2 och MySql, men betonar
att driftmiljön och kostnader för denna kan komma att förändras om MySql väljs som
databas.
Rekommendation Databashanterare
Ladoks förvaltning
Anna-Karin Bergman
5
Version 1.0
2014-05-16
Sida: 8 (8)
Slutsatser och rekommendation
MySql
MySql bedöms vara en mogen och kompetent databas. MySql antas kunna tillgodose
utvecklingsprojektets och framtida förvaltnings behov. Detta är dock inte verifierat
genom tester. MySql bedöms som en stabil databas för mellanstora system med jämn
belastning. Vid högintensiv belastning där flera databaser ingår i ett så kallat kluster
finns risk för datainkonsistens i fall av datorkrasch eller haveri.
Innan beslut fattas om att införa MySql i det nya Ladoksystemet bör tester göras för att
verkligen säkerställa att MySql svarar mot de krav som ställs på det nya systemet.
MariaDB
MariaDb är baserat på MySql, vilket innebär samma tekniska fördelar och nackdelar för
de bägge databaserna. Skillnaden mellan MySql och MariaDb är att få än så länge kör
MariaDb skarpt i produktionsmiljö.
MariaDB verkar lovande, men fler tester och verifieringar borde göras om MariaDB
övervägs som alternativ för det nya Ladoksystemet.
DB2
DB2 är en väldigt omfattande databas med mycket funktionalitet. En del av
funktionaliteten är med största sannolikhet överflödig för Ladok. Vad som talar för DB2
som alternativ för det nya Ladoksystemet är att det är en mycket driftsäker databas som
har hög kapacitet. DB2 har vidare mer inbyggt stöd för en mer flexibel
infrastrukturplattform, vilket konkret innebär att resurser kan allokeras dynamiskt vid
behov. Det är en stor fördel att inte behöva en konstant hög fysisk kapacitet i form av
servers, vilket är kostnadsdrivande.
I nuläget bedöms DB2 vara den databas som bäst kan svara mot de krav som kommer
ställas på det nya Ladoksystemet. MySql kan vara ett bra alternativ, men det är inte
verifierat. Om MySql och/eller MariaDb övervägs som databas för det nya
Ladoksystemet är det en stark rekommendation att inleda tester för att säkerställa att
Ladoksystemet kommer att leva upp till ställda krav och förväntad kapacitet.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2011-01-01
Sida: 1 (26)
PM Översikt av möjliga
databashanterare i Ladok3
Syftet med rapporten är att ge en översikt av möjliga databashanterare (DBMS) för
Ladok3.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
Statusrapport
2011-01-01
Sida: 2 (26)
Innehåll
1
Sammanfattning ....................................................................................................... 4
2
Introduktion.............................................................................................................. 5
3
Produktöversikt ........................................................................................................ 6
3.1
3.2
3.3
3.4
3.5
4
Support/Licensavtal ................................................................................................. 8
4.1
4.2
4.3
4.4
4.5
5
IBM DB2 ...................................................................................................................... 12
Oracle ........................................................................................................................... 12
MS SQL Server ........................................................................................................... 12
PostgreSQL .................................................................................................................. 12
MySQL ......................................................................................................................... 12
Övervakningsverktyg ............................................................................................. 13
8.1
8.2
8.3
8.4
8.5
9
IBM DB2 ...................................................................................................................... 11
Oracle ........................................................................................................................... 11
MS SQL Server ........................................................................................................... 11
PostgreSQL .................................................................................................................. 11
MySQL ......................................................................................................................... 11
Kluster ..................................................................................................................... 12
7.1
7.2
7.3
7.4
7.5
8
IBM DB2 ...................................................................................................................... 10
Oracle ........................................................................................................................... 10
MS SQL Server ........................................................................................................... 10
PostgreSQL .................................................................................................................. 10
MySQL ......................................................................................................................... 10
Failover.................................................................................................................... 11
6.1
6.2
6.3
6.4
6.5
7
IBM DB2 ........................................................................................................................ 8
Oracle ............................................................................................................................. 8
MS SQL Server ............................................................................................................. 8
PostgreSQL .................................................................................................................... 9
MySQL ........................................................................................................................... 9
Backup ..................................................................................................................... 10
5.1
5.2
5.3
5.4
5.5
6
IBM DB2 ........................................................................................................................ 6
Oracle ............................................................................................................................. 6
MS SQL Server ............................................................................................................. 6
PostgreSQL .................................................................................................................... 7
MySQL ........................................................................................................................... 7
IBM DB2 ...................................................................................................................... 13
Oracle ........................................................................................................................... 13
MS SQL Server ........................................................................................................... 13
PostgreSQL .................................................................................................................. 13
MySQL ......................................................................................................................... 13
Stöd för avancerad SQL ........................................................................................ 14
9.1
Deferrable constraints................................................................................................. 14
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
9.2
9.3
9.4
9.5
9.6
9.7
9.8
10
Statusrapport
2011-01-01
Sida: 3 (26)
Check constraints ........................................................................................................ 14
Table functions ............................................................................................................ 15
Common table expressions (CTE) / Recursive queries ............................................ 15
OLAP / Windowing functions .................................................................................... 16
Funktionsbaserade index ............................................................................................ 16
Uppdaterbara vyer ...................................................................................................... 16
Materialiserade vyer ................................................................................................... 17
Stöd för Datatyper ............................................................................................... 18
10.1 CHAR......................................................................................................................... 18
10.1.1 Standard ................................................................................................................ 18
10.1.2 DB2 ...................................................................................................................... 18
10.1.3 MSSQL................................................................................................................. 18
10.1.4 Postgres ................................................................................................................ 18
10.1.5 Oracle ................................................................................................................... 18
10.1.6 MySQL ................................................................................................................. 18
10.2 Timestamp ................................................................................................................. 19
10.2.1 Standard ................................................................................................................ 19
10.2.2 DB2 ...................................................................................................................... 19
10.2.3 MSSQL................................................................................................................. 19
10.2.4 Postgres ................................................................................................................ 19
10.2.5 Oracle ................................................................................................................... 19
10.2.6 MySQL ................................................................................................................. 19
11
Tidigare utredning mm. ...................................................................................... 20
12
Gartner om DBMS............................................................................................... 22
12.1 Sammanfattning ........................................................................................................ 22
12.2 Inledning .................................................................................................................... 22
12.3 Servermiljö och prestanda ....................................................................................... 22
12.4 Kommersiella eller öppna databashanterare? ....................................................... 23
12.5 Öppna lösningar........................................................................................................ 23
12.5.1 MySQL ................................................................................................................. 23
12.5.2 Ingres .................................................................................................................... 23
12.5.3 PostgreSQL .......................................................................................................... 24
12.6 Trender ...................................................................................................................... 24
12.6.1 NoSQL.................................................................................................................. 24
12.6.2 IMDBMS – minnesdatabaser ............................................................................... 24
12.6.3 Databas via PaaS eller SaaS (Platform/Software as a Service) ............................ 25
12.6.4 Öppen källkod ...................................................................................................... 25
12.6.5 Kolumndatabaser .................................................................................................. 25
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
1
2011-01-01
Sida: 4 (26)
Sammanfattning
Tema-0 har implementerats med H2, en databas där ingen information persisteras till
disk, utan ligger i minnet. Viss verifiering och test har skett mot DB2 för att säkerställa
att principerna även kommer att fungera mot en riktig DBMS så småningom. Att det är
just DB2 är av mindre betydelse eftersom ingen DBMS specifik funktionalitet använts,
utveckling kunde lika gärna ha skett med någon av de andra DBMS.
En genomgång material från Gartner kring databashanterare har även gjorts, men har inte
visat på någon specifik rekommendation av databashanterare.
En avvägning måste förmodligen ske mellan hur portabel respektive effektiv datalagring
man vill använda i slutändan. Om man väljer att bara använda funktionalitet som stöds av
samtliga DBMS så kommer man att få en ganska mager uppsättning funktionalitet, som
riskerar att bli ineffektiv. Om man å andra sidan använder många DBMS specifika
konstruktioner blir lösningen mindre portabel. Av denna anledning är det angeläget att
tidigt välja DBMS och att därefter noggrant dokumentera de eventuella avvikelser från
SQL-standarden som man väljer att använda.
Det som framkommit i vår utredning är att:







Det finns möjlighet till kommersiell support för samtliga granskade DBMS.
DB2, Oracle, MySQL och Postgres supportas på en mängd olika plattformar,
medan MS SQL Server enbart stöds på Windows plattformen.
Samtliga granskade DBMS erbjuder bra stöd för backup.
Det finns ett flertal leverantörer av övervakningsprogramvara för samtliga DBMS
Samtliga DBMS erbjuder någon form av hot standby lösning
DB2, Oracle, MSSQL och Postgres implementerar många nyare konstruktioner i
SQL standarden, medan MySQL överlag implementerar ganska få nya
konstruktioner.
Ingen av de granskade DBMS spänner upp all SQL-funktionalitet som övriga
DBMS implementerar.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2
2011-01-01
Sida: 5 (26)
Introduktion
Det finns en stor mängd databashanterare (DBMS) och att utvärdera alla alternativ skulle
bli en mycket lång och utdragen process. Rapporten kommer därför att fokusera på
följande DBMS





IBM DB21
Oracle2
MS SQL Server3
PostgreSQL4
MySQL5
Rapporten har heller inte för avsikt att göra en uttömmande utvärdering av dessa DBMS,
utan kan betraktas mer som en översikt.
1
2
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp
http://docs.oracle.com/cd/E11882_01/server.112/e10592/toc.htm
3
http://www.microsoft.com/sqlserver/en/us
4
http://www.postgresql.org/docs/9.1/interactive/index.html
5
http://dev.mysql.com/doc/refman/5.5/en/
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
3
2011-01-01
Sida: 6 (26)
Produktöversikt
De aktuella DBMS finns i en rad olika varianter, där pris, funktionalitet och
begränsningar varierar.
3.1
IBM DB2
De olika varianter av DB2 som vi tittat på är
DB2 Express-C
DB2 Express Edition
DB2 Workgroup Server Edition
DB2 Enterprise Server Edition
En översikt av funktionalitet och begränsningar för respektive version finns på:
http://www.ibm.com/developerworks/data/library/techarticle/dm0909db2compare/sidefile.html
http://publib.boulder.ibm.com/infocenter/db2luw/v9r7/index.jsp?topic=/com.ibm.db2.luw
.licensing.doc/doc/r0053238.html
DB2 9.7 supportas på ett antal olika versioner av AIX, HP-UX, Linux, Solaris och
Windows.
3.2
Oracle
För Oracle har vi tittat på följande versioner
Oracle Express Edition 10g
Oracle Standard Edition One
Oracle Standard Edition
Oracle Enterprise Edition
En översikt av respektive version finns på
http://www.oracle.com/us/products/database/product-editions-066501.html
Oracle 11g2 supportas på ett antal olika versioner av Windows, Linux, Solaris, HP-UX,
och AIX.
3.3
MS SQL Server
För SQL server har vi tittat på följande versioner
SQL server Express
SQL Server Standard
SQL Server Business Intelligence
SQL Server Enterprise
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2011-01-01
Sida: 7 (26)
En översikt om vad de olika versionerna innehåller ges på
http://www.microsoft.com/sqlserver/en/us/editions.aspx
SQL server supportas på ett antal olika versioner av Windows.
3.4
PostgreSQL
Det finns två olika versioner av PostgreSQL
PostgreSQL (Community edition)
PostgreSQL Plus Advanced Server
Den sistnämnda utvecklas av Enterprise DB och utökar funktionaliteten hos PostgreSQL
på ett antal punkter. En översikt av dessa finns på
http://www.enterprisedb.com/products-services-training/products/postgres-plusadvanced-server
Enterprise DB supportas på ett antal olika versioner av AIX, BSD, Linux, FreeBSD, HPUX, Mac OS X, NetBSD, FreeBSD, UnixWare och Windows.
3.5
MySQL
Finns i två olika versioner
MySQL Standard Edition
MySQL Enterprise Edition
dessa beskrivs under
http://mysql.com/products/
http://mysql.com/products/enterprise/
MySQL 5.5 supportas på ett antal olika versioner av Linux, Solaris, Windows, AIX, Mac
OS X, FreeBSD, HP-UX
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
4
2011-01-01
Sida: 8 (26)
Support/Licensavtal
För att få ett jämförbart pris på vad licens och supportkostnad blir för respektive produkt,
har vi utgått från en fiktiv server bestyckad enligt:
CPU: 2 st. E5-2670 (2.6 GHz, 8 cores)
MEM: 32Gb
I priset ska vara inräknat typiska verktyg för drift såsom online backup.
4.1
IBM DB2
IBMs priser nedan baseras på ett Education-avtal som ger ca 60 % rabatt.
DB2 Express-C är en gratis version där supporten som erbjuds är via forum.
För DB2 Express Edition finns två möjliga upplägg, man kan leasa programvaran för 7
508 Skr per server och år, alternativt köpa programvaran för 22 663 skr per server och
därefter betala 4 540 skr per server och år.
För DB2 Workgroup Server Edition kostar licensen år ett 113 840 skr och efterföljande år
22 768 skr. Som en parantes kan nämnas att detta är den version som antagningssystemet
Nya använder. I produktionssystemet betjänas tre stycken databaser som används för
handläggning, sökandeweb och urval.
För DB2 Enterprise Server Edition kostar licensen år ett 856 800 per server och år för att
efterföljande år kosta 171 360 skr per server och år.
4.2
Oracle
Oracle Express Edition 10g är en gratisversion som fungerar på ett liknande sätt som
DB2’s variant. Omfattas delvis av andra begränsningar än DB2 Express-C.
Oracle Standard Edition One kostar 82 602 per server. Supporten kostar sedan 18 136 skr
per server och år.
Oracle Standard Edition kostar 249 228 skr per server. Supporten kostar sedan 54 830 skr
per server och år.
Oracle Enterprise Edition kostar 1.352.952 kr per server och där supporten sedan kostar
297 648 skr per server och år. För båda dessa belopp kan man enligt uppgift räkna med
50 % rabatt.
4.3
MS SQL Server
Prisuppgifter saknas. Väntar på svar från Licensbolaget
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
4.4
Statusrapport
2011-01-01
Sida: 9 (26)
PostgreSQL
Produkterna kan kostnadsfritt laddas ner och Redpill6 erbjuder två varianter av support
avtal; vardagar 8-17 vilket kostar 44 000 sek per server och år, och 24/7 vilket kostar 58
000 sek per server och år. Redpill erbjuder även DBA-utbildningar och expertkonsulting.
4.5
MySQL
Både MySQL Standard edition och MySQL Enterprise edition kan fritt laddas ner.
Supportkostnaden för MySQL Standard edition är 14 242 skr per server och år. För
Enterprise Edition är motsvarande kostnad 35 604 skr per server och år.
6
http://www.redpill-linpro.com/
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
5
Statusrapport
2011-01-01
Sida: 10 (26)
Backup
Vi kommer att bedöma vilket stöd produkterna har för online och inkrementell backup
samt om backupen kan komprimeras.
5.1
IBM DB2
Samtliga versioner har stöd för online och inkrementell backup. DB2 Express-c saknar
möjlighet till komprimerad backup, medan övriga versioner stöder detta.
5.2
Oracle
Oracle Recovery Manager (RMAN) stöds av alla versioner utom Express Edition, och
möjliggör online backup, inkrementell backup och kompression. Det är i nuläget oklart
vilka backupmöjligheter som ges för Express Edition.
5.3
MS SQL Server
Det framgår inte helt tydligt ur dokumentationen om det är något som skiljer versionerna
åt vad gäller online backup och inkrementell backup. Åtminstone Enterprise stödjer
online och inkrementell backup. Kompression av backup stöds av SQL Server Standard,
SQL Server Business Intelligence och SQL Server Enterprise.
5.4
PostgreSQL
Både PostgreSQL och PostgreSQL Plus Advanced Server stöder online backup. Postgres
inkrementella backup avviker lite grand från övriga genom att den sker på en varm
standby databas.
5.5
MySQL
Via MySQL Enterprise Backup stöds online, inkrementell och compressed backup. Vissa
begränsningar finns för kombinationen av dessa. Gäller för innodb tabeller. T.ex. myisam
tabeller kan backas upp, men med reservationen att de inte är skrivbara under tiden som
backupen av respektive tabell pågår.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
6
2011-01-01
Sida: 11 (26)
Failover
Syftet med punkten är att avgöra huruvida produkten stödjer failover till en standby
server. I de fall där en produkt stöder flera olika sätt att åstadkomma detta, kommer vi
bara att nämna en.
6.1
IBM DB2
Samtliga versioner utom DB2 Express-C är möjliga att licensiera för High Avalabitity
Disaster Recovery (HADR). Failover databasen licensieras med en delmängd av de
licenser som gäller för den aktiva databasen. Failover databasen kan användas för read
only, men då krävs fullständiga licenser.
6.2
Oracle
Oracle Dataguard kan licensieras för Oracle Enterprise Edition och tillhandahåller
funktionalitet för failover
6.3
MS SQL Server
Enterprise, Business Intelligence och Standard stöder alla logshipping, databasspegling
och failover mellan två noder i ett kluster. Enterprise stöder dessutom mer avancerade
koncept.
6.4
PostgreSQL
Stöder logshipping och ett antal replikeringsmekanismer. I tillägg finns ett antal
kommersiella implementationer.
6.5
MySQL
För innodb existerar logshipping och replikering
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
7
Statusrapport
2011-01-01
Sida: 12 (26)
Kluster
Kluster är egentligen ett lite olyckligt begrepp då det åtminstone finns tre olika syften
med att klustra en databas.
 Hög tillgänglighet, t.ex. failover. Då vi redan berört detta under föregående punkt
berör vi inte detta mer här. Benämns ibland ”scale up”
 Partionera data på olika noder, typisk Datawarehouse scenario (DW).
 Ökad parallellism, typiskt OnLine Transactional Processing (OLTP) scenario.
Benämns ibland ”scale out”
7.1
IBM DB2
Data Partition Feature (DPF) är inte längre tillgängligt i rena DB2 versioner, utan man
hänvisas här till IBM InfoSphere Warehouse product editions. Det är en share nothing
arkitektur, men eftersom vi inte känner till något pris på den versionen berör vi den inte
mer här.
För OLTP kan PureScale licensieras för Enterprise och ingår med vissa begränsningar för
workgroup edition. Det är en share everyting arkitektur där upp till 128 identiska noder
kan klustras. Alla noder är read/write.
7.2
Oracle
Oracle Real Application Clusters (RAC) ingår I en begränsad version (BabyRAC) I
Standard Edition, och kan tilläggslicensieras till fullo I Enterprise Edition. Det är för mig
oklart hur många noder som kan användas, men praxis verkar vara att inte använda fler
än fem. RAC används för både ”scale up” och ”scale out”
7.3
MS SQL Server
Saknar uppgift om huruvida MSSQL stöder ”scale out” och partitionering av data över
flera noder.
7.4
PostgreSQL
Finns ett antal olika klustermekanismer, som ibland överlappar varandra i funktionalitet.
Den som mest påminner om en share nothing arkitektur är pgpool-II. Oklart om det finns
någon mekanism för read/write på parallella noder.
7.5
MySQL
För MySQL finns NDB motorn som kan användas för klustring. NDB är en share nothing
arkitektur. NDB avviker en del från innodb vad gäller t.ex. semantik för transaktioner,
och foreign keys. NDB har begränsningar i hur mycket data som kan hanteras som
baseras på den mängd minne som finns totalt på samtliga noder. T.ex. klarar 48 noder
med 64Gb minne var 3Tb data.
För DW erbjuds ett antal alternativa kommersiella motorer såsom Calpont's InfiniDB,
Infobright's BrightHouse engine och Kickfire. Vi känner idag inte till någon prisbild för
dessa.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
8
2011-01-01
Sida: 13 (26)
Övervakningsverktyg
Syftet med punkten är att undersöka om det finns stöd för tredjeparts
övervakningsverktyg. Fördelen med ett sådant är att det eventuellt går att använda till
andra produkter än aktuell DBMS och på så sätt minska mängden administration och
kostnad för övervakning. Vi har inte undersökt vilka övriga produkter som eventuellt
stöds utav dessa, eller vilka licenskostnader dessa medför.
8.1
IBM DB2
Exempel på leverantörer är IBM, Hyperic och Computer Associates
8.2
Oracle
Exempel på leverantörer är Quest, IBM och Hyperic
8.3
MS SQL Server
Exempel på leverantörer är Quest, Red Gate och Hyperic
8.4
PostgreSQL
Exempel på leverantörer är Manageengine och Veraxsystems
8.5
MySQL
Exempel på leverantörer är Solarwinds och Hyperic
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
9
2011-01-01
Sida: 14 (26)
Stöd för avancerad SQL
Här har vi valt ett antal begrepp från olika delar av SQL-standarden (SQL92 – SQL2011).
Det är ett antal slumpmässigt valda konstruktioner med potentiella användningsområden i
Ladok3, som i bästa fall ger en antydan om hur snabbt en DBMS produkt väljer att
implementera nya delar av standarden. Vi tittar på om dessa är implementerade, samt en
tänkt möjlig användning i Ladok3.
9.1
Deferrable constraints
Möjligheten att förskjuta validering av ett constraint tills dess att transaktionen avslutas.
Exempel:
SQL2003: F491, "Constraint management"
F721, "Deferrable constraints"
F381, "Extended schema manipulation"
ALTER TABLE egg ADD CONSTRAINT egg_ref_hen
FOREIGN KEY (cID)
REFERENCES hen(hID)
INITIALLY DEFERRED DEFERRABLE;
ALTER TABLE hen ADD CONSTRAINT hen_ref_egg
FOREIGN KEY (hID)
REFERENCES egg(eID)
INITIALLY DEFERRED DEFERRABLE;
INSERT INTO chicken VALUES(1, 2);
INSERT INTO egg VALUES(2, 1);
COMMIT;
Konstruktionen stöds av Oracle och Postgres men inte av DB2, MSSQL och MySQL.
Konstruktionen möjliggör ömsesidiga beroendeen mellan begrepp. I dagsläget ser vi inget
direkt behov av detta i Ladok3
9.2
Check constraints
Typ av constraint som möjliggör kontroller av typen check ( age > 3 ). Exempel
SQL2003: F491, "Constraint management"
F381, "Extended schema manipulation"
alter table T add constraint x check ( age > 3 )
och en mer avancerad variant
SQL2003: F491, "Constraint management"
F671, "Subqueries in CHECK"
F381, "Extended schema manipulation"
alter table T add constraint x check ( (select count(1) from U where age > 3 ) = 0 );
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2011-01-01
Sida: 15 (26)
Alla utom MySQL stöder den enklare varianten. Den mer avancerade varianten stöds inte
av någon.
För Ladok3 skulle Check constraints kunna användas som ett stöd vid sub-typning av
generaliserade begrepp i datalagret.
9.3
Table functions
Funktion som returnerar en tabell, I någon mån kan det sägas vara en parametriserad vy.
Exempel SQL2003 T326, "Table functions"
create function F (x int, y int)
returns table ( z int )
return (select z from T where z between x and y);
select z from table(F(3,6));
Stöds av DB2, Oracle, MSSQL och Postgres, men inte av MySQL. Funktionaliteten som
kan uttryckas med Table functions kan uttryckas med hjälp av vyer, men erbjuder i vissa
fall ett elegantare sätt att utrycka samma sak.
9.4
Common table expressions (CTE) / Recursive queries
Möjlighet att referera till ett utryck flera gånger I en fråga, inklusive självreferens.
Exempel:
SQL2003 T121, "WITH (excluding RECURSIVE) in query expression"
T131, "Recursive query"
F661, "Simple tables"
with recursive sum_to_10 (n, acc) as (
values (1,0)
union all
select n+1, n+acc from sum_to_10 where n<=10
) select acc from sum_to_10
where n = ( select max(n) from sum_to_10 )
Konstruktionen stöds av DB2, Oracle och MSSQL med ett mindre undantag, det
reserverade ordet recursive kan ej anges utan både rekursiva och icke-rekursiva Common
Table Expression (CTE) deklareras utan recursive.
Konstruktionen stöds helt av PostgresSQL
Konstruktionen stöds inte alls av MySQL.
För Ladok3s del tyder mycket på organisation kommer att representeras i en hierarkisk
struktur. En CTE kan då användas för att besvara frågor av typen vilka institutioner på
fakultet Y vid lärosäte X har fler än Z aktiva studenter.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
9.5
2011-01-01
Sida: 16 (26)
OLAP / Windowing functions
Möjlighet att applicera en funktion på ett “fönster” av data. Exempel
SQL2003, T611, "Elementary OLAP operations"
select t, x, avg(x) over (partition by x
order by t
rows between
1 preceding and 1 following
) as sliding_average
from T
Konstruktionen stöds av DB2, Oracle, MSSQL och Postgres, men inte av MySQL
Analytiska funktioner är ett potentiellt kraftfullt verktyg för analys och uppföljning i
Ladok3.
9.6
Funktionsbaserade index
Möjlighet att indexera ett uttryck på en kolumn. Beskrivs inte i standarden eftersom index
inte ingår i standarden, men är en vanligt förekommande feature bland DBMS.
create index on T ( lower(str) );
Stöds av Oracle, PostgreSQL och MSSQL. Stöds ej av DB2 och MySQL. DB2 stöder en
workaround med en genererad kolumn som sedan kan indexeras. Kolumnen kan gömmas
för användaren och optimeraren gör omskrivningen av frågan transparent för användaren.
En potentiell användning i Ladok3 skulle kunna vara att effektivt kunna söka efter
information utan att känna till hur versaler respektive gemener använts vid inläggning av
uppgiften.
9.7
Uppdaterbara vyer
Möjlighet att uppdatera en eller flera tabeller via en vy. SQL:2008 säger ungefär att en vy
ska vara uppdaterbar så länge uppdateringen innebär en entydig förändring.
Alla DBMS utom PostgreSQL har stöd för att uppdatera mer eller mindre komplicerade
vyer. Ingen DBMS implementerar formuleringen i SQL2008 fullt ut. PostgreSQL har ett
regelsystem som kan användas för att uppdatera vyer. DB2, Oracle och MSSQL erbjuder
INSTEAD OF triggers där man kan specificera vad en uppdatering av en vy innebär.
MySQL erbjuder inget stöd för att uppdatera vyer utöver triviala uppdateringar där
uppdateringen av bastabellerna direkt kan härledas ur uppdateringen av vyn.
Ladok3 innehåller ingen datamodell i traditionell mening utan är i allt väsentligt en
objektmodell. Informationen är därför denormaliserad på ett flertal sätt, där samma
begrepp representeras i flera relationer/tabeller och samma relation/tabell representerar
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
Statusrapport
2011-01-01
Sida: 17 (26)
flera begrepp. Normalisering av data har som syfte att undvika uppdateringsanomalier,
och om man eftersträvar en ökad normalisering kan uppdaterbara vyer användas som ett
lager mellan applikationen och databasen för att åstadkomma detta.
9.8
Materialiserade vyer
För realisering av uppföljningstjänsten i Ladok3 har en datawarehouse (DW) lösning
diskuterats. Ett sätt att implementera ett DW är via ett star alternativt snowflake schema.
Båda dessa kännetecknas av att man har en eller flera denormaliserade fakta tabeller och
ett antal dimensionstabeller. En Extract, Transform, Load (ETL) process ansvarar typiskt
för att uppdatera faktatabellerna. Ett alternativt sätt att implementera ett DW är att låta
underlagstabellerna fortsatt vara normaliserade, och att erbjuda vyer som motsvarar
faktatabeller.
En vy är i allt väsentligt en namngiven fråga som evalueras när man refererar den i en
rapport. För en materialiserad vy skapas resultatet av evalueringen fysiskt antingen i
realtid eller vid givna tidpunkter. När man refererar en materialiserad vy behöver inte
frågan som vyn representerar beräknas, utan resultatet finns redan tillgängligt. En annan
skillnad är att en materialiserad vy kan indexeras precis som en vanlig tabell. Nackdelen
med materialiserade vyer är en ökad kostnad vid uppdatering av underliggande tabeller.
MSSQL har stöd för indexerade vyer i samtliga versioner. Dock kommer dess optimerare
bara att kunna dra full nytta av vyn i Enterprise Versionen. Oracle har stöd för
materialiserade vyer i Enterprise Edition och DB2 har materialiserade query tables
(MQT) i Enterprise Server Edition
För MySQL och PostgreSQL finns inget färdigt stöd i produkterna, utan man hänvisas till
att använda en vanlig tabell, och själv populera den.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
Statusrapport
2011-01-01
Sida: 18 (26)
10 Stöd för Datatyper
Ett urval av datatyper och hur de hanteras av standard och av respektive DBMS. I Vissa
fall kan en produkt konfigureras för att utföra en striktare kontroll, men jämförelsen
nedan avser den inställning som är default.
10.1 CHAR
10.1.1 Standard



Return with an exception state if the inserted string is too long, unless the
characters exceeding the limit are all spaces.
Pad CHAR columns with spaces if the inserted string is shorter than the
specified CHAR-length.
Pad with trailing spaces as needed when casting or comparing to other stringlike values (e.g. VARCHARs).
10.1.2 DB2
Följer standard. Har dock en egenhet när det gäller utf-8. CHAR(x) anger antal bytes som
typen allokerar, inte antal tecken. Ett alternativ är att använda den proprietära typen
GRAPHIC, vilket innebär att strängen sparas i UCS-2.
10.1.3 MSSQL
Följer standard med undantag för att strängar trunkeras map. white space innan vissa
funktioner (t.ex. len()) appliceras.
10.1.4 Postgres
Följer standard med undantag för att strängar trunkeras map white space innan vissa
funktioner (t.ex. CHARACTER_LENGTH), och vissa operationer (t.ex. ||) appliceras.
10.1.5 Oracle
Följer standard med ett minimalt undantag. Kastar exception även om överskjutande
tecken är white space
10.1.6 MySQL
Bryter mot standard på ett flertal sätt. Trunkerar strängen även om överskjutande
bokstäver inte är white space och trunkerar konsekvent all avslutande white space.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2011-01-01
Sida: 19 (26)
10.2 Timestamp
10.2.1 Standard



Part of the Core requirements, feature ID F051-03.
Stores year, month, day, hour, minute, second (with fractional seconds; default is
6 fractional digits).
Extension to Core SQL (feature ID F411): TIMESTAMP WITH TIME ZONE
which also stores the time zone.
10.2.2 DB2
Har TIMESTAMP, men inte TIMESTAMP med TIMEZONE. Bra typkontroll av att t.ex.
ett datum är giltigt
10.2.3 MSSQL
Saknar timestamp, men har en snarlik datatyp DATETIME. DATETIME är ingen typ i
standarden, utan ett samlingsbegrepp för DATE, TIME och TIMESTAMP. Maximal
upplösning är 3 decimaler. Bra typkontroll av att t.ex. ett datum är giltigt
10.2.4 Postgres
Har både TIMESTAMP och TIMESTAMP med TIMEZONE. Bra typkontroll av att t.ex.
ett datum är giltigt
10.2.5 Oracle
Har både TIMESTAMP och TIMESTAMP med TIMEZONE. Bra typkontroll av att t.ex.
ett datum är giltigt. Av okänd anledning får man inte använda TIMESTAMP med
TIMEZONE i nycklar.
10.2.6 MySQL
Bryter mot standard på ett flertal sätt. TIMESTAMP är inte samma sak som standarden
beskriver, bl.a. finns det ett antal sidoeffekter. Har en DATETIME p.s.s som MSSQL.
Högsta möjliga upplösning är sekund. Godkänner högre upplösning, men sparar inte
informationen. Saknar vettig kontroll av att datum är giltiga i grundkonfiguration. Om ett
datum är ogiltigt används en speciell markör som inte är ett datum. Den har ett antal
lustiga egenskaper, t.ex. är den null samtidigt som den inte är det.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2011-01-01
Sida: 20 (26)
11 Tidigare utredning mm.
Den tidigare utredningen (TEK-07-T-02) som berörde byte av DBMS i Ladok2
avhandlades ORACLE 10G, IBM DB2 9.1, Mimer 9.3, Microsoft SQL Server 2005,
MySQL 5.1 och PostgreSQL 8.2. Förutsättningarna för denna utredning var något
annorlunda, då man där hade ett antal väldefinierade krav att jämföra respektive DBMS
med. Detta till trots kan det vara intressant att se vilka argument för respektive emot som
användes, och om de fortfarande är relevanta.
Ett skallkrav var att DBMS skulle kunna driftas på Linux och detta gjorde att Microsoft
SQL Server 2005 uteslöts som ett alternativ. Det kravet har gissningsvis fortfarande en
viss relevans, oklart dock om det fortfarande är ett skallkrav.
PostgreSQL valdes bort av två huvudsakliga anledningar, dels att det inte fanns något
färdigt stöd för postgreSQL gentemot Uniface, dels för att det kommersiella stödet för
produkten bedömdes som lågt. PostgreSQL uppfyllde annars kravbilden väl, och att den
byggs med hjälp av öppen källkod sågs som positiv egenskap. Uniface argumentet saknar
helt relevans för Ladok3, och EnterpriseDB har idag en ledande ställning när det gäller
kommersiellt stöd för PostgreSQL. Gissningsvis finns det nog ändå ett större urval av
driftorganisationer som är vana vid att drifta övriga alternativ.
Mimer var den DBMS som man ville byta ifrån, men var ändå med som ett alternativ
(dvs att inte byta). Mimer var med dåvarande licensmodell betydligt dyrare än övriga
alternativ och förtroendet för leverantören var lågt. Detta tillsammans med en misstanke
om att Mimer skulle inrikta sin utveckling i huvudsak mot mobila enheter gjorde att
Mimer valdes bort. Då Mimer inte ingår som ett alternativ i denna utredning gör vi ingen
bedömning huruvida förutsättningarna har ändrats eller ej.
DB2 9.1 var den DBMS som klarade kravbilden näst bäst av de utvärderade alternativen.
Det verkar i huvudsak ha varit frånvaron av en färdig driver mot Uniface och att Ladok2s
driftcentraler inte hade någon större erfarenhet av denna DBMS som gjorde att den till
slut föll bort. Uniface argumentet saknar helt relevans för Ladok3 och huruvida någon av
de då inblandade driftcentralerna kommer att drifta Ladok3 är oklart.
Oracle var den enda av de utvärderade alternativen som klarade alla skallkraven. Till
skillnad mot DB2 fanns det en färdig driver för Uniface och Oracle verkar också ha varit
driftcentralernas första val då man hade relativt stor erfarenhet av att drifta Oracle. För
Ladok3 är därför Oracle och DB2 likvärdiga ur den utredningens perspektiv.
MySQL var den DBMS som slutligen valdes som ny DBMS i Ladok2. MySQL saknade
liksom DB2 en färdig driver för Uniface och uppfyllde dessutom inte ett annat skallkrav,
samt var något sämre på bör och önskas krav. Driftcentralerna hade relativt god vana av
att drifta MySQL och produkten hade ett attraktivt pris. På samma sätt som för
PostgreSQL antyds att det är positivt att produkten byggs med öppen källkod.
Via telefonsamtal med Jonas Brorsson framkom att man från förvaltningsorganisationens
sida vill undvika ”inlåsning” i en produkt, dvs. att undvika att använda DBMS specifik
funktionalitet som inte på ett enkelt sätt kan uttryckas på liknande sätt i en annan DBMS.
I den tidigare utredningen hade frågan om samordningsvinster med att välja samma
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
2011-01-01
Sida: 21 (26)
Lennart Jonsson/Reijo Soreus
DBMS som NyA (DB2) tagits upp, men så vitt jag kan förstå lyckades man aldrig påvisa
några sådana. Det är lite oklart som frågan utreddes och man kom fram till att det inte
fanns några sådana samordningsvinster, eller om någon sådan undersökning aldrig
gjordes.
Ytterligare en aspekt som inte framkom i samtal med Jonas, men som verkar rimlig, är att
man i dag har erfarenhet av MySQL som DBMS, och att denna erfarenhet skulle kunna
tas tillvara vid ett val av denna DBMS.
Eftersom driftleverantör inte är fastställd är det omöjligt att förutspå vilken erfarenhet en
sådan har av respektive DBMS. Via telefonsamtal med Torbjörn Andersson på Logica
(en av de DBA:er som driftar NyA), framkom att deras fördelning av drift på respektive
DBMS i Sverige ut ungefär som:
Oracle
SQL Server
DB2
MySQL
PostgreSQL
35%
35%
25%
5%
0%
Siffrorna är mycket ungefärliga och det finns inget som garanterar att andra
driftorganisationer har en liknande fördelning av drift.
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
2011-01-01
Statusrapport
Sida: 22 (26)
Lennart Jonsson/Reijo Soreus
12 Gartner om DBMS
12.1 Sammanfattning
Det finns två huvudspår för val av databashanterare, proprietära lösningar eller öppen
källkod. De dominerande aktörerna av proprietära lösningar är Oracle, Microsoft och
IBM. De största öppna produkterna är MySQL, PostgreSQL och Ingres.
Lösningar baserade på öppen källkod har enligt Gartner för ca 1% av marknaden,
nischade främst på webbpublicering.
12.2 Inledning
Projektet har ett antal tekniska val framför sig, varav val av databashanterare är ett. Detta
PM sammanfattar innehållet i ett antal analyser från Gartner.
Dokument som gåtts igenom är:




Adopt Best Practices to Choose Your ERP Platform
Adoptation Trends in Open-Source Database Management Systems
IT Market Clock for Database Management Systems, 2011
Magic Quadrant for Data Warehouse Database Management Systems
Målet med underlaget är att plocka ut rekommendationer eller analyser som kan hjälpa
oss förankra och att fatta ett beslut.
12.3 Servermiljö och prestanda
Gartner rekommenderar x86-plattformar med Linux eller Windows, att man väljer
administrationsverktyg och databashanterare innan man funderar på hårdvaran samt att
man utvärderar krav på nätverkstrafik, lagringskapacitet och virtualisering inför beslut.
Man bör överväga andra plattformar än x86 endast då belastning och krav på
tillgänglighet överskrider gränserna för x86.
OS
Windows Linux
Unix
Oracle
8 cores
64 cores
64 to 512 cores
16 threads
128 threads
128 to 1024 threads
RAC beyond this
SQL Server
32 cores
not applicable (NA)
NA
32 cores
64 to 512 cores
64 threads
128 to 1024 threads
64 threads
DB2
NA
DBMS Operating Environment Limits in Production
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2011-01-01
Sida: 23 (26)
12.4 Kommersiella eller öppna databashanterare?
Enligt Gartner motiveras normalt val av öppna lösningar med sänkta kostnader, ökad
flexibilitet och avsaknad av leverantörsinlåsning. Begränsande faktorer är kvalitet på
support och stöd för ”high-end functionality” för verksamhetskritiska lösningar.
Gartner talar om att företag genom att övergå till öppna databashanterare kan sänka sina
kostnader för dessa med uppemot 80%.
Problemområden som nämns är låsningsproblem vid stort antal samtidiga användare och
stora datavolymer (över en terabyte)
Totalt sett har lösningar baserade på öppen källkod ca en procent av mjukvaruintäkterna
på marknaden för databashanterare, men dessa ökar betydligt mer än de kommersiella
lösningarna vilket indikerar en förändring av marknaden.
12.5 Öppna lösningar
2010 hade MySQL 53%, Ingres 38% och PostgreSQL 9% av de totala
mjukvaruinteäkterna inom området (andelar av den procent av världsmarknaden som
innehas av databashanterare baserade på öppen källkod). Observera att detta gäller
intäkter, inte användande.
12.5.1 MySQL
Gartner bedömer MySQL som den näst mognaste produkten på området, näst Ingres, och
har sedan Sun och därefter Oracle övertog den också snabbt mognat skalbarhets och
stabilitetsmässigt.
Oracle förefaller vara fokuserade på att behålla den marknadsledande positionen för
MySQL och förstår att GPL-versionen är en nyckel till detta.
Ingres och PostgreSQL konkurrerar primärt med Oracle, inte fullt så mycket med
MySQL även om man anser att osäkerheten kring Oracles avsikter med MySQL innebär
en öppning för konkurrenterna att stärka sina positioner.
Gartner tror att en försvagning av MySQL är tillfällig, på sikt torde Oracles
distributionskanaler kompensera för en eventuell försvagning. Detta förutsatt att oron för
inlåsning inte överväger för potentiella nya kunder.
Förgreningar som MariaDB tror man kan möta ett visst intresse från användare som oroar
sig för Oracle, men man ser inte något större användande ännu. Time will tell.
12.5.2 Ingres
Ingres, vilken bedöms som den mest mogna produkten, levererar sin produkt med
funktioner som stödjer affärskritiska applikationer, rollback, redo och databasspegling,
något som enligt Gartner skiljer dem från andra leverantörer av öppen källkod.
“Ingres' open-source relational DBMS supports mission-critical workloads, thereby
challenging the status quo in the data management industry”
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
Statusrapport
2011-01-01
Sida: 24 (26)
Ingres användes 2009 av 136 företag på Fortune 500-listan, men Gartner nämner inte till
vad.
12.5.3 PostgreSQL
Gartner anser att PostgreSQL har vad som krävs för att möta kraven från potentiella
MySQL-kunder både vad gäller teknik likväl som kostnad.
Man nämner att EnterpriseDB, som levererar PostgreSQL och PostgresPlus till företag,
lyckats trots endast en 9%-andel av företagsmarknaden attrahera $50 M i riskkapital
vilket tyder på ett högt förtroende från investerarna.
EnterpriseDB riktar sig primärt mot Oracle-kunder genom att försöka hålla sig
kompatibla med Oracles produkter, något som Gartner bedömer de inte riktigt lyckas med
ännu. Däremot ser Gartner en öppning att konkurrera med MySQL om kunder som är
tveksamma till Oracle.
12.6 Trender
Gartner talar i rapporten ”IT Market Clock for Database Management Systems” om ett
antal trender där alla inte är relevanta för projektet.
12.6.1 NoSQL
För de flesta användningsområden är NoSQL inte ett alternative pga brist på ACIDkonsistens. Potentiellt negativt är också svårigheterna att använda integrationsverktyg
vilka kräver en djup förståelse för informationsstrukturen i datakällan.
På sikt tror Gartner också att minnesdatabaser kommer att fylla den nisch som NoSQL
finns i idag.
12.6.2 IMDBMS – minnesdatabaser
Minnesdatabaser har funnits sedan många år tillbaka men de flesta idag tillgängliga har
dykt upp de senaste två-tre åren. Gartner räknar med att användandet kommer att öka
exponentiellt framöver tack vare fallande hårdvarukostnader och ökad mognad för
produkterna. Begränsande faktorer som minneskrascher, stöd för återställning och
avsaknad av tillräckligt snabba backup-lösningar kommer att bli allt mindre avgörande.
Tekniken klassas som transformerande tack vare den stora skillnaden i energianvändning
och hastighet jämfört med traditionella diskbaserade lösningar. Med en minnesdatabas
kan man kombinera OLTP och data warehouse i samma lösning.
Minnesdatabaser har potential att helt förändra hur vi ser på och designar databaser och
den infrastruktur som krävs kring dem.
Utvalda leverantörer: Exabyte; Exasol; IBM; McObject; Oracle; SAP; StreamBase
Systems; Sybase, an SAP Company; VoltDB
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Statusrapport
Lennart Jonsson/Reijo Soreus
2011-01-01
Sida: 25 (26)
12.6.3 Databas via PaaS eller SaaS (Platform/Software as a Service)
Plattformerna på marknaden är alla relativt nya och ofta begränsade. Den enda kompletta
tjänsten med ACID-stöd är idag database.com.
Gartner tror att flera tjänster kommer att tillkomma inom de närmaste åren, exempelvis
kommer Azure bli bättre och släppa de existerande begränsningarna allt eftersom. Dock
återstår många problem att lösa.
DBSaaS är användbart för specifika applikationer som organisationen själv inte vill hålla
sig med eller där en leverantör har ett större kunnande.
12.6.4 Öppen källkod
Databashanterare baserade på öppen källkod används primärt för icke
verksamhetskritiska funktioner men under det senaste året anser Gartner att användandet
för kritiska lösningar ökat kraftigt. Inte minst så i och med nya versioner av både MySQL
och PostgreSQL.
Ett problem ligger i att de flesta leverantörer av DBA-verktyg inte stöder de öppna
lösningarna och att de flesta BI-lösningar endast gör det via odbc eller jdbc. Undantag är
leverantörer med bas i öppen källkod såsom Talend och Jaspersoft.
Databashanterare baserade på öppen källkod har problem med att hantera de volymer och
den skalbarhet som krävs för DW-lösningar, något som man ser tecken på är på väg att
ändras. Ett undantag är Ingres Vectorwise som rör sig mot att bli en lösning för analytiska
DW.
TCO för en databashanterare baserad på öppen källkod anser Gartner är högre initialt pga
krav på egen förmåga till underhåll, men allteftersom det kommer fler DBA-verktyg
sjunker kostnaderna i och med frånvaron av licenskostnader.
Gartner rekommenderar öppna lösningar endast för organisationer med hög teknisk
kompetens och en villighet att acceptera risker för bristande skalbarhet och stabilitet.
Utvalda leverantörer (kan antagligen ses som en rekommendation) är EnterpriseDB
(PostgreSQL), Ingres och Oracle.
12.6.5 Kolumndatabaser
Kolumndatabaser lämpar sig för BI och OLTP, främst i formen av minnesdatabaser och
Gartner råder till användande i följande fall:




Data marts
Generella arkivlösningar (hög kompressionsfaktor)
Data warehouselösningar
Tekniska ledare som behöver höga prestanda
Dokument:
PM Översikt av möjliga
databashanterare i Ladok3
Version 1.0
Ladok3-projektet
Lennart Jonsson/Reijo Soreus
Statusrapport
2011-01-01
Sida: 26 (26)
Utvalda leverantörer: 1010data, Exasol, Greenplum, Infobright, ParAccel, Sand, SAP,
Sybase, SAP, HP
Dokument:
PM Val av driftmiljö för Ladok3
Version 0.2
Ladok3-projektet
Beslutsunderlag
Bo Sehlberg
2013-11-27
Sida: 1 (6)
PM Val av driftmiljö för Ladok3
Syftet med dokumentet är att ge ett underlag för beslut kring val av driftmiljö för Ladok3.
Dokumentet ger Ladok3-projektets rekommendation för val av:
 Operativsystem
 Databashanterare
 Webbserver
 Applikationsserver
Dokument:
PM Val av driftmiljö för Ladok3
Version 0.2
Ladok3-projektet
Bo Sehlberg
Beslutsunderlag
2013-11-27
Sida: 2 (6)
Innehåll
1
Inledning ................................................................................................................... 3
1.1
2
Operativsystem ......................................................................................................... 4
2.1
2.2
3
Bilagor ............................................................................................................................ 3
Bakgrund ....................................................................................................................... 4
Rekommendation .......................................................................................................... 4
Databashanterare ..................................................................................................... 4
3.1 Bakgrund ....................................................................................................................... 4
3.2 Rekommendation .......................................................................................................... 5
3.2.1 Open Source DBMS ................................................................................................. 5
3.2.2 Kommersiell DBMS ................................................................................................. 5
4
Webbserver ............................................................................................................... 5
4.1
4.2
5
Bakgrund ....................................................................................................................... 5
Rekommendation .......................................................................................................... 6
Applikationsserver ................................................................................................... 6
5.1
5.2
Bakgrund ....................................................................................................................... 6
Rekommendation .......................................................................................................... 6
Dokument:
PM Val av driftmiljö för Ladok3
Version 0.2
Ladok3-projektet
Beslutsunderlag
Sida: 3 (6)
Bo Sehlberg
1
2013-11-27
Inledning
I den förberedande delen av Ladok3-projektet togs beslut att använda Java som
utvecklingsplattform. Däremot har inget beslut tagits med avseende på operativsystem,
databas, webbserver eller applikationsserver.
Hittills har Red Hat Enterprise Linux Server release 6.3 använts i testmiljöerna och
Windows i utvecklarmiljöerna.
Projektet har hittills använt H2 Java SQL databas i utvecklarmiljöerna (en databas där
ingen information persisteras till disk, utan ligger i minnet). Verifiering och test sker mot
DB2 för att säkerställa att principerna även kommer att fungera mot en riktig DBMS så
småningom. Att det är just DB2 är av mindre betydelse eftersom ingen DBMS-specifik
funktionalitet använts, utveckling kunde lika gärna ha skett med någon av de andra
DBMS:erna. En rapport (PM Möjliga DBMS för Ladok3) kring möjliga databaser togs
också fram, men inget efterföljande beslut har tagits.
På webbserversidan har projektet använt Apache Http Server i testmiljöerna. Ingen
webbserver har använts i utvecklingsmiljöerna.
Som applikationsserver har Apache Tomcat använts i testmiljöer och Jetty i
utvecklarmiljöer.
Eftersom det börjar närmar sig det läge att förvaltningen behöver förbereda driftsmiljöer,
finns behov av att ta beslut om vilken miljö som ska gälla för drift av Ladok3.
1.1
Bilagor
Bilaga
1
Dokumentnamn
PM Möjliga DBMS för Ladok3
Dokument:
PM Val av driftmiljö för Ladok3
Version 0.2
Ladok3-projektet
Beslutsunderlag
2013-11-27
Sida: 4 (6)
Bo Sehlberg
2
Operativsystem
2.1
Bakgrund
Prestanda och funktionalitet är i det närmaste identisk i samtliga Linux-distributioner.
Valet bör främst baseras på:
- Erfarenheter inom utveckling
- Erfarenheter hos förväntad förvaltning
- Erfarenheter hos förväntad drift
- Support/stöd från övriga programvaror i Ladok3 (DBMS, Applikationsserver)
- Stabilitet vid uppgraderingar av operativsystemet
RedHat Enterprise Linux är en av de största kommersiella Linux-distributionerna på
marknaden och har använts av Ladok sedan 2006/2007 och av NyA från start (2005).
Båda projekten har goda erfarenheter av distributionen och driftsleverantörer har i
allmänhet hög kompetens inom RHEL. RedHat Enterprise Linux version 6 släpptes 2010
och är fortfarande den senaste versionen.
2.2
Rekommendation
Red Hat Enterprise Linux Server 6.
3
Databashanterare
3.1
Bakgrund
I rapporten ”PM Möjliga DBMS för Ladok3” ges en översikt av möjliga databashanterare
(DBMS). Rapporten innefattade följande DBMS





IBM DB2
Oracle
MS SQL Server
PostgreSQL
MySQL
Den valda arkitektur och de valda utvecklingsprinciperna för Ladok3 gör systemet
tämligen oberoende av vald DBMS. Beroendet finns främst med avseende på
konfiguration och installations/deploymentscript.
Projektet såg därför inget akut behov av slutgiltigt val av DBMS, utan började tidigt
använda IBM DB2 och H2 Java SQL. Valet av DB2 baserades till stor del på tillgänglig
kompetens i projektet. Valet av H2 baserades främst på dess enkelhet.
Dokument:
PM Val av driftmiljö för Ladok3
Version 0.2
Ladok3-projektet
Beslutsunderlag
Sida: 5 (6)
Bo Sehlberg
3.2
2013-11-27
Rekommendation
Man kan dela in valet i två huvudalternativ: Open Source respektive kommersiell DBMS.
I rapporten ”PM Möjliga DBMS för Ladok3” beskrivs och jämförs de olika alternativen.
När det gäller MS SQL Server, passar den mindre bra in i den valda tekniska miljön
(Unix/Linux/Java), varför den kan uteslutas i valet.
Baserat på rapporten, egna erfarenheter och en del utforskning på webben har projektet
gjort prioritering bland de resterande DBMS. Prioriteringen är uppdelad i två grupper
Open Source respektive kommersiella produkter.
3.2.1 Open Source DBMS


PostgreSQL
o I den jämförelse som görs i ”PM Möjliga DBMS för Ladok3”, så är
PostgreSQL en mer kompetent DBMS än MySQL inom de beskrivna
områdena.
o PostgreSQL följer ISO-standarden för SQL.
o PostgreSQL har bättre stöd för ACID jämfört med MySQL
MySQL
o Stor användarbas, som delvis börjar flytta över till MariaDB
o Utvecklingen har delvis stannat av efter Oracles förvärv. Man kan också
fundera på framtiden med avseende på licenser och Oracles licenspolicy.
o Enklare deployment jämfört med PostgreSQL
o Något lägre supportkostnad jämfört med PostgreSQL
3.2.2 Kommersiell DBMS

IBM DB2 och Oracle är ur teknisk synvinkel för projektets behov likvärdiga.
Valet av DB2 i projektet är främst baserat på att det fanns mer erfarenhet kring
DB2.
Konsekvenserna av att välja en annan DBMS än IBM DB2 består främst i ändringar av
konfigurationer, samt hantering av paketering för deployment, samt script för installation.
4
Webbserver
4.1
Bakgrund
För att möjliggöra SAML2-autentisering (Shibboleth), för att minska komplexiteten när
det gäller SSL-hantering och för att öka säkerheten bör en webbserver läggas framför
applikationsservrarna. För närvarande använder sig projektet av Apache HTTP Server
som webbserver. Apache HTTP Server är de-facto standard och följer med i samtliga
större Linux-distributioner.
Dokument:
PM Val av driftmiljö för Ladok3
Version 0.2
Ladok3-projektet
Bo Sehlberg
4.2
Beslutsunderlag
2013-11-27
Sida: 6 (6)
Rekommendation
Projektet rekommenderar att som front-end för webb och REST-gränssnitt välja Apache
HTTP Server 2.4+. Produkten har en mycket bred användning med stora aktörer och är
en stabil och säker plattform.
5
Applikationsserver
5.1
Bakgrund
Arkitekturen i Ladok3 baseras på att använda webben som plattform. Det betyder också
att det är viktigt att välja en bra applikationsserverplattform. För närvarande använder sig
projektet av Apache Tomcat i testmiljöer. I utvecklarmaskinerna används istället Jetty
som är en enklare applikationsserver.
Det finns ett antal stora applikationsservrar att välja på, rimligtvis främst Apache Tomcat
och JBoss.
Apache Tomcat är den enklare av dessa. Den stödjer den funktionalitet Ladok3 i
dagsläget behöver. Kommersiell support för Tomcat finns men är oprövad i
utvecklingsprojektet. Det kan dock ifrågasättas om behovet av kommersiell support finns
då Open Source-communityn är stor och det är en stabil produkt som funnits länge.
JBoss är en mer avancerad applikationsserver med gott om konfigurations- och
prestandaoptimeringsmöjligheter och betydligt mycket mer funktionalitet än Apache
Tomcat. JBoss är dock en mycket mer komplicerad plattform som kräver högre
kompetens inom utveckling, förvaltning och drift än Apache Tomcat.
NyA bytte 2012 från IBM WebSphere Application Server på grund att WebSphere
bedömdes ligga alltför efter i Java-funktionalitet och för att minska priset på supporten.
5.2
Rekommendation
Projektet rekommenderar att som Java web server använda Tomcat 7. Produkten har en
mycket bred användning med stora aktörer och är en stabil och säker plattform.