Institutionen för datavetenskap

Transkript

1 Institutionen för datavetenskap Department of Computer and Information Science Examensarbete En utredning av NoSQL för iipax av Jonas Hesselryd LIU IDA/LITH EX G 11/012 SE Linköpings universitet SE Linköping, Sweden Linköpings universitet Linköping

2 Linköpings universitet Institutionen för datavetenskap Examensarbete En utredning av NoSQL för iipax av Jonas Hesselryd LIU IDA/LITH EX G 11/012 SE Handledare: Lena Strömbäck Examinator: Lena Strömbäck

3 rapport 2011/8/11 22:20 page iii #5 Sammanfattning NoSQL är ett omtalat ämne just nu. Det finns mycket som talar för att det ska lösa de problem relationsdatabaser lider av. Exempelvis onödigt resurskrävande system eller svårt att konvertera mellan olika format på data. Att lösa dessa problem är något Ida Infront är intresserade av för lagringen i deras ärendehanteringsplattform iipax. Uppgiften är att ta reda på vad NoSQL-begreppet faktiskt innebär och utvärdera utvalda databaser mot Ida Infront och iipax krav. Problemet har angripits genom en litteraturstudie av NoSQL för att sedan undersöka tre databaser: Neo4J, CouchDB och Cassandra. Implementationerna har undersökts för att ge en bättre bild av vad NoSQL innebär i praktiken. Resultatet av arbetet är att NoSQL är ett väldigt diffust begrepp där många är oense om vad som gäller. Det är några olika typer av databaser som räknas till NoSQL men de i sig är ingen definition av begreppet. Olika typer som ofta nämns är dokument, graf och kolumndatabaser. När det kommer till de specifika databaserna ser de ut att ha spännande egenskaper som kan passa iipax, till exempel bra datamodell eller stöd för fulltextindexering. Slutligen kan det sägas att Neo4J i dagsläget ser ut som den bästa kandidaten för lagringen i iipax. iii

4 rapport 2011/8/11 22:20 page iv #6

5 rapport 2011/8/11 22:20 page v #7 Innehåll 1 Inledning Bakgrund Syfte Frågeställning Kravbild Metod Målgrupp Teori Begrepp CAP-satsen ACID BASE Vertikal och Horisontell Skalning RDBMS NoSQL Allmänt Typer av NoSQL iipax Ärende och iipax ACID i iipax Ärendemodell ObjectBase Modell för ett ärende Funktionalitet Neo4J Modelleringsmöjligheter Index ACID Skalbarhet Neo4J APIer Lågnivå API v

6 rapport 2011/8/11 22:20 page vi #8 INNEHÅLL INNEHÅLL Högnivå API: jo4neo Externa verktyg Utvärdering av API CouchDB Modelleringsmöjligheter ACID Skalbarhet Index CouchDB API Lågnivå JSON/javascript API Högnivå: Ektorp API Externa verktyg Utvärdering av CouchDB Cassandra Modelleringsmöjligheter ACID Skalbarhet Index API Cassandra-cli Thrift Kundera Kommentarer på API Exempel Hierarkisk grafmodellering Map/Reduce för join Denormalisering Flera hämtningar Komplexa nycklar Analys Diskussion NoSQL Neo4J CouchDB Cassandra Sammanfattning av diskussion Slutsats Sammanfattning Framtida arbeten vi

7 rapport 2011/8/11 22:20 page 1 #9 Kapitel 1 Inledning Choose your hammer wisely - Emil Eifrem, CEO of Neo Technology 1.1 Bakgrund Behovet av att lagra data ökar hela tiden. Förutom att mängden data ökar blir data mer och mer komplex. De senaste 30 åren har relationsdatabaser dominerat, men de passar inte för all typ av lagring. Data som produceras är inte alltid anpassad efter att sparas ner enligt relationsmodellen. För ungefär tio år sedan visade sig relationsdatabaser inte alls räcka till för vissa företag, de började utveckla sin egen datalagring som frångick relationsmodellen. Exempel på företag som gjorde just detta är Google, Facebook och Amazon. Databaser som inte använder sig av den klassiska relationsmodellen går under den gemensamma benämningen NoSQL (Not Only SQL). NoSQL myntades 1998 av Erik Evans, en av utvecklarna av NoSQL databasen Cassandra. Begreppet kastas runt väldigt flitigt och innebörden är diffus. Ida Infront vill ha en bild av vad NoSQL innebär idag och om det kan vara något för deras egenutvecklade plattform iipax. Ida Infronts iipax är en plattform för ärende- och arkivhanteringssystem. Ärende- och arkivhanteringssystem lagrar ofta komplex data som inte alltid passar att lagra i relationsdatabaser. Det är därför intressant att undersöka om det finns bättre alternativ att lagra data. Mer och mer ärendehantering sker idag elektroniskt och det är därför även intressant att undersöka skalbarhet hos NoSQL databaserna. Idag lagras data med hjälp av en egenutvecklad modul för mappning mellan objekt och relationsdatabas. NoSQL databaserna kommer att jämföras direkt med iipax egna system som idag består av modulen ObjectBase och en relationsdatabas. 1

8 rapport 2011/8/11 22:20 page 2 # SYFTE KAPITEL 1. INLEDNING 1.2 Syfte Syftet med rapporten är att utreda om NoSQL är ett bättre alternativ än relationsdatabaser för någon del av iipax-plattformens datalagring. Problemen som NoSQL är tänkt att lösa är modellering av komplicerade relationer och hantering av större datamängder. Utvärderingen av NoSQL ska först utvärderas teoretiskt på en abstrakt nivå för att successivt gå mot specifika implementationer som praktiskt ska utvärderas mot Ida Infronts intressen. 1.3 Frågeställning Vad innebär NoSQL? Vilka egenskaper har NoSQL i förhållande till relationsdatabaser? Är NoSQL något som passar iipax bättre än nuvarande lagring? - löser den problemen med objekt till relationell mappning? - är det effektivare? 1.4 Kravbild Kravbilden från Ida Infront är att de vill veta hur NoSQL databaser beter sig i jämförelse med nuvarande lagring. Jämförelsen ska ge sammanställning över vilka vinster och förluster som en alternativ lagring skulle ge. Egenskaper som ska undersökas: Modelleringsmöjligheter API/Frågespråk ACID-stöd Fritextindexering 1.5 Metod Informationen samlades in genom sökning i bibliotekets artikelsök och på Google. Det var videoklipp från föreläsningar, bloggar, tidnings- och vetenskapliga artiklar. De valdes med hänsyn till objektivitet. Utifrån den information som samlats in valdes tre databaser ut för att studeras närmare och utvärderas mot Ida Infronts krav. Information om databaserna samlades in genom litteraturstudie mot kravspecifikationen. Därefter testades databaserna praktiskt för att få en djupare insikt. Den praktiska biten innebar att pröva att modellera saker som skulle kunna vara intressanta för iipax. 2

9 rapport 2011/8/11 22:20 page 3 # MÅLGRUPP KAPITEL 1. INLEDNING 1.6 Målgrupp Rapporten riktar sig till de som har kunskap om datorer och programmering. Speciellt antas läsaren ha kunskap om relationsdatabaser och distribuerade system. 3

10 rapport 2011/8/11 22:20 page 4 #12 Kapitel 2 Teori Kapitlet tar upp teori som är relevant för rapporten. Inledande tas begrepp som är kopplade till hela rapporten upp. Efter det diskuteras teori om relationsdatabasers svagheter upp. Det är endast svagheterna som tas upp eftersom endast de som är relevanta för rapporten. Efter det kommer ett avsnitt om begrepp som ofta tas upp i samband med NoSQL. Avslutningsvis ges en översiktlig bild av fyra typer av datalagring: key/value, kolumn-orienterade, graf och dokument. De typerna är bra representanter för NoSQL. 2.1 Begrepp CAP-satsen År 2000 presenterade Eric Brewer CAP-satsen, den bevisades 2002 formellt av Gilbert och Lynch [1]. CAP står för Consistency, Availability och Partition-tolerans. Consistency innebär att databasen ska visa samma data vid alla tillfällen. Availability innebär att resursen ska finnas tillgänglig vid alla tillfällen. Partition-tolerant syftar på att resursen kan delas upp på flera olika maskiner. CAP-satsen säger att endast två av dessa tre krav kan fullständigt uppfyllas av ett distribuerat system. Satsen syftar på ett allmänt distribuerat system men tillämpas på databaser eftersom vissa NoSQL databaser är distribuerade system. Beviset i [1] är att visa med motsägelse att ett partitionerat nätverk kan inte uppfylla både konsistent data och tillgänglighet fullt ut på samma gång. En sammanfattning av beviset är att det i ett asynkront nät finns minst två noder. Noderna har kopior av samma data. Antag att alla meddelanden som skickas i nätverket mellan noderna inte kommer fram. Om det då utförs en skrivoperation i en av noderna, kan omöjligt data bli konsistent i de olika noderna. Ska istället skrivoperationen försäkra sig om att alla kopior av data är uppdaterat i en atomär operation kommer tillgängligheten att försvinna. 4

11 rapport 2011/8/11 22:20 page 5 # BEGREPP KAPITEL 2. TEORI Tillgängligheten kommer att försvinna i det givna scenariot eftersom noderna vill försäkra sig om att all data är lika innan någon får läsa igen. Det kommer inte på något sätt att fungera enligt det givna scenariot ACID ACID är krav som måste uppfyllas av databastransaktioner. De fyra egenskaperna som ingår i ACID är Atomicity, Consistency, Isolation och Durability. Med Atomicity menas att en transaktion ska genomföras i sin helhet eller inte alls. Consistency kravet innehar att allas syn på data ska vara densamma vid alla tillfällen. Isolation betyder att en transaktion ska utföras isolerat från yttre påverkan. Durability syftar på att om en transaktion är utförd ska den bestå BASE BASE står för Basically Available Soft-state Eventually consistent som är ett alternativ till ACID. Kraven innebär att det alltid går att komma åt data men den behöver inte vara konsistent. Data blir dock eventuellt konsistent efter att uppdateringen nått alla noder i systemet. Uppdateringar sker oftast via så kallade Gossip-protokoll. Med det menas, som namnet antyder, att det skickas meddelanden mellan noderna för att sprida de senaste uppdateringarna Vertikal och Horisontell Skalning Skalning innebär att en resurs kan användas i ett större sammanhang. Med andra ord att köra systemet i en större skala, därav ordet. Ett systems mjukvara kan i sig vara mer eller mindre skalbart beroende på hur det hanterar en större trafik av data eller operationer. Det vill säga mjukvarans komplexitet. Oavsett mjukvarans komplexitet kommer ett växande system att behöva mer beräkningskraft från hårdvaran. Där talas det om vertikal eller horisontell skalning. I ett system som skalar vertikalt måste mjukvaran köras på en maskin och för att skala upp hårdvaran måste en starkare dator ersätta den föregående. Går systemet istället att skala horisontellt går det att dela upp på flera maskiner. Det kan lösas genom att systemet är decentraliserat och noderna klarar sig själva eller genom att det finns en överordnad nod som sköter kommunikationen. I detta fall går det att komplettera ett system med en extra dator, och behålla de äldre, för att skala systemet. Det anses vara ett mer kostnadseffektivt system då mycket billig hårdvara kan bli bättre än ett dyrt system som endast består av en dator. Till skillnad från att det kallas skala upp i det vertikala fallet brukar det i det horisontella fallet talas om att skala ut. 5

12 rapport 2011/8/11 22:20 page 6 # RDBMS KAPITEL 2. TEORI 2.2 RDBMS RDBMS(Relational Database Management System) skapades på 70-talet. Sedan dess har hårdvaran ändrats enormt mycket medan systemen inte ändrats lika mycket [2]. Relationsdatabaser är långt ifrån utdaterade och sämre än NoSQL på alla punkter. Det finns applikationer som passar bäst i relationsdatabaser och kräver allt som de har att erbjuda, de två kompletterar varandra. Trots att det finns applikationer där relationsdatabaser är det absolut bästa alternativet, tas här bara nackdelarna med RDBMS upp. De svagheter som NoSQL är skapade för att lösa. Skalbarhet RDBMS har designats för att uppfylla C och A, och det leder till att de inte kan uppfylla P fullt ut enligt CAP-satsen. När inte P gäller måste ett RDBMS skala upp vertikalt. Den vertikala skalningen kan bli kostsam hårdvarumässigt. Databasernas fullständiga ACID transaktioner medför en hel del beräkningar. Det kan leda till en ineffektivitet(se nedan) för system som inte kräver all den funktionalitet som RDBMS erbjuder. I storskaliga system kommer den extra overheaden på varje transaktion att göra stor skillnad. Effektivitet RDBMS är ineffektiva i sina transaktioner för att de lämnar många garantier och försäkrar att allt går rätt till. Att systemen är försiktiga och försäkrar sig om att allt går rätt till är inget dåligt i sig. Det kan dock vara onödigt för många applikationer. Det resulterar i att onödigt mycket kraft slösas bort. Enligt [2] är det som tar tid i OLTP(Online Transaction Processing) följande fyra saker: bufferthantering, lås, underhåll av delad datastruktur(latching) och loggar. Dessa tar mellan 10% och 35% var av den totala processtiden. Dessa olika delar krävs för att RDBMS ska kunna garantera ACID egenskaperna. Om ett system tar bort ACID och därmed de fyra nämnda tidskrävande processer, kommer databasen att snabbas upp betydligt. Det var något som MySQL gjorde till en början. De hade inte fullt ACID stöd men utvecklare använde den ändå för att det inte var nödvändigt för applikationen och det blev ett snabbare databassystem. Relationsdatabaser är inte bara ineffektiva på grund av den större overheaden som följer av ACID-transaktionerna. I och med att många av relationsdatabaserna grundar sig på design från 70-talet har vissa designbeslut blivit föråldrade [2]. Det lägger på ännu mer overhead på processerna. Trots att hårdvaran utvecklats explosionsartat de senaste 30 åren har databassystemen inte ändrats så mycket som de skulle behövt. Det gör att systemen inte kan utnyttja den fulla potentialen hos dagens hårdvara. Ett vanligt scenario på 70-talet, var ett stort datacenter med extremt långsamma hårdiskar och lite RAM-minne. Designbeslut som togs då, som idag är utdaterade, 6

13 rapport 2011/8/11 22:20 page 7 # NOSQL KAPITEL 2. TEORI är exempelvis effektiva datastrukturer för få diskaccesser och flitig multitrådning för att systemet skulle kunna göra annat i väntan på de långsamma hårddiskarna. Idag kan många databaser köras direkt i RAM-minnet och allt går så snabbt att multitrådning kan bli onödigt. Skulle dagens hårdvara utnyttjas fullt ut skulle RDBMS gå fortare än vad de gör idag. En Modell RDBMS har i princip bara tabeller där all data lagras. Att lagra all sorts data i samma datamodell är inte alltid en bra idé. Ett exempel är objektorienterad data som inte passar relationsmodellen. Systemen måste kompensera för att fungera tillsammans. Det är ett problem som brukar kallas impendence mismatch problem [3]. Det blir en ineffektiv kombination. [3] beskriver fyra nivåer av problem som uppstår. De är paradigm, språk, schema och instans. Paradigm syftar på problemen som uppstår i kompabiliteten mellan två olika språk, exempelvis ett objektorienterat och SQL. De är olika språk-paradigm. Språk syftar till direkta implementation av språk och de skillnader som kan uppkomma där. Exempel där är Java och SQL. Det kan leda till svårigheter i att utnyttja ett språks fulla potential. Där kan det vara svårt att matcha datastrukturer hos de olika språken. Schemarelaterade problem är att underhålla två versioner av samma sak. Instans problemen är de problemen som uppstår vid hämtning av ett objekt i ett kontext. En mappning ner till relationsdatabas kan medföra att objektet normaliseras ut på flera tabeller som kommer att kräva en insamlig av det fragmenterade data vid varje hämtning. RDMBS har ett fast schema som måste bestämmas innan databasen sätts i bruk. Om databasen ska ändras måste systemet tas ur bruk för att göras om. Det gör databasen jobbigare att underhålla. Det fasta schemat kommer att vara dåligt då data är glest. Det vill säga i ett fall där en datamodell har många fält men det är inte ofta en stor del av fälten används. Ett exempel kan vara användaruppgifter där inte många av fälten är ett krav. En relationsdatabas kommer att behöva skapa ett fält i sitt schema för alla fält oavsett om det används eller inte. Minne kommer då att allokeras utan att användas. Det kommer leda till dålig användning av lagringsutrymme. Problemen då är inte bara ekonomiska utan påverkar även prestandan för att databasen blir tvungen att flytta större mängd data som kanske inte används. 2.3 NoSQL NoSQL(Not Only SQL) är ett begrepp som används på allt från distribuerade filsystem till informationslagrade grafer. NoSQL är enligt många ett förvirrande begrepp. Det gemensamma är att det är datalagring som frångått relationsmodellen och det finns de som istället kallar det för NRDB (Non Relational DataBase). De har gått ifrån den modellen för att i de fles- 7

14 rapport 2011/8/11 22:20 page 8 # NOSQL KAPITEL 2. TEORI ta fall försöka lösa dess problem i modern datalagring. Problemen som ska lösas är en representation närmare en applikations data och möjlighet att köras i enorm skala Allmänt NoSQL databaser skiljer sig väldigt mycket och termen används flitigt, det gör det svårt att sätta fingret på vad som verkligen är en NoSQL-databas. Det finns några koncept som återkommer i många implementationer av NoSQL. Ingen SQL NoSQL har inget gemensamt språk som relationsdatabaserna har. Ett program som använder sig av NoSQL som lagring går genom egna APIer för de olika databaserna. Det finns dock standarder som används. Exempel på sådant kan vara att några databaser använder sig av Apache Thrift, ett ramverk för att kommunicera mellan olika språk. Men det finns även exempel på anpassade språk, exempel på ett sådant är Gremlin som är ett språk för grafdatabaser. Quorum Quorum är en metod som databaser utan ACID kan använvda för att förbättra hur konsistent dess data är. Det är något som bland annat implementerats i Amazons Dynamo [4]. Ordet kan översättas på svenska till kvorum och innebär att man i en grupp måste vara ett visst antal för att kunna ta beslut. Ordet är taget från sammanträdesetik där det ofta måste vara ett visst antal ledamöter på plats för att ett beslut ska kunna tas. När quorum implementeras i ett distribuerat system har de vanligtvis tre parametrar: N, R och W. Det är de vanliga beteckningarna på parametrarna i litteraturen[4, 6]. N står för antalet kopior av data; R är hur många av kopiorna som måste vara med vid skrivtillfället; W är hur många av kopiorna som måste vara med vid lästillfället. Dessa parametrar konfigureras för att uppnå önskat beteende hos systemet. Låga R och W i jämförelse med N kan i större utsträckning leda till inkonsistens. Det leder även till ett snabbare system för att mindre antal resurser måste vara med vid en operation. Att konfigurera i motsatt riktning ger motsatt effekt. En smart konfiguration när quorum används är att följande ekvation ska gälla: R + W >N. Gäller den kan inte en läsning och en skrivning ske samtidigt. Det kommer att leda till konsistent data i större utsträckning. Elastiskt system En del av NoSQL databaserna har ett dynamiskt schema och klarar därför av att ändra på sig utan att stänga ner systemet. Detta kallas för ett elastiskt 8

15 rapport 2011/8/11 22:20 page 9 # NOSQL KAPITEL 2. TEORI system. Det finns NoSQL databaser som är elastiska i sin skalning. Det betyder att nya maskiner kan läggas till under drift och ta en del av belastningen. Elastisk skalning fungerar endast i databaser som skalar horisontellt. Ett exempel på en databas som klarar det är Dynamo[4]. Den har elastisk skalning genom att systemet består av virtuella noder där godtyckligt antal noder kan tillhöra en fysisk nod. Ett elastiskt system är bra ur ekonomioch miljösynpunkt för att antalet maskiner kan anpassas efter den aktuella belastningen utan att systemet behöver gå ner. När systemet bara behöver tillräckligt med maskiner igång för att möta den aktuella belastningen kan maskiner stängas av och sparar därför energi. Map/Reduce Map/Reduce är en teknik som introducerades av Google[5]. Det är en programmeringsteknik för att distribuera beräkningar. Uttrycket kommer från den funktionella programmeringens funktioner map och reduce. Map/Reduce innebär att en uppgift delas upp och distribueras ut, map. Därefter samlas alla resultat ihop och skickas som ett svar, reduce. I många implementationer är inte reduce steget nödvändigt utan map-funktionernas resultat blir resultat. Map/Reduce används i centralstyrda distribuerade system som exempelvis filsystemen HDFS[11] och GFS[7]. Versionshantering Versionshantering används i några NoSQL databaser, [4, 7], för att dels förbättra responstiden men även för att lösa problemet med en förlorad uppdatering. Versionshantering sker genom att data tidstämplas. Responstiden minskar och tillgängligheten ökar i ett system för att systemet aldrig behöver uppdatera data. Det går fortare att bara skriva dit en ny kopia istället för att ta ut data, behandla det och sen skriva. Systemet kommer även att kunna erbjuda data utan att låsa den eftersom systemet kommer att kunna lösa konflikter i data och slå samman olika versioner vid ett senare tillfälle. För att inte allt för många kopior ska kunna visas använder systemen sig av quorum. Då går det att få systemet att visa flera versioner i väldigt få tillfällen [4]. Med versioner av systemet menas att data är inkonsistent och systemet kommer därför att visa olika versioner av data. Så en användare kan se ouppdaterad data medan en annan ser uppdaterad. Det kan även uppstå vid flera läsningar av data samtidigt. Skillnaden mellan de två är att de läser från olika kopior i systemet. Systemet kommer inte att spara hur många kopior som helst utan kommer vid ett senare tillfälle att rensa bland versionerna. Rensning av data sker antingen när en inaktuell version blivit för gammal eller när en kvot av olika versioner passerats. 9

16 rapport 2011/8/11 22:20 page 10 # NOSQL KAPITEL 2. TEORI Typer av NoSQL NoSQL är en benämning på alla typer av databaser som inte använder den klassiska relationsmodellen. Det är därför ett väldigt brett begrepp som används för att benämna databaser som sinsemellan skiljer sig mycket. I litteraturen beskrivs många olika klassningar. De fyra vanligaste klasserna av NoSQL som beskrivs är kolumnorienterade, key/value, graf och dokument. Key/Value Key/Value är en typ av databas som associerar en datamängd med ett unikt nyckelvärde. Datamängden lagras som en BLOB det vill säga ett Binary Large OBject där det inte finns någon struktur som systemet kan använda sig av. Många av systemen är baserade på distribuerade hashtabeller(dht). Exempel på den här typen av databas är Amazons Dynamo [4]. Det är idéerna bakom Dynamo som de allra flesta key/value databaser bygger på. Databaserna erbjuder ofta en avskalad funktionalitet. Det kommer ge en snabbare databas med mycket flexibilitet. Nackdelarna som uppstår i och med avsaknaden av funktionalitet är att mycket komplexitet lämnas upp till applikationslagret av ett system. Det ger högre kostnad i utvecklingen av ett system. Funktionalitet som ofta finns i dessa system är att de är distribuerade, balanserar belastning, decentraliserade, saknat statiskt schema och eventuellt blir konsistenta i data. Funktionaliteten hos ett system varierar givetvis. Detta är dock de vanligaste funktionerna som finns. Egenskaper i ett system är oftast en övervägning mellan de bra och de sämre som följer. När ett NoSQL-system är distribuerat är det viktigt att behålla CAPsatsens P. Det gör att systemets designer måste välja mellan C och A. Det finns varianter av key/value databaser som stödjer båda avvägningarna. Dynamo är en databas som har valt att gå i riktningen mot hög tillgänglighet, A. Medan exempelvis Scalaris har valt att data ska vara konsistent istället. Förenklat kan implementationen, i de två nämnda fallen, av de olika varianterna förklaras med att Quorum-algoritmen är implementerad på olika vis. I fallet med att ha hög tillgänglighet krävs endast ett litet antal av kopiorna för att utföra en operation. I det andra fallet kräver en operation en majoritet av noderna. Belastningen balanseras genom att distribueringen av nycklarna är jämn över de möjliga nyckelvärdena. Så istället för att börja på nyckel nummer ett och fortsätta uppåt väljs nycklar för att få en jämn distribution över de möjliga nycklarna. Om systemet börjar med nummer ett och stegar uppåt kommer all data hamna på den första servern till att börja med. Då kommer de andra servrarna vara oanvända och onödiga tills de andra servrarna är fyllda. Det blir ineffektiv användning av hårdvara då en server kommer vara överbelastad medan de andra är inaktiva. Nyttan med att ha ett decentraliserat system som inte har ett statiskt schema är att det klarar mycket under drift. Att det saknar ett statiskt 10

17 rapport 2011/8/11 22:20 page 11 # NOSQL KAPITEL 2. TEORI schema gör att det går att ändra på strukturen i data under drift. Det är flexibelt men det innebär att det är något som måste tas hänsyn till i applikationslagret. Den extra hänsyn som måste tas av applikationen är kontrollering av data. Applikationer har i de flesta fall begränsningar i vilken data den kan hantera. Den decentraliserade arkitekturen innebär även att systemet klarar av att noder läggs till eller tas bort. Nackdelen med att ha den ovan beskrivna arkitekturen är att data vid vissa tillfällen kommer att vara inkonsistent. Inkonsistensen kommer eventuellt att lösas genom att noder pratar med varandra genom gossip-protokoll. En annan lösning på inkonsistens mellan skriven data kan systemet lösa genom versionshantering. Det som databasen först skapades för var e-handel, många läsningar och hög tillgänglighet. Data i applikationen ska ha mycket läsning men desto färre skrivningar. Databaserna går att skala till väldigt stora mängder data och fortfarande ha bra prestanda. Kolumnorienterade Kolumnorienterade databaser lagrar data efter rader och kolumner. Raderna har alla en unik nyckel, precis som key/value databaserna, som identifierar data. Utöver rader har den kolumnorienterade modellen kolumner som hjälper till att strukturera data. Kolumnerna grupperas sedan in i kolumnfamiljer. Exempel på kolumnorienterade databaser är Googles Bigtable[7] och Cassandra[6]. Implementationen av kolumnorienterade databaser kan på många sätt likna key/value databaserna. Den direkta skillnaden är att data struktureras med hjälp av kolumnerna. Den här typen av databaser är i regel distribuerad vilket ger systemet ett val mellan CAP-satsens C och A. Semistruktureringen är bra för eventuell indexering. Eftersom kolumner kan klassificeras hierarkiskt i kolumnfamiljer som passar bra till indexering är de ofta strukturerade på ungefär samma vis. Kritiken kolumnorienterade databaser kan få är att APIerna har en väldigt låg abstraktionsnivå. Ett typiskt API har endast ett litet antal funktioner. Exempelvis Cassandra har bara tre funktioner insert, get och delete. Det lämnar mycket upp till utvecklaren av applikationen. Eftersom data endast är semistrukturerat kommer den inte att hantera komplex data speciellt bra. Vid komplex data måste applikationen ta hand om komplexiteten den medför. Denna typ av databas är bra att använda för lagring av stora mängder data som ska grupperas. Praktiska exempel är företag som skapat den här typen av databaser, Google och Facebook. Google använder kolumnfamiljer för att gruppera sidor som har länkar till samma sidor. I Facebooks inkorgsökning där Cassandra används klassas meddelanden med samma användar-id i samma kolumn och meddelanden som består av samma ord i samma super kolumn. Det ger mer strukturerad data som blir lättare att indexera och söka i, det är viktigt för båda Facebook och Google. 11

18 rapport 2011/8/11 22:20 page 12 # NOSQL KAPITEL 2. TEORI Graf Grafdatabaser består i huvudsak av tre komponenter: nod, kant och egenskaper. Noden är representationen för ett objekt och kanten är en relation till en annan nod. Egenskaperna är den data som lagras i en nod eller kant. Grafrepresentationen har en stabil matematisk grund och har därför välutvecklade algoritmer. Algoritmerna är väldigt snabba och arbetar lokalt. Den stora prestandavinsten jämfört med relationsdatabaser kommer när en sökning i relaterat data görs. Grafdatabasen behöver endast följa en relation medan relationsdatabasen behöver söka bland olika tabeller eller göra kostsamma joinoperationer med sig själv. En nackdel med grafdatabasernas sökning är att den måste söka genom hela grafen för att ge ett definitivt svar. Sökningen kan då ta onödigt lång tid om svaret endast finns i en liten del av grafen. Detta går att åtgärda med ett index motsvarande som för relationsdatabaser. Grafdatabaser traverserar data med procedurer. Ett exempel på en fråga är att hämta alla som exempelvis uppfyller att vara granne med en annan nod. Sedan måste programmet explicit gå igenom alla svar det fått. Det är alltså en låg abstraktion på frågespråket. Som nämnts ovan är en negativ del av grafdatabaser att de måste söka genom hela grafen för att få svar på nya frågor. Men det går att snabba upp frågor genom att bygga upp index över noder och dess egenskaper. Det ger resultatet att databasen klarar semistrukturerad data bra men strukturerad sämre. Relationsdatabaser har ett väldigt mycket krav på struktur och kan använda den på ett bra sätt. Grafdatabaserna är sämre för att de inte har det kravet och kan därmed inte utnyttja strukturen. Förutom att grafdatabaser är bra på att representera semistrukturerad data är deras starkaste sida att representera relationer[8]. Det i och med att varje kant mellan två noder är en relation. Det blir därför väldigt lätt att fråga efter noder med hjälp av relationer. Exempel på en fråga som skulle bli komplicerad i andra databastyper men lätt i grafdatabaser är vänners vänner i ett socialt nätverk. Databaser med grafrepresentation kommer att skala väldigt bra på en maskin. Ett system kan hantera väldigt mycket data. Men skalbarheten begränsas av att det är svårt att köra ett system i kluster. Men det finns system som stödjer att köras i kluster, exempelvis HypergraphDB. Det positiva med att databaserna bara körs på en nod är att de kan stödja ACID fullt ut. Neo4J är en grafdatabas som stödjer ACID transaktioner fullt ut. Typiska exempel på användningsområden där grafdatabaser gör bra ifrån sig är där relationer är viktiga. Det kan vara exempelvis sociala nätverk eller kunskapsrepresentation i artificiell intelligens, där data naturligt är nätverk. Dokument Dokumentdatabaser är en key/value databas men där värdet är ett dokument. Ett dokument är mer strukturerat än värdet i key/value databaser. 12

19 rapport 2011/8/11 22:20 page 13 # NOSQL KAPITEL 2. TEORI Dokument är schemalösa och kan designas hur som helst och när som helst. Dokumentet är i många fall lagrat som JSON(JavaScript Object Notation) en standard som strukturerar data[10], det är till skillnad mot key/value databaser som lagrar värdet som en BLOB. Strukturen är fri och väljer utvecklaren att lägga in struktur kommer databasen att kunna använda den för hämtning av data. Den fria strukturen medför att det går att skapa entiteter i databasen som stämmer väl överens med ett programs datastrukturer. Det kommer att vara bra för många av de problem som uppstår vid Object-Relational Impendence Mismatch problemet[3]. De lösa kraven på struktur medför även att dokumentdatabaser klarar av data som har ofullständig och gles data. Det är för att schemat i ett dokument är fritt och inte kommer att finnas med om det inte explicit skrivs. Det är bra för att databasen kommer inte att slösa utrymme på tomma utrymmen som kan uppkomma i relationsdatabaser. Dokumentdatabaser har goda möjligheter att skala, databassystemen skalar horisontellt. Men precis som de andra typerna av databaser kommer databasen att behöva välja mellan att ha konsistent data eller att vara tillgänglig. Bristen på struktur och schema kommer att leda till att det inte går att standardisera ett frågespråk. Databassystemet kommer att göra dåligt ifrån sig vid sökning i dokumenten. Att hämta data via nyckeln kommer fortfarande som i key/value databaserna att gå bra och snabbt. Men då kommer behandlingen av dokumenten lämnas upp till programmet. Den typiska applikationen där dokumentdatabaser kan användas är där det finns en struktur som ska användas men där olika delar av strukturen ofta saknas. Det kan vara personuppgifter där många av uppgifterna är valfria. Val av databaser De databaser som i kommande kapitel har valts för att undersökas närmare är Neo4J, CouchDB och Cassadra. Anledningen till att databaserna valts är till stor del deras popularitet och det är förslag som kommit upp vid diskussion med intressenter på Ida Infront. De tre databaserna tillhör typerna graf-, dokument- och key/value databas i respektive ordning. Datbaserna har även valts för att få representanter från olika typer av NoSQL databaser för att rapporten till stor del ska orientera i NoSQL. I valet av databaser fanns även en tanke på att databasen med fördel kunde vara öppen källkod. Öppen källkod är bra för att databaserna är lättillgängliga på internet. Inte bara databaserna utan även information och dokumentation. Mer specifik motivering finns i inledningen till varje kapitel av respektive databas. 13

20 rapport 2011/8/11 22:20 page 14 #22 Kapitel 3 iipax iipax är en plattform för ärendehanteringssystem. Den har en generell modell av ett ärende för att kunna tillämpas på många olika organisationers behov. I dag har iipax en relationsdatabas i grunden. Relationsdatabaser har ACID vilket är ett krav för ärenden men lider av att den komplexa modellen för ärenden inte passar riktigt bra i tabellform. I kapitlet tas det upp varför ärenden behöver ACID och hur modellen för ett ärende ser ut i stora drag. 3.1 Ärende och iipax Ett ärende är en avgränsad fråga som tas upp för behandling. Ärende är ett brett begrepp som kan vara allt från ansökan om byggnadslov till utredning av mord. Ärende som ord används oftast tillsammans med statliga verk och företag men det finns inget som säger att det måste användas i det sammanhanget. Ett ärende har en typisk livscykel där det först öppnas för behandling för att slutligen stängas. Stängning innebär inte ett definitivt slut då ett ärende kan öppnas på nytt. Ärenden är normalt stängda men öppnas ibland för behandling. Anledningen till det är för att ärendehanteringssystem oftast byggs för företag och statliga verk. De har i de allra flesta fall lagkrav på att hålla ett arkiv över gamla ärenden. Mellan öppnandet och stängningen av ett ärende ska det behandlas efter bestämda steg som är olika för olika ärenden. Dessa steg kan naturligt representeras som en ändlig automat eller ett flödesdiagram. Ett exempel kan vara att en person ansöker om byggnadslov. Personen börjar då med att skicka in en ansökan till ett statligt verk. När ansökan då kommer in till verket kommer det att dyka upp i en handläggares inkorg. Säg då att i kontrollen av uppgifterna saknas något. Då måste ärendet markeras med att det ska kompletteras och en begäran på komplettering måste skickas till den berörda personen. Inkommer senare en komplettering kan behandlingen av ärendet fortsätta. Antag då att ett byggnadslov måste ha uppgifter från ett annat statligt verk för att kontrollera att marken inte är 14

21 rapport 2011/8/11 22:20 page 15 # ACID I IIPAX KAPITEL 3. IIPAX naturreservat eller liknande. Då skickas begäran till ett annat statligt verk om dessa uppgifter. När alla uppgifter inkommit kan handläggaren välja att avslå eller godkänna ärendet och det stängs. Visar det sig bli ett avslag kan personen överklaga och ärendet måste öppnas på nytt. Vilket utfall det än blir måste förmodligen det statliga verket spara ärendet i ett arkiv för ett visst antal år framåt av lagkrav. Många av stegen kan automatiseras. Exempelvis kontroller och begäran av uppgifter. Kanske är det till och med så att det öppnas ett ärende i ett annat statligt verk. Då skulle hämtningen av dessa uppgifter ske helt automatiskt. Alla dessa steg är ett tillstånd i diagrammet och förverkligas genom en programmerad modul. På iipax byggs system som kan hantera ärenden. Självaste iipax har generella komponenter som används i många olika typer av ärenden. Ärendehanteringssystem som bygger på iipax kan ses som en realisering av tidigare nämnda automaten som representerar ett ärendes livscykel. Realiseringen är ett grafiskt gränssnitt för handläggare och programmerade moduler som automatiserar olika steg i livscykeln. Ett ärende börjar med att komma till inkorgen hos en ansvarig handläggare. Därefter tar sig ärendet genom olika steg i automaten. Ett steg i automaten kan vara något som måste göras av handledare eller en begäran på ytterligare uppgifter från den berörda, en annan organisation eller ett arkiv. De senare kan ofta skrivas som en plugin som kommunicerar med de olika parterna och kontrollerar uppgifterna. 3.2 ACID i iipax ACID egenskaperna är viktiga för ärendehantering. Det kanske inte är ofta det uppstår situationer då de egenskaperna räddar den, men Murphys lag lyder: Om något kan gå fel så kommer det också att göra de. Går något fel i ett viktigt ärende kan det innebära stora negativa konsekvenser. Här följer anledningar till varför det är viktigt med de olika egenskaperna. Endast ett fåtal fall är beskrivna, listan skulle förmodligen kunna göras lång. A, Atomicity, är viktigt för att en behandling av ett ärende inte får bli halvgjort. Om exempelvis några av ett ärendes attribut ändras och behandlingen sedan avbryts kan det leda till oväntade resultat om ingen ser över ärendet noga och ser att något inte stämmer. Det kanske inte heller syns om något har gått fel. En uppmärksam människa kan se om något har blivit tokigt, men fler och fler processer automatiseras av datorer som kanske inte lägger märke till fel i kontexten. C, Consistency, är viktigt i och med att flera ärenden kan ha samma källa som resurs. Om två ärenden behandlas men olika data ses i de olika fallen kan det leda till olika beslut där de egentligen skulle bedömts lika. Blir något av besluten felaktiga har behandlingen av ärendet misslyckats. I, Isolation, är ett måste för att ett ärendes behandling inte ska påverkas av något yttre. Ändras ett ärendes villkor under behandling kan det leda till 15

22 rapport 2011/8/11 22:20 page 16 # ÄRENDEMODELL KAPITEL 3. IIPAX ett felaktigt beslut. D, Durability, en väldigt viktig punkt för att ett ärende som är behandlat måste förbli så. Det kan uppkomma onödiga tvister om ett ärende om någon tror att ett ärende är behandlat. Behandlingen kan i det fallet ha försvunnit ur databasen av exempelvis en krash. Till exempel, om ett ärende om adressändring behandlas och sen försvinner det kommer personen som flyttat kommer inte att få sin post. 3.3 Ärendemodell Modellen för ett ärende är komplex. Den består av många entiteter och de är kopplade på många olika sätt. Först och främst finns det en entitet för ett ärende. Ett ärende består av ett journalnummer som identifierar ärendet unikt. Till det finns en märkning som visar vart ärendet är i sin livscykel, dvs. öppen eller stängd. På kan det finnas en massa attribut av många olika slag. Dessa attribut orsakar en gles datamodell som är ett av de problemen som relationsdatabaser har. Till varje ärende finns det rättigheter för vem som får besluta om dem. Där finns nästa stora entitet, handläggare. Handläggaren kan ingå i olika arbetsgrupper eller vara någon form av administratör, vilket ger komplexa relationer mellan grupper, handläggare och administratörer. Varje ärende kan ha flera olika tillhörande dokument. De kan ha egna strukturer som kan bli komplexa. På detta ska de tillhörande dokumenten diarieföras i någon form av logg. Det är inte bara dokumenten som behöver loggas utan allt som görs ska helst loggas för att kunna spåra hur ett ärende har behandlats. Olika entiteter i hela systemet beskrivs av attribut och meta data. Dessa måste indexeras för att det ska vara möjligt att söka i systemet och göra det användbart. En bra indexering är därför av stor vikt. Som texten beskriver blir många av strukturer lätt komplexa. Detta kan vid normalisering leda till väldigt många tabeller vilket vid hämtning av data ger många join-operationer, vilket kan leda till ett långsamt system. 3.4 ObjectBase ObjectBase är Ida Infronts egna modul för att spara ner objekt till databas. Den har förutom lagringen av ärenden etc. en hel del extra funktionalitet som iipax drar nytta av Modell för ett ärende Datamodellen som ett ärende har i iipax kan liknas vid en mappstruktur. Den är hierarkisk och utökas efter behov. Olika delar av det som är beskrivet i 3.3 blir till grenar i en trädstruktur. 16

23 rapport 2011/8/11 22:20 page 17 # OBJECTBASE KAPITEL 3. IIPAX Funktionalitet I ObjectBase finns det en hel del extra funktionalitet som iipax använder i samband med lagringen. Funktionaliteten är i många fall skriven i applikationslagret och inte i den underliggande databasen. Validering är en viktig funktionalitet som ObjectBase erbjuder. Den är viktig av framförallt två anledningar; att data ska hålla en viss standard och att det ska gå att kontrollera en användares rättigheter. Eftersom iipax är en väldigt generell plattform för ärendehantering kan de båda nämnda fallen se ut på väldigt olika sätt. Därför blir det även ett krav att valideringen enkelt går att komplettera med en plugin. I ett ärende är olika delar ibland starkt kopplade eller beroende av varandra. Det kan därför vara väldigt praktiskt att ha tillgång till att händelser utlöses vid ändring på exempelvis ett attribut. Ett enkelt exempel på det kan vara en summa. Om en term ändras eller läggs till är det praktiskt om programmet räknar om summan automatiskt. Händelserna kan vara att andra, kopplade, delar kan uppdateras. Detta är något som ObjectBase har stöd för och är viktig funktionalitet för iipax. ObjectBase har stöd för versionshantering. Versionshantering är viktigt i ärendehantering dels för att kunna följa en historik och dels för att återställa om något blir fel. Fulltextindexeringen i iipax görs med hjälp av projektet Apache Lucene. Det är viktigt för att kunna göra fulltextsökningar i databasen av ärenden. 17

24 rapport 2011/8/11 22:20 page 18 #26 Kapitel 4 Neo4J Neo4J är en grafdatabas som är släppt under fri licens för privat bruk, men för kommersiellt måste licenser köpas. Den fria versionen är öppen källkod och byter vid version 1.3 till GNU GPL v3. Företaget som står bakom Neo4J heter Neo Technologies och har sitt huvudkontor i Malmö. Databasen är skriven i Java och den är en av de mer kända grafdatabaserna just nu. Neo4J är släppt i en stabil version 1.2 och en utvecklingsversion 1.3 Milestone 5; den släpptes i mars Beskrivningen av databasen är baserad på dokumentation för 1.3M5[13, 14]. Neo4J klarar av stora mängder data med flera miljarder noder i en databas. Databasen Neo4J valdes för att modelleringsegenskaperna, ur ett teoretiskt perspektiv, var väldigt passande. Den stödjer även ACID egenskaperna fullt ut vilket är intressant för iipax. Neo4J valdes också för att den ofta nämns i samband med diskussioner om NoSQL, och denna rapport är till stor del en orientering i just det begreppet. Att databasen går att få tag på gratis och finns under öppen licens underlättar utvärderingen. 4.1 Modelleringsmöjligheter Datamodellen är alltid en graf. Grafens noder och kanter representerar dataobjekt och relationer. Det går att specificera relationers riktning som utgående, inkommande eller båda. Flera relationer kan vara av samma sort, exempelvis om två noder representerar personer och relationen är ett samtal mellan de två. Då går det att representera att de talat med varandra flera gånger genom flera relationer mellan de två personerna. Neo4Js starka modelleringsegenskaper är därför data med komplexa relationer. Egenskaperna för de två komponenterna modelleras schemalöst genom dataobjekten Node och Relationship. Där associeras en nyckel med ett värde. Nyckeln är en sträng och värdet är en Javaprimitiv, sträng eller en array av Javaprimitiver. Värdet står på många ställen som ett Object men den tar bara de tidigare givna datatyperna. Det tar exempelvis inte null som värde. Värdet 18

25 rapport 2011/8/11 22:20 page 19 # INDEX KAPITEL 4. NEO4J kan indexeras(se nedan) och användas för att hämta ut data genom frågor. 4.2 Index Neo4J stödjer indexering genom att köra Apache Lucene som en indexeringsmotor. När Lucene används som indexeringsmotor stödjer Neo4J full textindexering. Genom indexeringen går det att ställa frågor till databasen och slippa traversera genom hela grafen. Databasen kan frågas genom två metoder, query och get. Funktionen query matchar delsträngar och stödjer funktioner för att kunna ställa frågor som matchar en större mängd. Funktionalitet som query ärvt av Lucene är bland annat: Numeriska intervaller, sortering, sammansättning av frågor med nyckelordet AND och cachning av index för att kunna öka prestandan. Metoden get hämtar bara ut exakta matchningar. Index går att skapa på både noder och relationer. Om data uppdateras måste indexet uppdateras explicit av programmet. Förutom stöd att indexera text med hjälp av Lucene stödjer Neo4J indexering via tidstämplar. Det är bra utifall historiken för data är viktigt för applikationen. Indexeringstjänsten kommer i framtiden att bytas ut i Neo4J. Det finns ännu inte mycket information om den. 4.3 ACID Neo4J har ett fullt stöd för ACID när databasen kör på en nod. Operationer på databasen börjar med att öppna upp en transaktion för att sedan utför alla operationer i en try-finally konstruktion. Det sista i try-blocket är att flagga operationerna som färdiga. I finally satsen stängs transaktionen och om det inte är flaggat som ok kommer transaktionerna att återställas. Operationerna flaggas som ok med tx.success() som alltid måste vara den sista raden i första blocket. try-finally i Java fungerar på så sätt att första delen prövas att köras och oavsett om första blocket lyckas eller ej kommer finally delen att köras. Där mellan går det att fånga upp undantag som kastats. Så tx.finish() körs oavsett hur det går i första blocket. Därmed avslutas transaktionen och om transaktionerna inte är markerade som ok kommer databasen att återställa dem. Eftersom Neo4J låser data kommer låsningar att uppkomma. Det löser systemet genom att så kallad deadlock detection kommer att avbryta en transaktion och inte markeras som färdigt. Då kommer det som transaktionen åstadkommit återställas. APIet är i regel trådsäker om något annat inte specificeras. 4.4 Skalbarhet Det går att konfigurera Neo4j för hög tillgänglighet, Neo4j HA(High Availability). Systemet skalar då horisontellt i en så kallad read-mostly arkitektur. 19

26 rapport 2011/8/11 22:20 page 20 # NEO4J APIER KAPITEL 4. NEO4J Transaction tx = graphdb.begintx(); try {... //operationer... tx.success(); } finally { tx.finish(); } Figur 4.1: En kodsnutt som visar hur en typisk transaktion går till i Neo4Js Java API. Det kommer då att sätta upp en master-slave relation där slaves är kopior av noden. Systemet klarar av att balansera belastningen och kommer därför att kunna hantera högre trafik. Systemet är feltolerant och klarar hårdvarufel. Om noder skulle gå ner klarar systemet av att ta bort slavar eller om masternoden går ner klarar systemet av att välja en ny. Systemet blir stabilt för att det har en ZooKeeper [12] som koordinerar det. Databasen blir i den här konfigurationen eventuellt konsistent i sin data. Den släpper då sitt fulla stöd för ACID. Det enda kriteriet som inte uppfylls längre är C, konsistent data, resterande kriterier kommer fortfarande att stödjas. För version två av Neo4J planeras stöd för distribuerade grafer. Neo4J ska alltså bli en fullständigt distribuerad databas. 4.5 Neo4J APIer Det finns bibliotek till många olika språk som kopplar direkt till databasen. Till Neo4J finns det ingen lågnivå API som biblioteken kopplar igenom utan funktionerna går direkt till databasen. Innan version 1.2 av databasen kördes den alltid som inbäddad. Den inbäddade varianten kan köras från språk som bygger till JVM. Från version 1.2 kan Neo4J köras som självständig server och kommunikationen sker då via REST. Här beskrivs först den låga nivån för Java för att sedan gå vidare till en högre nivå med jo4neo som ordnar konverteringen mellan Java objekt och databasen automatiskt. Utvärderingen av Neo4J avser version 1.2 av systemet. Version 1.2 används för att det är den senaste stabila versionen. Med senaste koden avvecklas den nuvarande indexeringstjänsten för att ersättas av en ny. Biblioteket som används stödjer ännu bara den äldre, stabila, versionens indexeringstjänst. Till utvärderingen har biblioteket jo4neo, version 0.4.1, använts. Det är ett bibliotek för att översätta objekt till databasen. 20

27 rapport 2011/8/11 22:20 page 21 # NEO4J APIER KAPITEL 4. NEO4J Lågnivå API Neo4J har en API som ger möjlighet att söka noder på många olika sätt. Eftersom databasen är en graf går det självklart att traversera genom grafen. Det görs med en Traverser. Den går att specificera med många parametrar för att få den att traversera på det sätt som önskas. Traverser friends = node.traverse( Order.BREADTH_FIRST, StopEvaluator.END_OF_GRAPH, ReturnableEvaluator.ALL_BUT_START_NODE, MyRelationshipTypes.KNOWS, Direction.OUTGOING ); for ( Node friend : friends ) { //... } Figur 4.2: Exempel på traversering i Neo4J API Koden ovan skapar en Traverser som traverserar genom alla nätverk av vänner i grafen med bredden först sökning. Den skapade traverseringen stegas sedan igenom med hjälp av Javas for-each konstruktion. Där behandlas varje nod i tur och ordning. Grafen går även att traversera lokalt genom att hämta in alla noder som har en viss relation till en nod. node.getrelationships( RelationshipTypes.KNOWS, Direction.OUTGOING ); Figur 4.3: Exempel på att hämta ut de noder som är kopplade med relationstypen KNOWS. I exemplet hämtas alla noder som är kopplade till noden node genom relationen KNOWS. Resultatet av metoden itereras precis som i föregående kodexempel. Som tidigare nämnts stödjer Neo4J indexeringen. Indexeringen kan frågas genom metoderna get och query på följande vis: roles.get( "name", "Persephone" ).getsingle(); movies.query( "title:*matrix* AND year:1999" ); Figur 4.4: Exempel på de två varianterna att hämta ut data ur indexet. I ovanstående exempel är skillnaden mellan de två olika metoderna att get matchar attributen name exakt medan query matchar med asterisker, 21

28 rapport 2011/8/11 22:20 page 22 # NEO4J APIER KAPITEL 4. NEO4J som matchar godtycklig sträng, och AND som sätter samman två frågor. I likhet med SQL. APIet är designat som ett vanligt objektorienterat bibliotek som kan anses som intuitiv för en van programmerare. Det är bra dokumenterat med Javadoc. APIet består inte bara av metoder för att hämta ut noder. Utan det finns även stöd för att använda olika grafalgoritmer för att hitta kortaste vägen och liknande. Förutom metoder för att behandla grafen finns det metoder för att bygga in Neo4J i en applikation Högnivå API: jo4neo Jo4neo är ett projekt på googlecode som är öppen källkod(gnu GPL v3). Anledningarna till att biblioteket valdes är att den är känd och har öppen källkod. Biblioteket Modellen har abstraherat bort grafen helt. Det finns bara klasser och relationer mellan dessa. En klass används som en nod i grafen genom att specificera en nods id-nummer. Detta id är unikt i databasen. Alla fält som ska associeras med en nod noteras Om det är en av de inbyggda datatyperna läggs det som ett fält i noden. Är det däremot en klass som också är en nod läggs en kant mellan dem och en relation är skapad bakom kulisserna. tar emot argument argument. De möjliga argumenten är index=true eller fulltext=true, belongs to eller inverse= belongs to, traverser och recency. public class Case extends DataNode = true) public String boolean private Collection<Document> diarium = new private Collection<Event> journal = new private Manager private Date creationdate; Figur 4.5: En klass som representerar ett ärende. 22

29 rapport 2011/8/11 22:20 page 23 # NEO4J APIER KAPITEL 4. NEO4J Ovan är ett exempel på hur biblioteket kan användas. Exemplet är en modell av ett ärende. Case ärver bara id från DataNode i exemplet. Med Jo4neo behövs bara vanlig objektorienterad programmering. Det enda extra är att variablerna ska noteras. Första variabeln indexeras i sin helhet. Det går därmed bara att söka på en exakt match. Skulle istället fulltext specificeras skulle delar av texten i variablen kunna matchas. Men i och med att det bara är ett namn väljs den första varianten. Den andra variabeln sparas bara ner i databasen i sin helhet, det blir bara ett attribut i noden. Den tredje variabeln är en relation till flera instanser av dokument. Notationen betyder att relationen mellan de två noderna döps till belongs to. Fjärde variabeln journal är även den en relation, skillnaden här är att inget namn specificeras på relationen men relationerna kommer att indexeras efter när de lades till. Databasen håller därmed reda på en tidslinje. De två sista repeterar bara nämnd funktionalitet. För att söka i indexet används raden i figur 4.6. Collection<Case> docs = graphdb.find(cas_ins).where(cas_ins.name).is("xfile x4152").results(); Figur 4.6: En sökning bland noder i jo4neo. Ovan söker databasen efter alla noder av typen Case genom variabeln cas ins som är en instans av klassen. Därefter specificeras vilken variabel indexet ska matcha mot. Den ska då matcha mot strängen xfile x4152. Indexet kommer bara att matcha exakt då bara index specificerades i??. Jo4neo hanterar mängder med hjälp av Collection. name är public för att den ska gå att komma åt ifrån sökningen. Sökningen ändrar i instansen som används; det kan därför vara bra att ta för vana att skapa en ny instans av klassen vid sökningarna. Det går att skapa egna traverserare för att kunna gå igenom data som önskas. Det är inget som visas i något av exemplen men det specificeras med som tar en traverserarklass som argument. När traverserare används släpps programmeraren ner på den lägre nivån när traverserarklassen skapas. Därefter är det bara som att gå igenom en Collection med en for-each sats. Det kan vara bra att namnge relationer när traverserare ska skapas. Det finns en notation som Den lägger inte en relation mellan dem utan serialiserar det annoterade objektet och lägger in de i noden. I bakgrunden jobbar Javas serialisering och gör om objektet till en byte array. APIet döljer uppdateringen av index. I APIet på lägre nivå måste det göras explicit. 23

30 rapport 2011/8/11 22:20 page 24 # NEO4J APIER KAPITEL 4. NEO4J Dokumentation Mindre bra är att det inte finns speciellt mycket om detta bibliotek på internet. Dokumentationen är dålig och det finns inte mycket om den på bloggar och liknande. Det kan vara svårt att hitta lösningar på sina problem, för att APIet har lite inbyggd funktionalitet. Attribut går inte att sätta på relationer med APIet. Alla klasser som skapas blir till noder, därav blir alla skapade attribut sparade i noder. Det kan kännas önskvärt att göra speciellt i många-till-många relationer. Att attributen ligger i relationerna kan medföra en naturligare representation Externa verktyg Det finns en plugin till utvecklingsmiljön eclipse som visualiserar den skapade databasen och dess data. Pluginen heter neoclipse och utvecklas av Neo Technology. Den kan användas för att se på data visualiserat som en graf som går att vrida och flytta runt. Det går även att utföra diverse administrativa uppgifter. Även ett webbaserat administrationsverktyg släpptes i och med Neo4J 1.3. Det har utöver administration av data en visualisering av grafer Utvärdering av API Den låga nivån som den inbäddade versionen har känts väldigt naturlig men saknar mycket funktionalitet. Den är helt enkelt på en för låg nivå för att kunna bygga större program på. Javadoc håller en hög standard. Jo4neo har ett väldigt koncist API där det i princip går att lägga till, hämta ut, söka och ta bort. Detta är det mesta ett program normalt behöver. Den ser ut att vara ett bra alternativ för iipax. Intrycket är att detta system klarar bra av att spara ner objekt i sin naturliga form. Relationer är något det finns gott om i ärendehantering och det klarar den bra. Ett fall som idag ses som svårt i iipax är att söka i delar av strukturer. Med en specialbyggd traversering ska det fallet klaras bra i Neo. 24

31 rapport 2011/8/11 22:20 page 25 #33 Kapitel 5 CouchDB CouchDB är en dokumentdatabas som är släppt under öppen licens och är släppt i version 1.0.1[15]. Databasen är skriven i Erlang. Dokumenten i databasen är lagrat i JSON(JavaScript Object Notation) format och frågespråket är javascript. Det finns möjlighet att skapa frågor i andra språk men javascript är det vanligaste i den information som finns på internet. Frågor designas efter map/reduce och databasen skalar bra. Kommunikationen med CouchDB sker via HTTP och är designad med webben i åtanke. CouchDB har valts för att det är en databas som är släppt under öppen licens och är en databas som ofta nämns i NoSQL sammanhang. Det ser även ut att vara en typisk dokumentdatabas och kan ses som en bra representant för den typen av NoSQL databaser. Den schemalösa designen hos dokumenten ser ut att kunna lösa några av problemen som ObjectBase har. CouchDB har många avancerade funktioner som kan vara värda en närmare undersökning för användning i iipax. 5.1 Modelleringsmöjligheter CouchDB är schemalös vilket leder till att designen av databasen är fri och kan ändras när som helst, även då systemet körs. Det finns inga begränsningar på antalet fält i ett dokument eller fältens storlek. I fälten kan det lagras väldigt många olika typer av data eftersom det lagras i JSON format. Det är JSON som sätter begränsningarna. Det går därför att nästla objekt och göra arrayer. Om inte JSON skulle räcka till finns möjlighet till att lagra BLOB i CouchDB. Det finns även möjlighet till att bifoga filer till ett dokument(eng attachments). Poängen med dessa är att det går att ladda in deras metadata utan att ladda in filerna själva. I CouchDB finns det så kallade designdokument. Ett designdokument är precis som alla andra entiteter i databasen ett dokument. Designdokument har namnkonventionen design/[namn]. Ett designdokument har som de andra entiteterna ett id och revisionsnummer. Därefter kan det specifice- 25

32 rapport 2011/8/11 22:20 page 26 # ACID KAPITEL 5. COUCHDB ras en hel del funktioner som kan anropas och annat till exempel metadata för de bifogade filerna, vyer, visnings funktioner och valideringsfunktioner. De bifogade filerna i ett designdokument kan vara alla typer av kod och bilder som ska användas i funktioner. Det är bra för att slippa utveckla allt i JSON dokument. Vyer specificeras genom ett namn och ett nästlat objekt. Objektet har fälten map och reduce där reduce är valfritt. Alla dessa namn resulterar i adressen till RESTanropet. Exempelvis: Där all är namnet på vyn och design/manager är namnet på designdokument. Shows är en transformation av uthämtad data. Det kan vara väldigt bra för att slippa lagra exempelvis HTML- eller XML-mallar explicit. När databasen kan skicka ut HTML ger det en fördel för sökmotorer som inte exekverar AJAX på hemsidor. Valideringen som kan specificeras i designdokumenten kan försäkra sig om att data håller en viss standard. Det kan vara som en åtgärd mot de fel som kan bli av den schemalösa datamodellen. Till en valideringsfunktion skickas alltid en parameter som innehåller roller och den användare som försöker utföra operationen. Valideringsfunktionerna kan därför hjälpa till att säkra databasen. 5.2 ACID En transaktion kan uppnå fullständigt stöd för ACID. Då flera transaktioner ingår i en uppdatering, bulkuppdatering, är stödet för ACID ej påslaget från början men kan specificeras så att ingen eller alla transaktioner genomförs. Under en transaktion låser aldrig CouchDB data utan använder sig av MVCC(Multi Version Concurency Control). Om två läsningar av samma data görs med avsikt att uppdatera data kommer bara den ena uppdateringen att gå igenom. För att en uppdatering ska gå igenom måste den ha ett uppdaterat revisionsnummer. I fallet då en uppdatering med utdaterat versionsnummer försöker uppdatera kommer CouchDB att returnera felkod 409 och ändringen sparas inte. Det är då upp till klienten att föröka lösa uppdateringen genom att hämta en ny kopia och försöka med uppdateringen igen. Så löser CouchDB problemet med förlorade uppdateringar. Trots att data inte blir låst ser en läsning samma data under hela tiden eftersom klienten som läser läser en kopia av data. 5.3 Skalbarhet CouchDB kan replikera data för att kunna bestå av flera synkroniserade databaser[16]; i ett distribuerat system kommer data att bli inkonsistent. 26

33 rapport 2011/8/11 22:20 page 27 # INDEX KAPITEL 5. COUCHDB Det löser CouchDB genom versionshantering. Versionshanteringen väljer deterministiskt en vinnare bland de olika versionerna. Det går att komma åt de andra versionerna utifall applikationen vill slå ihop flera versioner ända tills CouchDB utför en rensning av gammalt data och tar bort versioner som inte längre är aktuella. Det gör systemet under perioder då belastningen inte är hög. För en vy visas endast vinnaren bland versionerna. Det går att köra CouchDB i klusterkonfiguration med hjälp av ramverket Lounge. Det görs genom att sprida ut data på flera maskiner. Anrop till databasen sker genom en proxy som dirigerar anropen bland de olika delarna av databasen. När CouchDB körs i ovanstående konfigurationer gäller inte ACID utan BASE. Uppdateringar kommer att fortplanta sig genom noderna och uppnå konsistent data så småningom. I distribuerat läge uppnår alltså CouchDB A och P men inte C. CouchDBs klusterkonfiguration är väldigt speciell för att den kan kopiera upp databasen på flera olika noder som kan ha sin egen version och de synkroniseras automatiskt. Noderna behöver inte vara uppkopplade hela tiden utan kan gå offline och sen uppdateras allt automatiskt vid ett senare tillfälle. Det är något som idag används av molnlagringstjänsten UbuntuOne. CouchDB drar så pass lite resurser att den kan köras på nya smartphones. Det gör att molntjänsterna går bra att även köra på mobila enheter. 5.4 Index Dokumentdatabaser, som CouchDB är, är en variant av key/value databaser och därför har alla dokument en unik nyckel. Dokumenten lagras i en b- trädstruktur och har ett index där med. Det indexet kommer att uppdateras automatiskt. Vyer indexeras för att bli effektivare. Map/Reduce funktionerna för en vy går igenom alla dokument första gången för att vid senare anrop ha ett uppbyggt index. Det kan ses som så kallade thunks. Det är en konstruktion som bara evalueras första gången och sparar sedan ner resultatet. I CouchDB går det att fulltextindexera med Apache Lucene. Fulltextindexeringen är ett externt projekt och finns inte från i grunddatabasen. Eftersom APIerna är avancerade finns det utvecklare som skapat egna indexeringar med hjälp av det befintliga APIet. Vyer returnerar par av nyckel och ett värde. När CouchDB söker i en vy går det endast att göra så på nyckeln. Behandling av värdet sker i applikationslagret. Det går inte att använda sig av tecken för att matcha reguljära uttryck men det går att fråga efter intervaller av värden. För att skapa mer komplicerade frågor krävs det en smart design av map och reduce funktionerna. För mer avancerad sökfunktionalitet måste Lucene pluginen användas. 27

34 rapport 2011/8/11 22:20 page 28 # COUCHDB API KAPITEL 5. COUCHDB 5.5 CouchDB API Till utvärderingen av CouchDB har den senaste stabila versionen använts. Anledningen till versionsnumret är att när version 1.0 släpptes märktes snart en bugg som snabbt åtgärdades. APIet som använts är biblioteket Ektorp med versionsnummer 1.1.1[18]. Namnet Ektorp är lite av en ordlek från den svenska utvecklaren. Ektorp är en soffmodell från IKEA och CouchDB betyder soffa på engelska. Detta bibliotek mappar objekt till databasen men abstraherar även konstruktioner vyer och repositories Lågnivå JSON/javascript API CouchDB har ett RESTful HTTP-baserad[16] API. Enda vägen att kommunicera är genom GET, PUT, DELETE och POST metoder som innehåller Javascript-funktioner och data är strukturerat i JSON. { } "Subject": "I like Plankton" "Author": "Rusty" "PostedDate": "5/23/2006" "Tags": ["plankton", "baseball", "decisions"] "Body": "I decided today that I don t like baseball. I like plankton." Figur 5.1: Exempel på hur en bloggpost skulle kunna struktureras i CouchDB APIet. Måsvingarna, {}, används för att representera ett objekt och hakparenteserna, [], används för att representera en array. function(doc) { if(doc.age && doc.name) { emit(doc.age, doc.name); } } Figur 5.2: Exempel på en lagrad funktion som används vid förfrågning. Fälten age och name i figur 5.2 kontrolleras och emitteras ut ifall de passerar de specificerade kraven. Detta är map-funktionen i Map/Reducemodellen. Emitteringen plockas sedan upp av en reduce-funktion, om sådan finns, som sätter samman allt till ett slutgiltigt svar. Som tidigare nämnts klarar CouchDB av att modellera relationer med hjälp av att skapa funktioner enligt map/reduce-modellen. De skapas genom att lagra funktioner som tar in två dokument och matchar två värden. Det har stora likheter med ett SQLspråks JOIN funktion. 28

35 rapport 2011/8/11 22:20 page 29 # COUCHDB API KAPITEL 5. COUCHDB CouchDB har, som många relationsdatabaser, vyer. Vyer skapas även de med hjälp av map/reduce-modellen. En vy används precis som i SQL; som en förbestämd insamling av data som uppdateras med databasen. Designdokumenten har som tidigare nämnts en hel del funktioner som kan implementeras. De har ett specificerat gränssnitt för att det ska gå att kalla på dem. Namnen som används på parametrarna är vanliga i litteraturen [16]. En vy har funktionerna map och reduce. Map har som i koden ovan bara doc som parameter. Det är det dokumentet som behandlas. I map funktioner används emit(key, value) för att skicka delar av objekt vidare till reduce funktionen eller till resultatet direkt. key är den nyckel som representerar ett objekt och kan vara en primitiv eller en array. Det är även möjligt att filtrera svaren med ett krav på key i resultatet. value är de värden som ska associeras med nyckeln. Reduce har två eller tre parametrar; keys, values och eventuellt rereduce. keys är nyckeln som map funktionen emitterade och values kommer även därifrån. rereduce är en parameter som är sant eller falskt. Den har att göra med att CouchDB sparar resultat som den tidigare räknat ut i en förälder i b-trädet för att slippa räkna om något beräkningskrävande igen. Är rereduce falskt kommer CouchDB att använda det nersparade värdet och spara tid medans sant kommer att resultera i att den räknar om. Valideringsfunktionerna har newdoc, saveddoc och userctx. newdoc är det nya dokumentet som är på väg in i databasen medans saveddoc är den gamla versionen som finns på disk. Den är null om det inte finns någon tidigare version. userctx är användaren och dennes roller som kan användas för att se till att användaren har rättigheterna. Shows har doc och req. doc är som i mapfunktionen. Parametern req är en parameter som kan användas för att interaktivt lägga in värden. Det kan exempelvis vara att specificera ett namn som ska läggas in i HTML. Shows anropas genom URL till databasen och show/[namn]/[doc id]. Namnet är namnet på show funktionen och doc id är dokumentets id. Funktionerna går att kalla på utan att specificera dokument, men då gäller det att funktionen kan hantera det. För att kalla på en funktion och använda req används ett namngivet fält i req och specificera namnet på fältet i URLen vid anropet. Exempelvis req.name används i show funktionen och URLen ser ut som /mydb/ design/mydesign/ show/myshow?name=jonas. Det kan liknas vid en fråga till en vy Högnivå: Ektorp API APIet är komplext, består av vanlig objektorienterad programmering och avancerad användning av annotationer. Ektorp ger tillgång till flera abstraktionsnivåer. Det går från att behandla anrop som råa dataströmmar till en hög nivå då Java objekt kan mappas ner till databasen. Där mellan finns en hel del funktionalitet som ligger på olika nivåer. Eftersom Ektorp ger tillgång till många abstraktionsnivåer blir den flex- 29

36 rapport 2011/8/11 22:20 page 30 # COUCHDB API KAPITEL 5. COUCHDB ibel och det går att ändra på det mesta. Det går exempelvis att skapa en egen objektmappning och använda den med Ektorp. Standardkomponenterna fungerar bra, specialmappningen är inget en applikation behöver om det inte finns speciella behov. Objektmappningarna görs med hjälp av jackson JSON biblioteket. Den vanliga programmeringen är vad som kan väntas medan annotationerna är det mer speciella. De används för att exempelvis specificera hur data ska lagras, vilken sökväg anropet ska ha och funktioner i en vy; vyer bygger som bekant på map/reduce. Ett designdokument representeras i Ektorp som ett repository. Den ärver från klassen CouchDbRepositorySupport<T>som ger den grundläggande funktionaliteten hos en sådan klass. Det är med den som Vyer, Shows och Listor skapas med hjälp Ett repository har alltid till en början en funktion som listar alla dokument av en viss name = "complicated_view", file = name = "view_name", map = "function(doc) {...}", reduce = "function(doc) {...}") Figur 5.3: Exempel på vydeklarationer, översta från fil och den undre är skriven inline. Enkla vyer kan genereras med hjälp av List<Manager> list; ViewQuery vq = new ViewQuery().designDocId("_design/Manager").viewName("by_name").key(commands[2]); list = db.queryview(vq, Manager.class); Figur 5.4: Exempel på en fråga i Ektorp. Vyer går även att kalla på från ett existerande designdokument. I figur 5.4 är ett exempel på hur en extern vy i ett existerande designdokument kan kallas på. I figuren 5.4 så kallas det på ett tidigare definerat designdokument och en vy som är definerad i det. I figur 5.5 är ett exempel på deklarationen av en klass som ska mappas ner till dokument. Specificeringen av mappningen är genom Ektorp. Detta är ett exempel på används från Ektorp och den första notationen är där för att en vy som hämtar alla dokument ska kunna genereras. Fältet som är noterat kommer i den vyn vara nyckelvärdet. Den andra notationen är en referens mellan två klasser som kommer skötas automatiskt. Det går att specificera hur en relation ska fungera genom olika parametrar. I exemplet ovan 30

37 rapport 2011/8/11 22:20 page 31 # COUCHDB API KAPITEL 5. COUCHDB public class Case extends CouchDbDocument private String name; private boolean opened; private Date creationdate; private String = "case_name", fetch = FetchType.LAZY) private Set<Document> attachments; Figur 5.5: Ett exempel på en presisterad klass i Ektorp API har ett fält backreference, en parameter som måste specificeras, vilket är ett fält i den andra klassen som innehåller referens till klassen ovan. Den andra är en specificering om hur de refererade dokumenten ska hämtas. I fallet ovan är hämtningen lat och hämtas inte innan de behövs. En begränsning som nämns i [18] är att med ovan nämnda funktionalitet inte kan hantera många-till-många referenser. Klassen ärver från CouchDbDocument som är en mall för ett dokument. Den har den grundläggande funktionaliteten och fälten som id- och revisionsnummer. Indexering av data finns tillgängligt i ett externt projekt som integrerar projektet Lucene Externa verktyg Till CouchDB kommer ett administrationsverktyg i form av en webb applikation. Det går att utföra massor av administrativa saker. Det går att ta bort och lägga till databaser och dokument. Väldigt användbar när det gäller att lära sig CouchDB och för att utveckla och testa vyer. Verktyget heter Fulton och går när CouchDB är igång på port Utvärdering av CouchDB CouchDB har den absolut bästa communityn. Den finns mycket på bloggar och liknande. Det finns till och med en hel gratis bok på internet [16]. Lågnivå APIet består av JSON och javascript fungerar väldigt bra. Det är väldigt flexibelt och det finns många funktioner som om det utnyttjas rätt kan skapa en väldigt kraftfull databas. Den kan till och med ersätta mycket annan kod. Sökningarna är något begränsade när Lucene pluginen inte används. Det är ett väldigt annorlunda sätt att tänka på jämfört med SQL kan det ta tid att förstå hur allt fungerar. Det finns även en hel del funktionalitet i designdokumenten. Ektorps officiella dokumentation är bra. Den har bra Javadoc och en utförlig referensdokumentation. Men det finns inte så många exempel på 31

38 rapport 2011/8/11 22:20 page 32 # COUCHDB API KAPITEL 5. COUCHDB kod. APIet förekommer inte så ofta på bloggar och liknande vilket gör att det kan vara svårt att hitta lösningar på sina problem. Ektorp är beroende på flera andra bibliotek, det kan därför vara väldigt bekvämt att använda sig av exempelvis maven för att lösa beroenden. Maven är ett verkyg för att hantera Java projekt. Att ge sig i kast med CouchDB är väldigt lätt vid första anblick men visar sig vara väldigt svårt vid mer komplicerade tillämpningar. Att förstå sig på CouchDB på en låg nivå känns väldigt viktigt. Det känns lättare att skapa saker genom lågnivå och sedan kalla på dem genom Ektorp, för de gör den bra. 32

39 rapport 2011/8/11 22:20 page 33 #41 Kapitel 6 Cassandra Cassandra är enligt dem själva en strukturerad key/value databas, en blandning av Google Bigtable och Amazons Dynamo[17]. Cassandra skapades först av Facebook för deras inkorgsökning och släpptes som öppen källkod Systemet är skrivet i Java och släppt i version Cassandera är en stor aktör inom NoSQL och används av flera stora webbtjänster som Facebook, Digg och Twitter där den har gjort bra ifrån sig. Företaget DataStax står idag bakom Cassandra. Apache Cassandra är en databas som väldigt ofta nämns i NoSQL sammanhang. Cassandra har inte valts för att den ser ut att kunna lösa de problemen iipax har idag utan i ett rent orienterande syfte. Det kan mycket väl bli en databas som kan vara ett bra val för någon av iipax framtida funktioner. Med tanke på egenskaperna att kunna hantera stora mängder data och att Cassandra satsar hårt på D i ACID, att skriven data ska bestå, skulle det kunna vara ett väldigt bra alternativ för långtidslagring av data. Det finns ett flertal olika bibliotek som tillhandahåller ett abstraherat API. Kundera som är vald här har som mål att ha JPA helt implementerad. JPA är en standard för Java mellan objekt och databas. Den är framförallt avsedd för att fungera med SQL, därför kan övergången gå smidigt. Den har idag kommit en bra bit på vägen och är kompatibel med JPA 1.0. Det som är här näst att implementera är och pre- och postpersist. Ett API som i stor utsträckning, och mer ska komma, implementerar ett känt API är lättare att konvertera till. Det är just därför som Kundera har valts att undersökas lite närmare. 6.1 Modelleringsmöjligheter Strukturerna som finns i Cassandra är Kolumner, Superkolumner, Kolumnfamiljer och Superkolumnfamiljer. En kolumn är en tripplett bestående av namn, värde och en tidstämpel. Alla värden som är i en databas måste tillhöra en kolumn och en kolumn måste ha det nämnda formatet. Data i 33

40 rapport 2011/8/11 22:20 page 34 # MODELLERINGSMÖJLIGHETER KAPITEL 6. CASSANDRA en kolumn lagras binärt, därför går det att lagra vad som helst i fälten. Exempel på en kolumn kan vara figur 6.1. { } name: "Förnamn", value: "Jonas", timestamp: Figur 6.1: Ett exempel på en kolumn i Cassandra. I exemplet är namnet på värdet Förnamn, värdet är Jonas och tiden när den skapades är Superkolumner är en gruppering av kolumner. De är bestämda till dubbletter som består av namn och värde. En superkolumn kan gruppera godtyckligt många kolumner. Exempel på superkolumn i figur 6.2. { } name:"fullständigt namn", value:{ Förnamn: {name: "Förnamn", value:"jonas", timestamp:123567} Efternamn: {name: "Efternamn", value:"hesselryd", timestamp: } Mellanmanm: {name: "Mellannamn", value: "Karl", timestamp: } } Figur 6.2: En superkolumn i Cassandra. Superkolumnen är till för att lagra ett fullständigt namn som består av kolumnerna: Förnamn, Efternamn och Mellannamn. Vidare kan data struktureras i familjer. De kan antingen vara standardeller superkolumnfamiljer. De samlar flera kolumner respektive superkolumner på ett sätt som kan likna en HashMap. Exempel på en kolumnfamilj i figur 6.3. En familj kan lagra godtyckligt mycket data och är schemalösa. Nya familjer kan skapas medan databasen används. Nyckeln till de olika kolumnerna kommer att vara värdet. På samma sätt fungerar superkolumner förutom att entiteterna i familjen även kan vara superkolumner. I modelleringen av en databas är det bra att strukturera familjer efter hur data är tänkt att hämtas ut. I familjerna kommer det att gå snabbt att hämta ut data efter nyckel, eftersom det byggs upp index efter dem. Data i familjer sorteras efter värden i kolumnerna. Det är bra att göra eftersom 34

41 rapport 2011/8/11 22:20 page 35 # MODELLERINGSMÖJLIGHETER KAPITEL 6. CASSANDRA FörnamnSamling = { jonas: { name: "Förnamn", value: "Jonas", timestamp:"123567" }, adam: { name: "Förnamn", value: "Adam", timestamp:" " } } Figur 6.3: En kolumnfamilj i Cassandra. familjer kan liknas vid frågor och man vill oftast ha en viss ordning på data som kommer ut. Familjer lagras explicit i den ordning som specificerats och det går därför väldigt fort att hämta ut data för att de ligger seriellt på hårddisk. Alla strukturer kan ses som en fullständig denormalisering och leder till redundant data men det är väldigt effektivt. [default@twissandra] get User[ jsmith ]; => (column=age, value=3339, timestamp= ) => (column=first, value=4a6f686e, timestamp= ) => (column=last, value=536d697468, timestamp= ) Returned 3 results. Figur 6.4: Ett exempel på hur data kan hämtas ut genom den textbaserade klienten. Cassandra har även stöd för att specificera databaser genom yaml (yet another markup language). I filen Cassandra.yaml konfigureras hela systemet. Cassandra stödjer sedan senaste versionen, 0.7, map/reduce funktionalitet genom Hadoop. Det går då att skapa map/reduce funktioner för att hämta ut specifika delar av data utan att lagra det explicit som strukturerna (se Modelleringsmöjligheter) gör. Det viktigaste att inse med Cassandra är att strukturerna eller map/reduce funktionaliteten är det som kan liknas vid frågor i andra språk. Databasens struktur måste därför designas efter hur det är tänkt att data ska hämtas ut. Men det kommer inte att innebära allt för mycket jobb eftersom familjer är schemalösa och kan efter version 0.7 skapas medan databasen kör. 35

42 rapport 2011/8/11 22:20 page 36 # ACID KAPITEL 6. CASSANDRA 6.2 ACID Cassandra stödjer inte ACID utan går alltid efter BASE, en operation är dock atomär på en kopia. Data kan dock hållas konsistent genom inställningar. Inställningar för läs- och skrivoperationer går från att en eller ingen nod ska svara till att alla ska svara på begäran. Det vill säga läsoperationen väntar antingen på första bästa kopia att läsa från eller att vänta och jämföra från flera kopior. Med flera kopior går det att ta reda på vilken kopia som gäller. I fallet med skrivoperation behöver ingen kopia svara utan data läggs på kö för att skrivas. I den ena änden kommer operationer gå väldigt fort och systemet kommer att få bra responstid. För läsning måste minst en nod svara och för skrivning går det att göra ett asynkront anrop då inget svar behövs. Nackdelen med att ställa in systemet på det viset är att data kommer att riskera att bli inkonsistent. Uppdateringar kommer så småningom att fortplanta sig genom hela systemet. I den andra änden går det att ställa in att en operation behöver svar från samtliga noder för att kunna fortsätta. Det kommer att dra upp responstiden och om noder i ett kluster är otillgängliga kommer operationen att misslyckas. Där emellan finns att antalet noder ska uppnå quorum. Quorum kan väljas att antingen vara för hela systemet eller bara den lokala noden. Något som Cassandra stödjer är D i ACID. Databasen är designad för att data ska bestå. Det skrivs loggar vid varje operation och Cassandra stödjer väldigt avancerad replikering så att data aldrig ska gå förlorat. 6.3 Skalbarhet Cassandra körs idag på stora kluster på över 400 maskiner(digital Reasoning). Det är en av systemets starkaste punkter. Cassandra är feltolerant och klarar av att noder går ner. Det gör att kluster kan växa och krympa dynamiskt. I ett distribuerat läge satsar Cassandra på att uppfylla A och P fullt ut och har därför lite mindre konsistent data. Men det går att uppnå konsistent data med de olika alternativen för läs- och skrivoperationer. Systemet är uppbyggt som en DHT, distribuerad hash tabell, och adressrymden är cirkulär och är 128 bitar stor. En hashtabell är en stor tabell av nycklar och värden. Nyckeln fås genom att beräkna ett värde utifrån data med hjälp av en hashfunkton. Adresserna delas upp mellan de noder som finns i klustret. Ett kluster är decentraliserat och varje nod håller bara reda på de noder som kommer direkt före och efter med hänsyn till adresserna. Den decentraliserade arkitekturen gör att det inte finns någon ensam nod som kan dra ner ett helt kluster. När Cassandra delar ut data till de olika adresserna går det att välja om systemet ska välja adresser slumpmässigt eller seriellt. Ett slumpmässigt sätt kommer att balansera belastningen över noderna medan det seriella kommer att ge en något skev belastning. 36

43 rapport 2011/8/11 22:20 page 37 # INDEX KAPITEL 6. CASSANDRA 6.4 Index Cassandra är en form av key/value databas och har därför nycklar till alla sina värden som kan hämtas ut i konstant hastighet, O(1). I kluster får givetvis nätverkets begränsningar tas till hänsyn. Det går även att skapa index över mängder av data med familjer. Index byggs efter databasdesignen. Fulltextindexering i Cassandra använder sig av Lucene med en plugin som kallas Lucandra. Den har de funktioner som kan väntas av en sådan integration i övrigt. En förbättring av Lucandra är under utveckling och baseras på Solr. Det är ett indexeringsverktyg som bygger vidare på Lucene och har därmed mer funktionalitet. Pluginen kallas för Solandra. 6.5 API Cassandra har stöd för att kommunicera med många olika språk. Det är framför allt tack vare att den kommunicerar på låg nivå via Apache Thrift. Thrift är ett projekt för att kommunicera mellan olika språk och det finns stöd för en hel del språk. Vidare har Cassandra en textbaserad klient som kan utföra några grundläggande administrativa uppgifter. Till sist finns det flertalet projekt som kapslar in Thrift till en högnivå API. Det som är valt att undersöka närmare här är Kundera Cassandra-cli Cassandra har en textbaserad klient där användaren har tillgång till ett API som är på en låg nivå. Det liknar en vanlig textbaserad klient, som den för MySQL. Den kopplar upp mot en körande instans av Cassandra. Där är det möjligt att skapa nyckelrymder(eng. keyspaces) och behandla data. Dokumentationen är bristfällig. Även om dokumentationen kan anses vara bristfällig går det att komma långt med programmets hjälpfunktion. Kolumnfamiljer skapas som i figuren 6.5 och i deklareringen går det att specificera typen till super om det behövs. Därefter skapas kolumner implicit genom kommandot set Thrift Thrift används för att kommunicera med en Cassandradatabas ifrån ett externt språk, exempelvis Java. Thrift APIet är på väldigt låg nivå. Det är inte rekommenderat att bygga applikationer med Thirft API[17], utan det rekommenderas att välja ett högnivå bibliotek. Thrift kommunicerar med Cassandra genom egna nätverkssockets som kopplas till en klient. Genom klienten går det att utföra en hel del manipulering av data och inställningar i databasen. APIet är på ungefär samma nivå som den textbaserade klienten. 37

44 rapport 2011/8/11 22:20 page 38 # API KAPITEL 6. CASSANDRA connect localhost/9160; create keyspace ks1; use ks1; Authenticated to keyspace: ks1 create column family Manager with comparator = UTF8Type; [default@ks1] set Manager[ jhesselryd ][ name ] = Jonas ; Value inserted. [default@ks1] set Manager[ jhesselryd ][ surname ] = Hesselryd ; Value inserted. [default@ks1] get Manager[ jhesselryd ]; => (column=name, value=4a6f6e6173, timestamp= ) => (column=surname, value= c727964, timestamp= ) Figur 6.5: En session i cassandera-cli Kundera Kundera är som nämnt ett Java API för Cassandra och är kompatibel med JPA 1.0. Den ser till stor del ut som JPA men har några extra notationer för super kolumner, kolumnfamiljer och super kolumnfamiljer. Det använder sig av ="keyspace1", family = "Managers") public class Manager // row identifier String = " ") // override column-name String address; Figur 6.6: En entitet i Kundera API I exemplet figur 6.6 är en klass som kommer sparas ner i Cassandra. Det är bara ColumnFamily som är speciell för Kundera alla andra är från Javas Persistence API. I Kundera indexeras allt om annat inte specificeras. Indexeringen tillhandahålls med pluginen Lucandra i bakgrunden. När indexering inte önskas specificeras det Kundera är till och med tillräckligt kompatibelt för att den kan söka med hjälp av frågor som är ställda i SQL. 38

45 rapport 2011/8/11 22:20 page 39 # API KAPITEL 6. CASSANDRA Det finns inte tillgång till all funktionalitet som SQL har eftersom allt inte ännu är implementerat i Kundera Kommentarer på API Dokumentationen för många delar är bristfällig. Det är svårt att hitta information och den som finns är i många fall utdaterad. Det textbaserade administrationsverktyget som finns är dåligt dokumenterat men efter att ha spenderat tid med det och användning av hjälpkommandot så upptäcks mycket funktionalitet. Thrift APIn är på en väldigt låg nivå och saknar därför mycket av den funktionalitet som behövs för att ha i ett faktiskt projekt. Högnivå APIerna har bra idéer och kommer förmodligen att bli bra. Idag är de många gånger utdaterade och svåra att få igång. 39

46 rapport 2011/8/11 22:20 page 40 #48 Kapitel 7 Exempel Kapitlet tar upp och diskuterar hur en eventuell implementation skulle förverkligas. Det är framförallt de delar som visat sig passande vid utvärderingen av respektive databas som diskuteras. Det är till för att stärka slutsatserna och ge läsaren en större insikt i vad en implementation skulle innebära. Det som tas upp är kod och designmönster som finns för att lösa problemen. 7.1 Hierarkisk grafmodellering Följande stycke tar upp ett designmönster för att skapa hierarkiska strukturer i en grafdatabas. Exemplet kommer att modellera en förenklad version av ett ärende i en hierarkisk struktur och hur den kan traverseras. Det faller sig naturligt att representera en hierarkisk struktur som en graf. Ett exempel på hur det skulle kunna representeras i Neo4J är: Figur 7.1: Bild på grafrepresenation av ett förenklat ärende. 40