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.