En utredning av NoSQL för iipax

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

 2011­06­08

Institutionen för datavetenskap

Examensarbete

En utredning av NoSQL för iipax

av

Jonas Hesselryd

LIU­IDA/LITH­EX­G—11/012­SE

2011­06­07

Handledare: Lena Strömbäck

Examinator: Lena Strömbäck

Sammanfattning

NoSQL ¨ar ett omtalat ¨amne just nu. Det finns mycket som talar f¨or att det ska l¨osa de problem relationsdatabaser lider av. Exempelvis on¨odigt resurskr¨avande system eller sv˚art att konvertera mellan olika format p˚a data. Att l¨osa dessa problem ¨ar n˚agot Ida Infront ¨ar intresserade av f¨or lagringen i deras ¨arendehanteringsplattform iipax. Uppgiften ¨ar att ta reda p˚a vad NoSQL-begreppet faktiskt inneb¨ar och utv¨ardera utvalda databaser mot Ida Infront och iipax krav. Problemet har angripits genom en litteraturstudie av NoSQL f¨or att sedan unders¨oka tre databaser: Neo4J, CouchDB och Cassandra. Implementationerna har unders¨okts f¨or att ge en b¨attre bild av vad NoSQL inneb¨ar i praktiken. Resultatet av arbetet ¨ar att NoSQL ¨ar ett v¨aldigt diffust begrepp d¨ar m˚anga ¨ar oense om vad som g¨aller. Det ¨ar n˚agra olika typer av databaser som r¨aknas till NoSQL men de i sig ¨ar ingen definition av begreppet. Olika typer som ofta n¨amns ¨ar dokument, graf och kolumndatabaser. N¨ar det kommer till de specifika databaserna ser de ut att ha sp¨annande egenskaper som kan passa iipax, till exempel bra datamodell eller st¨od f¨or fulltextindexering. Slutligen kan det s¨agas att Neo4J i dagsl¨aget ser ut som den b¨asta kandidaten f¨or lagringen i iipax.

Inneh˚

all

1 Inledning 1 1.1 Bakgrund . . . 1 1.2 Syfte . . . 2 1.3 Fr˚agest¨allning . . . 2 1.4 Kravbild . . . 2 1.5 Metod . . . 2 1.6 M˚algrupp . . . 3 2 Teori 4 2.1 Begrepp . . . 4 2.1.1 CAP-satsen . . . 4 2.1.2 ACID . . . 5 2.1.3 BASE . . . 5

2.1.4 Vertikal och Horisontell Skalning . . . 5

2.2 RDBMS . . . 6

2.3 NoSQL . . . 7

2.3.1 Allm¨ant . . . 8

2.3.2 Typer av NoSQL . . . 10

3 iipax 14 3.1 Arende och iipax . . . .¨ 14

3.2 ACID i iipax . . . 15

3.3 Arendemodell . . . .¨ 16

3.4 ObjectBase . . . 16

3.4.1 Modell f¨or ett ¨arende . . . 16

3.4.2 Funktionalitet . . . 17 4 Neo4J 18 4.1 Modelleringsm¨ojligheter . . . 18 4.2 Index . . . 19 4.3 ACID . . . 19 4.4 Skalbarhet . . . 19 4.5 Neo4J APIer . . . 20 4.5.1 L˚agniv˚a API . . . 21

INNEH˚ALL INNEH˚ALL

4.5.2 H¨ogniv˚a API: jo4neo . . . 22

4.5.3 Externa verktyg . . . 24

4.5.4 Utv¨ardering av API . . . 24

5 CouchDB 25 5.1 Modelleringsm¨ojligheter . . . 25 5.2 ACID . . . 26 5.3 Skalbarhet . . . 26 5.4 Index . . . 27 5.5 CouchDB API . . . 28

5.5.1 L˚agniv˚a JSON/javascript API . . . 28

5.5.2 H¨ogniv˚a: Ektorp API . . . 29

5.5.3 Externa verktyg . . . 31

5.5.4 Utv¨ardering av CouchDB . . . 31

6 Cassandra 33 6.1 Modelleringsm¨ojligheter . . . 33 6.2 ACID . . . 36 6.3 Skalbarhet . . . 36 6.4 Index . . . 37 6.5 API . . . 37 6.5.1 Cassandra-cli . . . 37 6.5.2 Thrift . . . 37 6.5.3 Kundera . . . 38 6.5.4 Kommentarer p˚a API . . . 39 7 Exempel 40 7.1 Hierarkisk grafmodellering . . . 40 7.2 Map/Reduce f¨or join . . . 42 7.2.1 Denormalisering . . . 42 7.2.2 Flera h¨amtningar . . . 43 7.2.3 Komplexa nycklar . . . 44 8 Analys 46 8.1 Diskussion . . . 46 8.1.1 NoSQL . . . 46 8.1.2 Neo4J . . . 47 8.1.3 CouchDB . . . 48 8.1.4 Cassandra . . . 49 8.1.5 Sammanfattning av diskussion . . . 50 9 Slutsats 52 9.1 Sammanfattning . . . 52 9.2 Framtida arbeten . . . 53

Kapitel 1

Inledning

“Choose your hammer wisely”

- Emil Eifrem, CEO of Neo Technology

1.1

Bakgrund

Behovet av att lagra data ¨okar hela tiden. F¨orutom att m¨angden data ¨okar blir data mer och mer komplex. De senaste 30 ˚aren har relationsdatabaser dominerat, men de passar inte f¨or all typ av lagring. Data som produceras ¨

ar inte alltid anpassad efter att sparas ner enligt relationsmodellen. F¨or un-gef¨ar tio ˚ar sedan visade sig relationsdatabaser inte alls r¨acka till f¨or vissa f¨oretag, de b¨orjade utveckla sin egen datalagring som fr˚angick relationsmo-dellen. Exempel p˚a f¨oretag som gjorde just detta ¨ar Google, Facebook och Amazon. Databaser som inte anv¨ander sig av den klassiska relationsmodellen g˚ar under den gemensamma ben¨amningen NoSQL (Not Only SQL). NoSQL myntades 1998 av Erik Evans, en av utvecklarna av NoSQL databasen Cas-sandra. Begreppet kastas runt v¨aldigt flitigt och inneb¨orden ¨ar diffus. Ida Infront vill ha en bild av vad NoSQL inneb¨ar idag och om det kan vara n˚agot f¨or deras egenutvecklade plattform iipax.

Ida Infronts iipax ¨ar en plattform f¨or ¨arende- och arkivhanteringssystem. ¨

Arende- och arkivhanteringssystem lagrar ofta komplex data som inte alltid passar att lagra i relationsdatabaser. Det ¨ar d¨arf¨or intressant att unders¨oka om det finns b¨attre alternativ att lagra data. Mer och mer ¨arendehantering sker idag elektroniskt och det ¨ar d¨arf¨or ¨aven intressant att unders¨oka skal-barhet hos NoSQL databaserna.

Idag lagras data med hj¨alp av en egenutvecklad modul f¨or mappning mel-lan objekt och relationsdatabas. NoSQL databaserna kommer att j¨amf¨oras direkt med iipax egna system som idag best˚ar av modulen ObjectBase och en relationsdatabas.

1.2. SYFTE KAPITEL 1. INLEDNING

1.2

Syfte

Syftet med rapporten ¨ar att utreda om NoSQL ¨ar ett b¨attre alternativ ¨an relationsdatabaser f¨or n˚agon del av iipax-plattformens datalagring. Proble-men som NoSQL ¨ar t¨ankt att l¨osa ¨ar modellering av komplicerade relationer och hantering av st¨orre datam¨angder. Utv¨arderingen av NoSQL ska f¨orst utv¨arderas teoretiskt p˚a en abstrakt niv˚a f¨or att successivt g˚a mot specifika implementationer som praktiskt ska utv¨arderas mot Ida Infronts intressen.

1.3

Fr˚

agest¨

allning

Vad inneb¨ar NoSQL?

Vilka egenskaper har NoSQL i f¨orh˚allande till relationsdatabaser? ¨

Ar NoSQL n˚agot som passar iipax b¨attre ¨an nuvarande lagring? - l¨oser den problemen med objekt till relationell mappning? - ¨ar det effektivare?

1.4

Kravbild

Kravbilden fr˚an Ida Infront ¨ar att de vill veta hur NoSQL databaser beter sig i j¨amf¨orelse med nuvarande lagring. J¨amf¨orelsen ska ge sammanst¨allning ¨

over vilka vinster och f¨orluster som en alternativ lagring skulle ge. Egenska-per som ska unders¨okas:

• Modelleringsm¨ojligheter • API/Fr˚agespr˚ak

• ACID-st¨od • Fritextindexering

1.5

Metod

Informationen samlades in genom s¨okning i bibliotekets artikels¨ok och p˚a Google. Det var videoklipp fr˚an f¨orel¨asningar, bloggar, tidnings- och veten-skapliga artiklar. De valdes med h¨ansyn till objektivitet.

Utifr˚an den information som samlats in valdes tre databaser ut f¨or att studeras n¨armare och utv¨arderas mot Ida Infronts krav. Information om databaserna samlades in genom litteraturstudie mot kravspecifikationen. D¨arefter testades databaserna praktiskt f¨or att f˚a en djupare insikt. Den praktiska biten innebar att pr¨ova att modellera saker som skulle kunna vara intressanta f¨or iipax.

1.6

M˚

algrupp

Rapporten riktar sig till de som har kunskap om datorer och programmering. Speciellt antas l¨asaren ha kunskap om relationsdatabaser och distribuerade system.

Kapitel 2

Teori

Kapitlet tar upp teori som ¨ar relevant f¨or rapporten. Inledande tas be-grepp som ¨ar kopplade till hela rapporten upp. Efter det diskuteras teo-ri om relationsdatabasers svagheter upp. Det ¨ar endast svagheterna som tas upp eftersom endast de som ¨ar relevanta f¨or rapporten. Efter det kom-mer ett avsnitt om begrepp som ofta tas upp i samband med NoSQL. Av-slutningsvis ges en ¨oversiktlig bild av fyra typer av datalagring: key/value, kolumn-orienterade, graf och dokument. De typerna ¨ar bra representanter f¨or NoSQL.

2.1

Begrepp

2.1.1

CAP-satsen

˚

Ar 2000 presenterade Eric Brewer CAP-satsen, den bevisades 2002 for-mellt av Gilbert och Lynch [1]. CAP st˚ar f¨or Consistency, Availability och Partition-tolerans. Consistency inneb¨ar att databasen ska visa samma da-ta vid alla tillf¨allen. Availability inneb¨ar att resursen ska finnas tillg¨anglig vid alla tillf¨allen. Partition-tolerant syftar p˚a att resursen kan delas upp p˚a flera olika maskiner. CAP-satsen s¨ager att endast tv˚a av dessa tre krav kan fullst¨andigt uppfyllas av ett distribuerat system. Satsen syftar p˚a ett allm¨ant distribuerat system men till¨ampas p˚a databaser eftersom vissa NoSQL da-tabaser ¨ar distribuerade system.

Beviset i [1] ¨ar att visa med mots¨agelse att ett partitionerat n¨atverk kan inte uppfylla b˚ade konsistent data och tillg¨anglighet fullt ut p˚a samma g˚ang. En sammanfattning av beviset ¨ar att det i ett asynkront n¨at finns minst tv˚a noder. Noderna har kopior av samma data. Antag att alla meddelanden som skickas i n¨atverket mellan noderna inte kommer fram. Om det d˚a utf¨ors en skrivoperation i en av noderna, kan om¨ojligt data bli konsistent i de olika noderna. Ska ist¨allet skrivoperationen f¨ors¨akra sig om att alla kopior av data ¨

Tillg¨angligheten kommer att f¨orsvinna i det givna scenariot eftersom noder-na vill f¨ors¨akra sig om att all data ¨ar lika innan n˚agon f˚ar l¨asa igen. Det kommer inte p˚a n˚agot s¨att att fungera enligt det givna scenariot.

2.1.2

ACID

ACID ¨ar krav som m˚aste uppfyllas av databastransaktioner. De fyra egen-skaperna som ing˚ar i ACID ¨ar Atomicity, Consistency, Isolation och Dura-bility. Med Atomicity menas att en transaktion ska genomf¨oras i sin helhet eller inte alls. Consistency kravet innehar att allas syn p˚a data ska vara den-samma vid alla tillf¨allen. Isolation betyder att en transaktion ska utf¨oras isolerat fr˚an yttre p˚averkan. Durability syftar p˚a att om en transaktion ¨ar utf¨ord ska den best˚a.

2.1.3

BASE

BASE st˚ar f¨or Basically Available Soft-state Eventually consistent som ¨ar ett alternativ till ACID. Kraven inneb¨ar att det alltid g˚ar att komma ˚at data men den beh¨over inte vara konsistent. Data blir dock eventuellt konsi-stent efter att uppdateringen n˚att alla noder i systemet. Uppdateringar sker oftast via s˚a kallade Gossip-protokoll. Med det menas, som namnet anty-der, att det skickas meddelanden mellan noderna f¨or att sprida de senaste uppdateringarna.

2.1.4

Vertikal och Horisontell Skalning

Skalning inneb¨ar att en resurs kan anv¨andas i ett st¨orre sammanhang. Med andra ord att k¨ora systemet i en st¨orre skala, d¨arav ordet. Ett systems mjuk-vara kan i sig mjuk-vara mer eller mindre skalbart beroende p˚a hur det hanterar en st¨orre trafik av data eller operationer. Det vill s¨aga mjukvarans komplexitet. Oavsett mjukvarans komplexitet kommer ett v¨axande system att beh¨ova mer ber¨akningskraft fr˚an h˚ardvaran. D¨ar talas det om vertikal eller horison-tell skalning. I ett system som skalar vertikalt m˚aste mjukvaran k¨oras p˚a en maskin och f¨or att skala upp h˚ardvaran m˚aste en starkare dator ers¨atta den f¨oreg˚aende.

G˚ar systemet ist¨allet att skala horisontellt g˚ar det att dela upp p˚a flera maskiner. Det kan l¨osas genom att systemet ¨ar decentraliserat och noderna klarar sig sj¨alva eller genom att det finns en ¨overordnad nod som sk¨oter kommunikationen. I detta fall g˚ar det att komplettera ett system med en extra dator, och beh˚alla de ¨aldre, f¨or att skala systemet. Det anses vara ett mer kostnadseffektivt system d˚a mycket billig h˚ardvara kan bli b¨attre ¨an ett dyrt system som endast best˚ar av en dator. Till skillnad fr˚an att det kallas skala upp i det vertikala fallet brukar det i det horisontella fallet talas om att skala ut.

2.2. RDBMS KAPITEL 2. TEORI

2.2

RDBMS

RDBMS(Relational Database Management System) skapades p˚a 70-talet. Sedan dess har h˚ardvaran ¨andrats enormt mycket medan systemen inte ¨

andrats lika mycket [2] . Relationsdatabaser ¨ar l˚angt ifr˚an utdaterade och s¨amre ¨an NoSQL p˚a alla punkter. Det finns applikationer som passar b¨ast i relationsdatabaser och kr¨aver allt som de har att erbjuda, de tv˚a komplet-terar varandra. Trots att det finns applikationer d¨ar relationsdatabaser ¨ar det absolut b¨asta alternativet, tas h¨ar bara nackdelarna med RDBMS upp. De svagheter som NoSQL ¨ar skapade f¨or att l¨osa.

Skalbarhet

RDBMS har designats f¨or att uppfylla C och A, och det leder till att de inte kan uppfylla P fullt ut enligt CAP-satsen. N¨ar inte P g¨aller m˚aste ett RDBMS skala upp vertikalt. Den vertikala skalningen kan bli kostsam h˚ardvarum¨assigt.

Databasernas fullst¨andiga ACID transaktioner medf¨or en hel del ber¨akningar. Det kan leda till en ineffektivitet(se nedan) f¨or system som inte kr¨aver all den funktionalitet som RDBMS erbjuder. I storskaliga system kommer den extra overheaden p˚a varje transaktion att g¨ora stor skillnad.

Effektivitet

RDBMS ¨ar ineffektiva i sina transaktioner f¨or att de l¨amnar m˚anga ga-rantier och f¨ors¨akrar att allt g˚ar r¨att till. Att systemen ¨ar f¨orsiktiga och f¨ors¨akrar sig om att allt g˚ar r¨att till ¨ar inget d˚aligt i sig. Det kan dock vara on¨odigt f¨or m˚anga applikationer. Det resulterar i att on¨odigt mycket kraft sl¨osas bort. Enligt [2] ¨ar det som tar tid i OLTP(Online Transaction Processing) f¨oljande fyra saker: bufferthantering, l˚as, underh˚all av delad da-tastruktur(latching) och loggar. Dessa tar mellan 10% och 35% var av den totala processtiden. Dessa olika delar kr¨avs f¨or att RDBMS ska kunna ga-rantera ACID egenskaperna. Om ett system tar bort ACID och d¨armed de fyra n¨amnda tidskr¨avande processer, kommer databasen att snabbas upp betydligt. Det var n˚agot som MySQL gjorde till en b¨orjan. De hade in-te fullt ACID st¨od men utvecklare anv¨ande den ¨and˚a f¨or att det inte var n¨odv¨andigt f¨or applikationen och det blev ett snabbare databassystem.

Relationsdatabaser ¨ar inte bara ineffektiva p˚a grund av den st¨orre overhe-aden som f¨oljer av ACID-transaktionerna. I och med att m˚anga av relations-databaserna grundar sig p˚a design fr˚an 70-talet har vissa designbeslut blivit f¨or˚aldrade [2]. Det l¨agger p˚a ¨annu mer overhead p˚a processerna. Trots att h˚ardvaran utvecklats explosionsartat de senaste 30 ˚aren har databassyste-men inte ¨andrats s˚a mycket som de skulle beh¨ovt. Det g¨or att systemen inte kan utnyttja den fulla potentialen hos dagens h˚ardvara. Ett vanligt scena-rio p˚a 70-talet, var ett stort datacenter med extremt l˚angsamma h˚ardiskar och lite RAM-minne. Designbeslut som togs d˚a, som idag ¨ar utdaterade,

¨

ar exempelvis effektiva datastrukturer f¨or f˚a diskaccesser och flitig multi-tr˚adning f¨or att systemet skulle kunna g¨ora annat i v¨antan p˚a de l˚angsamma h˚arddiskarna. Idag kan m˚anga databaser k¨oras direkt i RAM-minnet och allt g˚ar s˚a snabbt att multitr˚adning kan bli on¨odigt. Skulle dagens h˚ardvara ut-nyttjas fullt ut skulle RDBMS g˚a fortare ¨an vad de g¨or idag.

En Modell

RDBMS har i princip bara tabeller d¨ar all data lagras. Att lagra all sorts data i samma datamodell ¨ar inte alltid en bra id´e. Ett exempel ¨ar objek-torienterad data som inte passar relationsmodellen. Systemen m˚aste kom-pensera f¨or att fungera tillsammans. Det ¨ar ett problem som brukar kallas impendence mismatch problem [3]. Det blir en ineffektiv kombination. [3] beskriver fyra niv˚aer av problem som uppst˚ar. De ¨ar paradigm, spr˚ak, sche-ma och instans. Paradigm syftar p˚a problemen som uppst˚ar i kompabiliteten mellan tv˚a olika spr˚ak, exempelvis ett objektorienterat och SQL. De ¨ar olika spr˚ak-paradigm. Spr˚ak syftar till direkta implementation av spr˚ak och de skillnader som kan uppkomma d¨ar. Exempel d¨ar ¨ar Java och SQL. Det kan leda till sv˚arigheter i att utnyttja ett spr˚aks fulla potential. D¨ar kan det va-ra sv˚art att matcha datastrukturer hos de olika spr˚aken. Schemarelaterade problem ¨ar att underh˚alla tv˚a versioner av samma sak. Instans problemen ¨

ar de problemen som uppst˚ar vid h¨amtning av ett objekt i ett kontext. En mappning ner till relationsdatabas kan medf¨ora att objektet normaliseras ut p˚a flera tabeller som kommer att kr¨ava en insamlig av det fragmenterade data vid varje h¨amtning.

RDMBS har ett fast schema som m˚aste best¨ammas innan databasen s¨atts i bruk. Om databasen ska ¨andras m˚aste systemet tas ur bruk f¨or att g¨oras om. Det g¨or databasen jobbigare att underh˚alla. Det fasta schemat kommer att vara d˚aligt d˚a data ¨ar glest. Det vill s¨aga i ett fall d¨ar en data-modell har m˚anga f¨alt men det ¨ar inte ofta en stor del av f¨alten anv¨ands. Ett exempel kan vara anv¨andaruppgifter d¨ar inte m˚anga av f¨alten ¨ar ett krav. En relationsdatabas kommer att beh¨ova skapa ett f¨alt i sitt schema f¨or alla f¨alt oavsett om det anv¨ands eller inte. Minne kommer d˚a att allokeras utan att anv¨andas. Det kommer leda till d˚alig anv¨andning av lagringsutrymme. Problemen d˚a ¨ar inte bara ekonomiska utan p˚averkar ¨aven prestandan f¨or att databasen blir tvungen att flytta st¨orre m¨angd data som kanske inte anv¨ands.

2.3

NoSQL

NoSQL(Not Only SQL) ¨ar ett begrepp som anv¨ands p˚a allt fr˚an distri-buerade filsystem till informationslagrade grafer. NoSQL ¨ar enligt m˚anga ett f¨orvirrande begrepp. Det gemensamma ¨ar att det ¨ar datalagring som fr˚ang˚att relationsmodellen och det finns de som ist¨allet kallar det f¨or NRDB (Non Relational DataBase). De har g˚att ifr˚an den modellen f¨or att i de

fles-2.3. NOSQL KAPITEL 2. TEORI

ta fall f¨ors¨oka l¨osa dess problem i modern datalagring. Problemen som ska l¨osas ¨ar en representation n¨armare en applikations data och m¨ojlighet att k¨oras i enorm skala.

2.3.1

Allm¨

ant

NoSQL databaser skiljer sig v¨aldigt mycket och termen anv¨ands flitigt, det g¨or det sv˚art att s¨atta fingret p˚a vad som verkligen ¨ar en NoSQL-databas. Det finns n˚agra koncept som ˚aterkommer i m˚anga implementationer av NoSQL.

Ingen SQL

NoSQL har inget gemensamt spr˚ak som relationsdatabaserna har. Ett pro-gram som anv¨ander sig av NoSQL som lagring g˚ar genom egna APIer f¨or de olika databaserna. Det finns dock standarder som anv¨ands. Exempel p˚a s˚adant kan vara att n˚agra databaser anv¨ander sig av Apache Thrift, ett ram-verk f¨or att kommunicera mellan olika spr˚ak. Men det finns ¨aven exempel p˚a anpassade spr˚ak, exempel p˚a ett s˚adant ¨ar Gremlin som ¨ar ett spr˚ak f¨or grafdatabaser.

Quorum

Quorum ¨ar en metod som databaser utan ACID kan anv¨anvda f¨or att f¨orb¨attra hur konsistent dess data ¨ar. Det ¨ar n˚agot som bland annat im-plementerats i Amazons Dynamo [4]. Ordet kan ¨overs¨attas p˚a svenska till kvorum och inneb¨ar att man i en grupp m˚aste vara ett visst antal f¨or att kunna ta beslut. Ordet ¨ar taget fr˚an sammantr¨adesetik d¨ar det ofta m˚aste vara ett visst antal ledam¨oter p˚a plats f¨or att ett beslut ska kunna tas. N¨ar quorum implementeras i ett distribuerat system har de vanligtvis tre para-metrar: N, R och W. Det ¨ar de vanliga beteckningarna p˚a parametrarna i litteraturen[4, 6]. N st˚ar f¨or antalet kopior av data; R ¨ar hur m˚anga av ko-piorna som m˚aste vara med vid skrivtillf¨allet; W ¨ar hur m˚anga av kopiorna som m˚aste vara med vid l¨astillf¨allet. Dessa parametrar konfigureras f¨or att uppn˚a ¨onskat beteende hos systemet. L˚aga R och W i j¨amf¨orelse med N kan i st¨orre utstr¨ackning leda till inkonsistens. Det leder ¨aven till ett snabbare system f¨or att mindre antal resurser m˚aste vara med vid en operation. Att konfigurera i motsatt riktning ger motsatt effekt. En smart konfiguration n¨ar quorum anv¨ands ¨ar att f¨oljande ekvation ska g¨alla: R + W >N. G¨aller den kan inte en l¨asning och en skrivning ske samtidigt. Det kommer att leda till konsistent data i st¨orre utstr¨ackning.

Elastiskt system

En del av NoSQL databaserna har ett dynamiskt schema och klarar d¨arf¨or av att ¨andra p˚a sig utan att st¨anga ner systemet. Detta kallas f¨or ett elastiskt

system.

Det finns NoSQL databaser som ¨ar elastiska i sin skalning. Det betyder att nya maskiner kan l¨aggas till under drift och ta en del av belastning-en. Elastisk skalning fungerar endast i databaser som skalar horisontellt. Ett exempel p˚a en databas som klarar det ¨ar Dynamo[4]. Den har elastisk skalning genom att systemet best˚ar av virtuella noder d¨ar godtyckligt antal noder kan tillh¨ora en fysisk nod. Ett elastiskt system ¨ar bra ur ekonomi-och milj¨osynpunkt f¨or att antalet maskiner kan anpassas efter den aktuella belastningen utan att systemet beh¨over g˚a ner. N¨ar systemet bara beh¨over tillr¨ackligt med maskiner ig˚ang f¨or att m¨ota den aktuella belastningen kan maskiner st¨angas av och sparar d¨arf¨or energi.

Map/Reduce

Map/Reduce ¨ar en teknik som introducerades av Google[5]. Det ¨ar en pro-grammeringsteknik f¨or att distribuera ber¨akningar. Uttrycket kommer fr˚an den funktionella programmeringens funktioner map och reduce. Map/Reduce inneb¨ar att en uppgift delas upp och distribueras ut, map. D¨arefter samlas alla resultat ihop och skickas som ett svar, reduce. I m˚anga implementatio-ner ¨ar inte reduce steget n¨odv¨andigt utan map-funktionernas resultat blir resultat. Map/Reduce anv¨ands i centralstyrda distribuerade system som ex-empelvis filsystemen HDFS[11] och GFS[7].

Versionshantering

Versionshantering anv¨ands i n˚agra NoSQL databaser, [4, 7], f¨or att dels f¨orb¨attra responstiden men ¨aven f¨or att l¨osa problemet med en f¨orlorad uppdatering. Versionshantering sker genom att data tidst¨amplas.

Responstiden minskar och tillg¨angligheten ¨okar i ett system f¨or att sy-stemet aldrig beh¨over uppdatera data. Det g˚ar fortare att bara skriva dit en ny kopia ist¨allet f¨or att ta ut data, behandla det och sen skriva. Systemet kommer ¨aven att kunna erbjuda data utan att l˚asa den eftersom systemet kommer att kunna l¨osa konflikter i data och sl˚a samman olika versioner vid ett senare tillf¨alle. F¨or att inte allt f¨or m˚anga kopior ska kunna visas anv¨ander systemen sig av quorum. D˚a g˚ar det att f˚a systemet att visa flera versioner i v¨aldigt f˚a tillf¨allen [4]. Med versioner av systemet menas att data ¨

ar inkonsistent och systemet kommer d¨arf¨or att visa olika versioner av data. S˚a en anv¨andare kan se ouppdaterad data medan en annan ser uppdaterad. Det kan ¨aven uppst˚a vid flera l¨asningar av data samtidigt. Skillnaden mellan de tv˚a ¨ar att de l¨aser fr˚an olika kopior i systemet. Systemet kommer inte att spara hur m˚anga kopior som helst utan kommer vid ett senare tillf¨alle att rensa bland versionerna. Rensning av data sker antingen n¨ar en inaktuell version blivit f¨or gammal eller n¨ar en kvot av olika versioner passerats.

2.3. NOSQL KAPITEL 2. TEORI

2.3.2

Typer av NoSQL

NoSQL ¨ar en ben¨amning p˚a alla typer av databaser som inte anv¨ander den klassiska relationsmodellen. Det ¨ar d¨arf¨or ett v¨aldigt brett begrepp som anv¨ands f¨or att ben¨amna databaser som sinsemellan skiljer sig mycket. I litteraturen beskrivs m˚anga olika klassningar. De fyra vanligaste klasserna av NoSQL som beskrivs ¨ar kolumnorienterade, key/value, graf och dokument.

Key/Value

Key/Value ¨ar en typ av databas som associerar en datam¨angd med ett unikt nyckelv¨arde. Datam¨angden lagras som en BLOB det vill s¨aga ett Binary Large OBject d¨ar det inte finns n˚agon struktur som systemet kan anv¨anda sig av. M˚anga av systemen ¨ar baserade p˚a distribuerade hashtabeller(DHT). Exempel p˚a den h¨ar typen av databas ¨ar Amazons Dynamo [4]. Det ¨ar id´eerna bakom Dynamo som de allra flesta key/value databaser bygger p˚a. Databaserna erbjuder ofta en avskalad funktionalitet. Det kommer ge en snabbare databas med mycket flexibilitet. Nackdelarna som uppst˚ar i och med avsaknaden av funktionalitet ¨ar att mycket komplexitet l¨amnas upp till applikationslagret av ett system. Det ger h¨ogre kostnad i utvecklingen av ett system.

Funktionalitet som ofta finns i dessa system ¨ar att de ¨ar distribuerade, balanserar belastning, decentraliserade, saknat statiskt schema och eventu-ellt blir konsistenta i data. Funktionaliteten hos ett system varierar givetvis. Detta ¨ar dock de vanligaste funktionerna som finns. Egenskaper i ett system ¨

ar oftast en ¨overv¨agning mellan de bra och de s¨amre som f¨oljer.

N¨ar ett NoSQL-system ¨ar distribuerat ¨ar det viktigt att beh˚alla CAP-satsens P. Det g¨or att systemets designer m˚aste v¨alja mellan C och A. Det finns varianter av key/value databaser som st¨odjer b˚ada avv¨agningarna. Dy-namo ¨ar en databas som har valt att g˚a i riktningen mot h¨og tillg¨anglighet, A. Medan exempelvis Scalaris har valt att data ska vara konsistent ist¨allet. F¨orenklat kan implementationen, i de tv˚a n¨amnda fallen, av de olika varian-terna f¨orklaras med att Quorum-algoritmen ¨ar implementerad p˚a olika vis. I fallet med att ha h¨og tillg¨anglighet kr¨avs endast ett litet antal av kopi-orna f¨or att utf¨ora en operation. I det andra fallet kr¨aver en operation en majoritet av noderna.

Belastningen balanseras genom att distribueringen av nycklarna ¨ar j¨amn ¨

over de m¨ojliga nyckelv¨ardena. S˚a ist¨allet f¨or att b¨orja p˚a nyckel nummer ett och forts¨atta upp˚at v¨aljs nycklar f¨or att f˚a en j¨amn distribution ¨over de m¨ojliga nycklarna. Om systemet b¨orjar med nummer ett och stegar upp˚at kommer all data hamna p˚a den f¨orsta servern till att b¨orja med. D˚a kommer de andra servrarna vara oanv¨anda och on¨odiga tills de andra servrarna ¨ar fyllda. Det blir ineffektiv anv¨andning av h˚ardvara d˚a en server kommer vara ¨

overbelastad medan de andra ¨ar inaktiva.

Nyttan med att ha ett decentraliserat system som inte har ett statiskt schema ¨ar att det klarar mycket under drift. Att det saknar ett statiskt

schema g¨or att det g˚ar att ¨andra p˚a strukturen i data under drift. Det ¨

ar flexibelt men det inneb¨ar att det ¨ar n˚agot som m˚aste tas h¨ansyn till i applikationslagret. Den extra h¨ansyn som m˚aste tas av applikationen ¨ar kontrollering av data. Applikationer har i de flesta fall begr¨ansningar i vilken data den kan hantera. Den decentraliserade arkitekturen inneb¨ar ¨aven att systemet klarar av att noder l¨aggs till eller tas bort. Nackdelen med att ha den ovan beskrivna arkitekturen ¨ar att data vid vissa tillf¨allen kommer att vara inkonsistent. Inkonsistensen kommer eventuellt att l¨osas genom att noder pratar med varandra genom gossip-protokoll. En annan l¨osning p˚a inkonsistens mellan skriven data kan systemet l¨osa genom versionshantering. Det som databasen f¨orst skapades f¨or var e-handel, m˚anga l¨asningar och h¨og tillg¨anglighet. Data i applikationen ska ha mycket l¨asning men desto f¨arre skrivningar. Databaserna g˚ar att skala till v¨aldigt stora m¨angder data och fortfarande ha bra prestanda.

Kolumnorienterade

Kolumnorienterade databaser lagrar data efter rader och kolumner. Rader-na har alla en unik nyckel, precis som key/value databaserRader-na, som identifi-erar data. Ut¨over rader har den kolumnorienterade modellen kolumner som hj¨alper till att strukturera data. Kolumnerna grupperas sedan in i kolumn-familjer. Exempel p˚a kolumnorienterade databaser ¨ar Googles Bigtable[7] och Cassandra[6].

Implementationen av kolumnorienterade databaser kan p˚a m˚anga s¨att likna key/value databaserna. Den direkta skillnaden ¨ar att data struktureras med hj¨alp av kolumnerna. Den h¨ar typen av databaser ¨ar i regel distribuerad vilket ger systemet ett val mellan CAP-satsens C och A.

Semistruktureringen ¨ar bra f¨or eventuell indexering. Eftersom kolumner kan klassificeras hierarkiskt i kolumnfamiljer som passar bra till indexering ¨

ar de ofta strukturerade p˚a ungef¨ar samma vis.

Kritiken kolumnorienterade databaser kan f˚a ¨ar att APIerna har en v¨aldigt l˚ag abstraktionsniv˚a. Ett typiskt API har endast ett litet antal funk-tioner. Exempelvis Cassandra har bara tre funktioner insert, get och delete. Det l¨amnar mycket upp till utvecklaren av applikationen. Eftersom data en-dast ¨ar semistrukturerat kommer den inte att hantera komplex data speciellt bra. Vid komplex data m˚aste applikationen ta hand om komplexiteten den medf¨or.

Denna typ av databas ¨ar bra att anv¨anda f¨or lagring av stora m¨angder data som ska grupperas. Praktiska exempel ¨ar f¨oretag som skapat den h¨ar typen av databaser, Google och Facebook. Google anv¨ander kolumnfamil-jer f¨or att gruppera sidor som har l¨ankar till samma sidor. I Facebooks inkorgs¨okning d¨ar Cassandra anv¨ands klassas meddelanden med samma anv¨andar-id i samma kolumn och meddelanden som best˚ar av samma ord i samma super kolumn. Det ger mer strukturerad data som blir l¨attare att indexera och s¨oka i, det ¨ar viktigt f¨or b˚ada Facebook och Google.

2.3. NOSQL KAPITEL 2. TEORI

Graf

Grafdatabaser best˚ar i huvudsak av tre komponenter: nod, kant och egen-skaper. Noden ¨ar representationen f¨or ett objekt och kanten ¨ar en rela-tion till en annan nod. Egenskaperna ¨ar den data som lagras i en nod eller kant. Grafrepresentationen har en stabil matematisk grund och har d¨arf¨or v¨alutvecklade algoritmer. Algoritmerna ¨ar v¨aldigt snabba och arbetar lokalt. Den stora prestandavinsten j¨amf¨ort med relationsdatabaser kommer n¨ar en s¨okning i relaterat data g¨ors. Grafdatabasen beh¨over endast f¨olja en rela-tion medan relarela-tionsdatabasen beh¨over s¨oka bland olika tabeller eller g¨ora kostsamma joinoperationer med sig sj¨alv. En nackdel med grafdatabasernas s¨okning ¨ar att den m˚aste s¨oka genom hela grafen f¨or att ge ett definitivt svar. S¨okningen kan d˚a ta on¨odigt l˚ang tid om svaret endast finns i en liten del av grafen. Detta g˚ar att ˚atg¨arda med ett index motsvarande som f¨or relationsdatabaser.

Grafdatabaser traverserar data med procedurer. Ett exempel p˚a en fr˚aga ¨

ar att h¨amta alla som exempelvis uppfyller att vara granne med en annan nod. Sedan m˚aste programmet explicit g˚a igenom alla svar det f˚att. Det ¨ar allts˚a en l˚ag abstraktion p˚a fr˚agespr˚aket. Som n¨amnts ovan ¨ar en negativ del av grafdatabaser att de m˚aste s¨oka genom hela grafen f¨or att f˚a svar p˚a nya fr˚agor. Men det g˚ar att snabba upp fr˚agor genom att bygga upp index ¨

over noder och dess egenskaper. Det ger resultatet att databasen klarar semistrukturerad data bra men strukturerad s¨amre. Relationsdatabaser har ett v¨aldigt mycket krav p˚a struktur och kan anv¨anda den p˚a ett bra s¨att. Grafdatabaserna ¨ar s¨amre f¨or att de inte har det kravet och kan d¨armed inte utnyttja strukturen.

F¨orutom att grafdatabaser ¨ar bra p˚a att representera semistrukturerad data ¨ar deras starkaste sida att representera relationer[8]. Det i och med att varje kant mellan tv˚a noder ¨ar en relation. Det blir d¨arf¨or v¨aldigt l¨att att fr˚aga efter noder med hj¨alp av relationer. Exempel p˚a en fr˚aga som skulle bli komplicerad i andra databastyper men l¨att i grafdatabaser ¨ar v¨anners v¨anner i ett socialt n¨atverk.

Databaser med grafrepresentation kommer att skala v¨aldigt bra p˚a en maskin. Ett system kan hantera v¨aldigt mycket data. Men skalbarheten be-gr¨ansas av att det ¨ar sv˚art att k¨ora ett system i kluster. Men det finns system som st¨odjer att k¨oras i kluster, exempelvis HypergraphDB. Det po-sitiva med att databaserna bara k¨ors p˚a en nod ¨ar att de kan st¨odja ACID fullt ut. Neo4J ¨ar en grafdatabas som st¨odjer ACID transaktioner fullt ut.

Typiska exempel p˚a anv¨andningsomr˚aden d¨ar grafdatabaser g¨or bra ifr˚an sig ¨ar d¨ar relationer ¨ar viktiga. Det kan vara exempelvis sociala n¨atverk eller kunskapsrepresentation i artificiell intelligens, d¨ar data naturligt ¨ar n¨atverk.

Dokument

Dokumentdatabaser ¨ar en key/value databas men d¨ar v¨ardet ¨ar ett doku-ment. Ett dokument ¨ar mer strukturerat ¨an v¨ardet i key/value databaser.

Dokument ¨ar schemal¨osa och kan designas hur som helst och n¨ar som helst. Dokumentet ¨ar i m˚anga fall lagrat som JSON(JavaScript Object Notation) en standard som strukturerar data[10], det ¨ar till skillnad mot key/value databaser som lagrar v¨ardet som en BLOB. Strukturen ¨ar fri och v¨aljer ut-vecklaren att l¨agga in struktur kommer databasen att kunna anv¨anda den f¨or h¨amtning av data.

Den fria strukturen medf¨or att det g˚ar att skapa entiteter i databasen som st¨ammer v¨al ¨overens med ett programs datastrukturer. Det kommer att vara bra f¨or m˚anga av de problem som uppst˚ar vid Object-Relational Impendence Mismatch problemet[3].

De l¨osa kraven p˚a struktur medf¨or ¨aven att dokumentdatabaser klarar av data som har ofullst¨andig och gles data. Det ¨ar f¨or att schemat i ett dokument ¨ar fritt och inte kommer att finnas med om det inte explicit skrivs. Det ¨ar bra f¨or att databasen kommer inte att sl¨osa utrymme p˚a tomma utrymmen som kan uppkomma i relationsdatabaser.

Dokumentdatabaser har goda m¨ojligheter att skala, databassystemen skalar horisontellt. Men precis som de andra typerna av databaser kom-mer databasen att beh¨ova v¨alja mellan att ha konsistent data eller att vara tillg¨anglig.

Bristen p˚a struktur och schema kommer att leda till att det inte g˚ar att standardisera ett fr˚agespr˚ak. Databassystemet kommer att g¨ora d˚aligt ifr˚an sig vid s¨okning i dokumenten. Att h¨amta data via nyckeln kommer fortfarande som i key/value databaserna att g˚a bra och snabbt. Men d˚a kommer behandlingen av dokumenten l¨amnas upp till programmet.

Den typiska applikationen d¨ar dokumentdatabaser kan anv¨andas ¨ar d¨ar det finns en struktur som ska anv¨andas men d¨ar olika delar av strukturen ofta saknas. Det kan vara personuppgifter d¨ar m˚anga av uppgifterna ¨ar valfria.

Val av databaser

De databaser som i kommande kapitel har valts f¨or att unders¨okas n¨armare ¨

ar Neo4J, CouchDB och Cassadra. Anledningen till att databaserna valts ¨

ar till stor del deras popularitet och det ¨ar f¨orslag som kommit upp vid dis-kussion med intressenter p˚a Ida Infront. De tre databaserna tillh¨or typerna graf-, dokument- och key/value databas i respektive ordning. Datbaserna har ¨aven valts f¨or att f˚a representanter fr˚an olika typer av NoSQL databaser f¨or att rapporten till stor del ska orientera i NoSQL. I valet av databaser fanns ¨aven en tanke p˚a att databasen med f¨ordel kunde vara ¨oppen k¨allkod.

¨

Oppen k¨allkod ¨ar bra f¨or att databaserna ¨ar l¨attillg¨angliga p˚a internet. Inte bara databaserna utan ¨aven information och dokumentation. Mer specifik motivering finns i inledningen till varje kapitel av respektive databas.

Kapitel 3

iipax

iipax ¨ar en plattform f¨or ¨arendehanteringssystem. Den har en generell modell av ett ¨arende f¨or att kunna till¨ampas p˚a m˚anga olika organisationers behov. I dag har iipax en relationsdatabas i grunden. Relationsdatabaser har ACID vilket ¨ar ett krav f¨or ¨arenden men lider av att den komplexa modellen f¨or ¨

arenden inte passar riktigt bra i tabellform. I kapitlet tas det upp varf¨or ¨

arenden beh¨over ACID och hur modellen f¨or ett ¨arende ser ut i stora drag.

3.1

Arende och iipax

¨

Ett ¨arende ¨ar en avgr¨ansad fr˚aga som tas upp f¨or behandling. ¨Arende ¨ar ett brett begrepp som kan vara allt fr˚an ans¨okan om byggnadslov till utredning av mord. ¨Arende som ord anv¨ands oftast tillsammans med statliga verk och f¨oretag men det finns inget som s¨ager att det m˚aste anv¨andas i det samman-hanget. Ett ¨arende har en typisk livscykel d¨ar det f¨orst ¨oppnas f¨or behand-ling f¨or att slutligen st¨angas. St¨angning inneb¨ar inte ett definitivt slut d˚a ett ¨

arende kan ¨oppnas p˚a nytt. ¨Arenden ¨ar normalt st¨angda men ¨oppnas ibland f¨or behandling. Anledningen till det ¨ar f¨or att ¨arendehanteringssystem oftast byggs f¨or f¨oretag och statliga verk. De har i de allra flesta fall lagkrav p˚a att h˚alla ett arkiv ¨over gamla ¨arenden. Mellan ¨oppnandet och st¨angningen av ett ¨arende ska det behandlas efter best¨amda steg som ¨ar olika f¨or olika ¨

arenden. Dessa steg kan naturligt representeras som en ¨andlig automat eller ett fl¨odesdiagram.

Ett exempel kan vara att en person ans¨oker om byggnadslov. Personen b¨orjar d˚a med att skicka in en ans¨okan till ett statligt verk. N¨ar ans¨okan d˚a kommer in till verket kommer det att dyka upp i en handl¨aggares inkorg. S¨ag d˚a att i kontrollen av uppgifterna saknas n˚agot. D˚a m˚aste ¨arendet mar-keras med att det ska kompletteras och en beg¨aran p˚a komplettering m˚aste skickas till den ber¨orda personen. Inkommer senare en komplettering kan behandlingen av ¨arendet forts¨atta. Antag d˚a att ett byggnadslov m˚aste ha uppgifter fr˚an ett annat statligt verk f¨or att kontrollera att marken inte ¨ar

naturreservat eller liknande. D˚a skickas beg¨aran till ett annat statligt verk om dessa uppgifter. N¨ar alla uppgifter inkommit kan handl¨aggaren v¨alja att avsl˚a eller godk¨anna ¨arendet och det st¨angs. Visar det sig bli ett avslag kan personen ¨overklaga och ¨arendet m˚aste ¨oppnas p˚a nytt. Vilket utfall det ¨an blir m˚aste f¨ormodligen det statliga verket spara ¨arendet i ett arkiv f¨or ett visst antal ˚ar fram˚at av lagkrav.

M˚anga av stegen kan automatiseras. Exempelvis kontroller och beg¨aran av uppgifter. Kanske ¨ar det till och med s˚a att det ¨oppnas ett ¨arende i ett annat statligt verk. D˚a skulle h¨amtningen av dessa uppgifter ske helt automatiskt. Alla dessa steg ¨ar ett tillst˚and i diagrammet och f¨orverkligas genom en programmerad modul.

P˚a iipax byggs system som kan hantera ¨arenden. Sj¨alvaste iipax har generella komponenter som anv¨ands i m˚anga olika typer av ¨arenden. ¨ Arende-hanteringssystem som bygger p˚a iipax kan ses som en realisering av tidigare n¨amnda automaten som representerar ett ¨arendes livscykel. Realiseringen ¨

ar ett grafiskt gr¨anssnitt f¨or handl¨aggare och programmerade moduler som automatiserar olika steg i livscykeln.

Ett ¨arende b¨orjar med att komma till inkorgen hos en ansvarig handl¨aggare. D¨arefter tar sig ¨arendet genom olika steg i automaten. Ett steg i automaten kan vara n˚agot som m˚aste g¨oras av handledare eller en beg¨aran p˚a ytterligare uppgifter fr˚an den ber¨orda, 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 ¨ar viktiga f¨or ¨arendehantering. Det kanske inte ¨ar ofta det uppst˚ar situationer d˚a de egenskaperna r¨addar den, men Murphys lag lyder: “Om n˚agot kan g˚a fel s˚a kommer det ocks˚a att g¨ora de”. G˚ar n˚agot fel i ett viktigt ¨arende kan det inneb¨ara stora negativa konsekvenser. H¨ar f¨oljer anledningar till varf¨or det ¨ar viktigt med de olika egenskaperna. Endast ett f˚atal fall ¨ar beskrivna, listan skulle f¨ormodligen kunna g¨oras l˚ang.

A, Atomicity, ¨ar viktigt f¨or att en behandling av ett ¨arende inte f˚ar bli halvgjort. Om exempelvis n˚agra av ett ¨arendes attribut ¨andras och behand-lingen sedan avbryts kan det leda till ov¨antade resultat om ingen ser ¨over ¨

arendet noga och ser att n˚agot inte st¨ammer. Det kanske inte heller syns om n˚agot har g˚att fel. En uppm¨arksam m¨anniska kan se om n˚agot har blivit tokigt, men fler och fler processer automatiseras av datorer som kanske inte l¨agger m¨arke till fel i kontexten.

C, Consistency, ¨ar viktigt i och med att flera ¨arenden kan ha samma k¨alla som resurs. Om tv˚a ¨arenden behandlas men olika data ses i de olika fallen kan det leda till olika beslut d¨ar de egentligen skulle bed¨omts lika. Blir n˚agot av besluten felaktiga har behandlingen av ¨arendet misslyckats.

I, Isolation, ¨ar ett m˚aste f¨or att ett ¨arendes behandling inte ska p˚averkas av n˚agot yttre. ¨Andras ett ¨arendes villkor under behandling kan det leda till

3.3. ¨ARENDEMODELL KAPITEL 3. IIPAX

ett felaktigt beslut.

D, Durability, en v¨aldigt viktig punkt f¨or att ett ¨arende som ¨ar be-handlat m˚aste f¨orbli s˚a. Det kan uppkomma on¨odiga tvister om ett ¨arende om n˚agon tror att ett ¨arende ¨ar behandlat. Behandlingen kan i det fallet ha f¨orsvunnit ur databasen av exempelvis en krash. Till exempel, om ett ¨arende om adress¨andring behandlas och sen f¨orsvinner det kommer personen som flyttat kommer inte att f˚a sin post.

3.3

Arendemodell

¨

Modellen f¨or ett ¨arende ¨ar komplex. Den best˚ar av m˚anga entiteter och de ¨

ar kopplade p˚a m˚anga olika s¨att.

F¨orst och fr¨amst finns det en entitet f¨or ett ¨arende. Ett ¨arende best˚ar av ett journalnummer som identifierar ¨arendet unikt. Till det finns en m¨arkning som visar vart ¨arendet ¨ar i sin livscykel, dvs. ¨oppen eller st¨angd. P˚a kan det finnas en massa attribut av m˚anga olika slag. Dessa attribut orsakar en gles datamodell som ¨ar ett av de problemen som relationsdatabaser har. Till varje ¨arende finns det r¨attigheter f¨or vem som f˚ar besluta om dem. D¨ar finns n¨asta stora entitet, handl¨aggare. Handl¨aggaren kan ing˚a i olika arbetsgrupper eller vara n˚agon form av administrat¨or, vilket ger komplexa relationer mellan grupper, handl¨aggare och administrat¨orer.

Varje ¨arende kan ha flera olika tillh¨orande dokument. De kan ha egna strukturer som kan bli komplexa. P˚a detta ska de tillh¨orande dokumenten diarief¨oras i n˚agon form av logg. Det ¨ar inte bara dokumenten som beh¨over loggas utan allt som g¨ors ska helst loggas f¨or att kunna sp˚ara hur ett ¨arende har behandlats.

Olika entiteter i hela systemet beskrivs av attribut och meta data. Dessa m˚aste indexeras f¨or att det ska vara m¨ojligt att s¨oka i systemet och g¨ora det anv¨andbart. En bra indexering ¨ar d¨arf¨or av stor vikt.

Som texten beskriver blir m˚anga av strukturer l¨att komplexa. Detta kan vid normalisering leda till v¨aldigt m˚anga tabeller vilket vid h¨amtning av data ger m˚anga join-operationer, vilket kan leda till ett l˚angsamt system.

3.4

ObjectBase

ObjectBase ¨ar Ida Infronts egna modul f¨or att spara ner objekt till databas. Den har f¨orutom lagringen av ¨arenden etc. en hel del extra funktionalitet som iipax drar nytta av.

3.4.1

Modell f¨

or ett ¨

arende

Datamodellen som ett ¨arende har i iipax kan liknas vid en mappstruktur. Den ¨ar hierarkisk och ut¨okas efter behov. Olika delar av det som ¨ar beskrivet i 3.3 blir till grenar i en tr¨adstruktur.

3.4.2

Funktionalitet

I ObjectBase finns det en hel del extra funktionalitet som iipax anv¨ander i samband med lagringen. Funktionaliteten ¨ar i m˚anga fall skriven i applika-tionslagret och inte i den underliggande databasen.

Validering ¨ar en viktig funktionalitet som ObjectBase erbjuder. Den ¨ar viktig av framf¨orallt tv˚a anledningar; att data ska h˚alla en viss standard och att det ska g˚a att kontrollera en anv¨andares r¨attigheter. Eftersom iipax ¨ar en v¨aldigt generell plattform f¨or ¨arendehantering kan de b˚ada n¨amnda fallen se ut p˚a v¨aldigt olika s¨att. D¨arf¨or blir det ¨aven ett krav att valideringen enkelt g˚ar att komplettera med en plugin.

I ett ¨arende ¨ar olika delar ibland starkt kopplade eller beroende av varandra. Det kan d¨arf¨or vara v¨aldigt praktiskt att ha tillg˚ang till att h¨andelser utl¨oses vid ¨andring p˚a exempelvis ett attribut. Ett enkelt exempel p˚a det kan vara en summa. Om en term ¨andras eller l¨aggs till ¨ar det praktiskt om programmet r¨aknar om summan automatiskt. H¨andelserna kan vara att andra, kopplade, delar kan uppdateras. Detta ¨ar n˚agot som ObjectBase har st¨od f¨or och ¨ar viktig funktionalitet f¨or iipax.

ObjectBase har st¨od f¨or versionshantering. Versionshantering ¨ar viktigt i ¨

arendehantering dels f¨or att kunna f¨olja en historik och dels f¨or att ˚aterst¨alla om n˚agot blir fel.

Fulltextindexeringen i iipax g¨ors med hj¨alp av projektet Apache Lucene. Det ¨ar viktigt f¨or att kunna g¨ora fulltexts¨okningar i databasen av ¨arenden.

Kapitel 4

Neo4J

Neo4J ¨ar en grafdatabas som ¨ar sl¨appt under fri licens f¨or privat bruk, men f¨or kommersiellt m˚aste licenser k¨opas. Den fria versionen ¨ar ¨oppen k¨allkod och byter vid version 1.3 till GNU GPL v3. F¨oretaget som st˚ar bakom Neo4J heter Neo Technologies och har sitt huvudkontor i Malm¨o. Databasen ¨ar skriven i Java och den ¨ar en av de mer k¨anda grafdatabaserna just nu. Neo4J ¨ar sl¨appt i en stabil version 1.2 och en utvecklingsversion 1.3 Milestone 5; den sl¨apptes i mars 2011. Beskrivningen av databasen ¨ar baserad p˚a dokumentation f¨or 1.3M5[13, 14]. Neo4J klarar av stora m¨angder data med flera miljarder noder i en databas.

Databasen Neo4J valdes f¨or att modelleringsegenskaperna, ur ett teore-tiskt perspektiv, var v¨aldigt passande. Den st¨odjer ¨aven ACID egenskaperna fullt ut vilket ¨ar intressant f¨or iipax. Neo4J valdes ocks˚a f¨or att den ofta n¨amns i samband med diskussioner om NoSQL, och denna rapport ¨ar till stor del en orientering i just det begreppet. Att databasen g˚ar att f˚a tag p˚a gratis och finns under ¨oppen licens underl¨attar utv¨arderingen.

4.1

Modelleringsm¨

ojligheter

Datamodellen ¨ar alltid en graf. Grafens noder och kanter representerar da-taobjekt och relationer. Det g˚ar att specificera relationers riktning som utg˚aende, inkommande eller b˚ada. Flera relationer kan vara av samma sort, exempelvis om tv˚a noder representerar personer och relationen ¨ar ett sam-tal mellan de tv˚a. D˚a g˚ar det att representera att de talat med varandra flera g˚anger genom flera relationer mellan de tv˚a personerna. Neo4Js starka modelleringsegenskaper ¨ar d¨arf¨or data med komplexa relationer. Egenska-perna f¨or de tv˚a komponenterna modelleras schemal¨ost genom dataobjek-ten Node och Relationship. D¨ar associeras en nyckel med ett v¨arde. Nyckeln ¨

ar en str¨ang och v¨ardet ¨ar en Javaprimitiv, str¨ang eller en array av Java-primitiver. V¨ardet st˚ar p˚a m˚anga st¨allen som ett Object men den tar bara de tidigare givna datatyperna. Det tar exempelvis inte null som v¨arde. V¨ardet

kan indexeras(se nedan) och anv¨andas f¨or att h¨amta ut data genom fr˚agor.

4.2

Index

Neo4J st¨odjer indexering genom att k¨ora Apache Lucene som en indexe-ringsmotor. N¨ar Lucene anv¨ands som indexeringsmotor st¨odjer Neo4J full textindexering. Genom indexeringen g˚ar det att st¨alla fr˚agor till databasen och slippa traversera genom hela grafen. Databasen kan fr˚agas genom tv˚a metoder, query och get. Funktionen query matchar delstr¨angar och st¨odjer funktioner f¨or att kunna st¨alla fr˚agor som matchar en st¨orre m¨angd. Funk-tionalitet som query ¨arvt av Lucene ¨ar bland annat: Numeriska intervaller, sortering, sammans¨attning av fr˚agor med nyckelordet “AND” och cachning av index f¨or att kunna ¨oka prestandan. Metoden get h¨amtar bara ut exakta matchningar. Index g˚ar att skapa p˚a b˚ade noder och relationer. Om data uppdateras m˚aste indexet uppdateras explicit av programmet.

F¨orutom st¨od att indexera text med hj¨alp av Lucene st¨odjer Neo4J in-dexering via tidst¨amplar. Det ¨ar bra utifall historiken f¨or data ¨ar viktigt f¨or applikationen. Indexeringstj¨ansten kommer i framtiden att bytas ut i Neo4J. Det finns ¨annu inte mycket information om den.

4.3

ACID

Neo4J har ett fullt st¨od f¨or ACID n¨ar databasen k¨or p˚a en nod. Operationer p˚a databasen b¨orjar med att ¨oppna upp en transaktion f¨or att sedan utf¨or alla operationer i en try-finally konstruktion. Det sista i try-blocket ¨ar att flagga operationerna som f¨ardiga. I finally satsen st¨angs transaktionen och om det inte ¨ar flaggat som ok kommer transaktionerna att ˚aterst¨allas. Ope-rationerna flaggas som ok med tx.success() som alltid m˚aste vara den sista raden i f¨orsta blocket. try-finally i Java fungerar p˚a s˚a s¨att att f¨orsta delen pr¨ovas att k¨oras och oavsett om f¨orsta blocket lyckas eller ej kommer finally delen att k¨oras. D¨ar mellan g˚ar det att f˚anga upp undantag som kastats. S˚a tx.finish() k¨ors oavsett hur det g˚ar i f¨orsta blocket. D¨armed avslutas transaktionen och om transaktionerna inte ¨ar markerade som ok kommer databasen att ˚aterst¨alla dem.

Eftersom Neo4J l˚aser data kommer l˚asningar att uppkomma. Det l¨oser systemet genom att s˚a kallad deadlock detection kommer att avbryta en transaktion och inte markeras som f¨ardigt. D˚a kommer det som transaktio-nen ˚astadkommit ˚aterst¨allas. APIet ¨ar i regel tr˚ads¨aker om n˚agot annat inte specificeras.

4.4

Skalbarhet

Det g˚ar att konfigurera Neo4j f¨or h¨og tillg¨anglighet, Neo4j HA(High Availa-bility). Systemet skalar d˚a horisontellt i en s˚a kallad read-mostly arkitektur.

4.5. 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˚ar till i Neo4Js Java API.

Det kommer d˚a att s¨atta upp en master-slave relation d¨ar slaves ¨ar kopior av noden. Systemet klarar av att balansera belastningen och kommer d¨arf¨or att kunna hantera h¨ogre trafik. Systemet ¨ar feltolerant och klarar h˚ardvarufel. Om noder skulle g˚a ner klarar systemet av att ta bort slavar eller om mas-ternoden g˚ar ner klarar systemet av att v¨alja en ny. Systemet blir stabilt f¨or att det har en ZooKeeper [12] som koordinerar det.

Databasen blir i den h¨ar konfigurationen eventuellt konsistent i sin data. Den sl¨apper d˚a sitt fulla st¨od f¨or ACID. Det enda kriteriet som inte uppfylls l¨angre ¨ar C, konsistent data, resterande kriterier kommer fortfarande att st¨odjas.

F¨or version tv˚a av Neo4J planeras st¨od f¨or distribuerade grafer. Neo4J ska allts˚a bli en fullst¨andigt distribuerad databas.

4.5

Neo4J APIer

Det finns bibliotek till m˚anga olika spr˚ak som kopplar direkt till databasen. Till Neo4J finns det ingen l˚agniv˚a API som biblioteken kopplar igenom utan funktionerna g˚ar direkt till databasen. Innan version 1.2 av databasen k¨ordes den alltid som inb¨addad. Den inb¨addade varianten kan k¨oras fr˚an spr˚ak som bygger till JVM. Fr˚an version 1.2 kan Neo4J k¨oras som sj¨alvst¨andig server och kommunikationen sker d˚a via REST. H¨ar beskrivs f¨orst den l˚aga niv˚an f¨or Java f¨or att sedan g˚a vidare till en h¨ogre niv˚a med jo4neo som ordnar konverteringen mellan Java objekt och databasen automatiskt.

Utv¨arderingen av Neo4J avser version 1.2 av systemet. Version 1.2 anv¨ands f¨or att det ¨ar den senaste stabila versionen. Med senaste koden avvecklas den nuvarande indexeringstj¨ansten f¨or att ers¨attas av en ny. Biblioteket som anv¨ands st¨odjer ¨annu bara den ¨aldre, stabila, versionens indexeringstj¨anst. Till utv¨arderingen har biblioteket jo4neo, version 0.4.1, anv¨ants. Det ¨ar ett bibliotek f¨or att ¨overs¨atta objekt till databasen.

4.5.1

L˚

agniv˚

a API

Neo4J har en API som ger m¨ojlighet att s¨oka noder p˚a m˚anga olika s¨att. Eftersom databasen ¨ar en graf g˚ar det sj¨alvklart att traversera genom grafen. Det g¨ors med en Traverser. Den g˚ar att specificera med m˚anga parametrar f¨or att f˚a den att traversera p˚a det s¨att som ¨onskas.

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˚a traversering i Neo4J API

Koden ovan skapar en Traverser som traverserar genom alla n¨atverk av v¨anner i grafen med bredden f¨orst s¨okning. Den skapade traverseringen ste-gas sedan igenom med hj¨alp av Javas for-each konstruktion. D¨ar behandlas varje nod i tur och ordning.

Grafen g˚ar ¨aven att traversera lokalt genom att h¨amta in alla noder som har en viss relation till en nod.

node.getRelationships( RelationshipTypes.KNOWS, Direction.OUTGOING );

Figur 4.3: Exempel p˚a att h¨amta ut de noder som ¨ar kopplade med relation-stypen KNOWS.

I exemplet h¨amtas alla noder som ¨ar kopplade till noden node genom relationen KNOWS. Resultatet av metoden itereras precis som i f¨oreg˚aende kodexempel.

Som tidigare n¨amnts st¨odjer Neo4J indexeringen. Indexeringen kan fr˚agas genom metoderna get och query p˚a f¨oljande vis:

roles.get( "name", "Persephone" ).getSingle(); movies.query( "title:*Matrix* AND year:1999" );

Figur 4.4: Exempel p˚a de tv˚a varianterna att h¨amta ut data ur indexet.

I ovanst˚aende exempel ¨ar skillnaden mellan de tv˚a olika metoderna att

4.5. NEO4J APIER KAPITEL 4. NEO4J

som matchar godtycklig str¨ang, och AND som s¨atter samman tv˚a fr˚agor. I likhet med SQL.

APIet ¨ar designat som ett vanligt objektorienterat bibliotek som kan anses som intuitiv f¨or en van programmerare. Det ¨ar bra dokumenterat med Javadoc. APIet best˚ar inte bara av metoder f¨or att h¨amta ut noder. Utan det finns ¨aven st¨od f¨or att anv¨anda olika grafalgoritmer f¨or att hitta kortaste v¨agen och liknande. F¨orutom metoder f¨or att behandla grafen finns det metoder f¨or att bygga in Neo4J i en applikation.

4.5.2

H¨

ogniv˚

a API: jo4neo

Jo4neo ¨ar ett projekt p˚a googlecode som ¨ar ¨oppen k¨allkod(GNU GPL v3). Anledningarna till att biblioteket valdes ¨ar att den ¨ar k¨and och har ¨oppen k¨allkod.

Biblioteket

Modellen har abstraherat bort grafen helt. Det finns bara klasser och rela-tioner mellan dessa. En klass anv¨ands som en nod i grafen genom att speci-ficera en nods id-nummer. Detta id ¨ar unikt i databasen. Alla f¨alt som ska associeras med en nod noteras med @neo. Om det ¨ar en av de inbyggda data-typerna l¨aggs det som ett f¨alt i noden. ¨Ar det d¨aremot en klass som ocks˚a ¨ar en nod l¨aggs en kant mellan dem och en relation ¨ar skapad bakom kulisser-na. Notationen @neo tar emot argument argument. De m¨ojliga argumenten ¨

ar index=true eller fulltext=true, “belongs to” eller inverse=“belongs to”, traverser och recency.

public class Case extends DataNode { @neo(index = true)

public String name; @neo

boolean opened; @neo("belongs_to")

private Collection<Document> diarium =

new LinkedList<Document>(); @neo(recency=true)

private Collection<Event> journal =

new LinkedList<Event>(); @neo("created_by")

private Manager creator; @neo

private Date creationDate;

Ovan ¨ar ett exempel p˚a hur biblioteket kan anv¨andas. Exemplet ¨ar en modell av ett ¨arende. Case ¨arver bara id fr˚an DataNode i exemplet. Med Jo4neo beh¨ovs bara vanlig objektorienterad programmering. Det enda extra ¨

ar att variablerna ska noteras. F¨orsta variabeln indexeras i sin helhet. Det g˚ar d¨armed bara att s¨oka p˚a en exakt match. Skulle ist¨allet fulltext specifi-ceras skulle delar av texten i variablen kunna matchas. Men i och med att det bara ¨ar ett namn v¨aljs den f¨orsta varianten. Den andra variabeln sparas bara ner i databasen i sin helhet, det blir bara ett attribut i noden. Den tredje variabeln ¨ar en relation till flera instanser av dokument. Notationen betyder att relationen mellan de tv˚a noderna d¨ops till belongs to . Fj¨arde variabeln journal ¨ar ¨aven den en relation, skillnaden h¨ar ¨ar att inget namn specificeras p˚a relationen men relationerna kommer att indexeras efter n¨ar de lades till. Databasen h˚aller d¨armed reda p˚a en tidslinje. De tv˚a sista re-peterar bara n¨amnd funktionalitet. F¨or att s¨oka i indexet anv¨ands 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¨okning bland noder i jo4neo.

Ovan s¨oker databasen efter alla noder av typen Case genom variabeln

cas ins som ¨ar en instans av klassen. D¨arefter specificeras vilken variabel indexet ska matcha mot. Den ska d˚a matcha mot str¨angen “xfile x4152”. Indexet kommer bara att matcha exakt d˚a bara index specificerades i ??. Jo4neo hanterar m¨angder med hj¨alp av Collection. name ¨ar public f¨or att den ska g˚a att komma ˚at ifr˚an s¨okningen. S¨okningen ¨andrar i instansen som anv¨ands; det kan d¨arf¨or vara bra att ta f¨or vana att skapa en ny instans av klassen vid s¨okningarna.

Det g˚ar att skapa egna traverserare f¨or att kunna g˚a igenom data som ¨

onskas. Det ¨ar inget som visas i n˚agot av exemplen men det specificeras med notationen @traverser som tar en traverserarklass som argument. N¨ar traverserare anv¨ands sl¨apps programmeraren ner p˚a den l¨agre niv˚an n¨ar traverserarklassen skapas. D¨arefter ¨ar det bara som att g˚a igenom en Col-lection med en for-each sats. Det kan vara bra att namnge relationer n¨ar traverserare ska skapas.

Det finns ut¨over @neo en notation som heter @embed. Den l¨agger inte en relation mellan dem utan serialiserar det annoterade objektet och l¨agger in de i noden. I bakgrunden av @embed jobbar Javas serialisering och g¨or om objektet till en byte array. APIet d¨oljer uppdateringen av index. I APIet p˚a l¨agre niv˚a m˚aste det g¨oras explicit.

4.5. NEO4J APIER KAPITEL 4. NEO4J

Dokumentation

Mindre bra ¨ar att det inte finns speciellt mycket om detta bibliotek p˚a internet. Dokumentationen ¨ar d˚alig och det finns inte mycket om den p˚a bloggar och liknande. Det kan vara sv˚art att hitta l¨osningar p˚a sina problem, f¨or att APIet har lite inbyggd funktionalitet. Attribut g˚ar inte att s¨atta p˚a relationer med APIet. Alla klasser som skapas blir till noder, d¨arav blir alla skapade attribut sparade i noder. Det kan k¨annas ¨onskv¨art att g¨ora speciellt i m˚anga-till-m˚anga relationer. Att attributen ligger i relationerna kan medf¨ora en naturligare representation.

4.5.3

Externa verktyg

Det finns en plugin till utvecklingsmilj¨on eclipse som visualiserar den skapa-de databasen och skapa-dess data. Pluginen heter neoclipse och utvecklas av Neo Technology. Den kan anv¨andas f¨or att se p˚a data visualiserat som en graf som g˚ar att vrida och flytta runt. Det g˚ar ¨aven att utf¨ora diverse administ-rativa uppgifter.

¨

Aven ett webbaserat administrationsverktyg sl¨apptes i och med Neo4J 1.3. Det har ut¨over administration av data en visualisering av grafer.

4.5.4

Utv¨

ardering av API

Den l˚aga niv˚an som den inb¨addade versionen har k¨ants v¨aldigt naturlig men saknar mycket funktionalitet. Den ¨ar helt enkelt p˚a en f¨or l˚ag niv˚a f¨or att kunna bygga st¨orre program p˚a. Javadoc h˚aller en h¨og standard.

Jo4neo har ett v¨aldigt koncist API d¨ar det i princip g˚ar att l¨agga till, h¨amta ut, s¨oka och ta bort. Detta ¨ar det mesta ett program normalt beh¨over. Den ser ut att vara ett bra alternativ f¨or iipax. Intrycket ¨ar att detta system klarar bra av att spara ner objekt i sin naturliga form. Relationer ¨ar n˚agot det finns gott om i ¨arendehantering och det klarar den bra. Ett fall som idag ses som sv˚art i iipax ¨ar att s¨oka i delar av strukturer. Med en specialbyggd traversering ska det fallet klaras bra i Neo.

Kapitel 5

CouchDB

CouchDB ¨ar en dokumentdatabas som ¨ar sl¨appt under ¨oppen licens och ¨ar sl¨appt i version 1.0.1[15]. Databasen ¨ar skriven i Erlang. Dokumenten i data-basen ¨ar lagrat i JSON(JavaScript Object Notation) format och fr˚agespr˚aket ¨

ar javascript. Det finns m¨ojlighet att skapa fr˚agor i andra spr˚ak men java-script ¨ar det vanligaste i den information som finns p˚a internet. Fr˚agor de-signas efter map/reduce och databasen skalar bra. Kommunikationen med CouchDB sker via HTTP och ¨ar designad med webben i ˚atanke.

CouchDB har valts f¨or att det ¨ar en databas som ¨ar sl¨appt under ¨oppen licens och ¨ar en databas som ofta n¨amns i NoSQL sammanhang. Det ser ¨

aven ut att vara en typisk dokumentdatabas och kan ses som en bra repre-sentant f¨or den typen av NoSQL databaser. Den schemal¨osa designen hos dokumenten ser ut att kunna l¨osa n˚agra av problemen som ObjectBase har. CouchDB har m˚anga avancerade funktioner som kan vara v¨arda en n¨armare unders¨okning f¨or anv¨andning i iipax.

5.1

Modelleringsm¨

ojligheter

CouchDB ¨ar schemal¨os vilket leder till att designen av databasen ¨ar fri och kan ¨andras n¨ar som helst, ¨aven d˚a systemet k¨ors. Det finns inga be-gr¨ansningar p˚a antalet f¨alt i ett dokument eller f¨altens storlek. I f¨alten kan det lagras v¨aldigt m˚anga olika typer av data eftersom det lagras i JSON format. Det ¨ar JSON som s¨atter begr¨ansningarna. Det g˚ar d¨arf¨or att n¨astla objekt och g¨ora arrayer. Om inte JSON skulle r¨acka till finns m¨ojlighet till att lagra BLOB i CouchDB. Det finns ¨aven m¨ojlighet till att bifoga filer till ett dokument(eng attachments). Po¨angen med dessa ¨ar att det g˚ar att ladda in deras metadata utan att ladda in filerna sj¨alva.

I CouchDB finns det s˚a kallade designdokument. Ett designdokument ¨

ar precis som alla andra entiteter i databasen ett dokument. Designdoku-ment har namnkonventionen design/[namn]. Ett designdokuDesigndoku-ment har som de andra entiteterna ett id och revisionsnummer. D¨arefter kan det

specifice-5.2. ACID KAPITEL 5. COUCHDB

ras en hel del funktioner som kan anropas och annat till exempel metadata f¨or 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¨andas i funktioner. Det ¨ar bra f¨or att slippa utveckla allt i JSON dokument.

Vyer specificeras genom ett namn och ett n¨astlat objekt. Objektet har f¨alten map och reduce d¨ar reduce ¨ar valfritt. Alla dessa namn resulterar i adressen till RESTanropet. Exempelvis:

http://localhost:5984/couchbase/_design/Manager/_view/all D¨ar all ¨ar namnet p˚a vyn och design/Manager ¨ar namnet p˚a designdoku-ment.

Shows ¨ar en transformation av uth¨amtad data. Det kan vara v¨aldigt bra f¨or att slippa lagra exempelvis HTML- eller XML-mallar explicit. N¨ar databasen kan skicka ut HTML ger det en f¨ordel f¨or s¨okmotorer som inte exekverar AJAX p˚a hemsidor.

Valideringen som kan specificeras i designdokumenten kan f¨ors¨akra sig om att data h˚aller en viss standard. Det kan vara som en ˚atg¨ard mot de fel som kan bli av den schemal¨osa datamodellen. Till en valideringsfunktion skickas alltid en parameter som inneh˚aller roller och den anv¨andare som f¨ors¨oker utf¨ora operationen. Valideringsfunktionerna kan d¨arf¨or hj¨alpa till att s¨akra databasen.

5.2

ACID

En transaktion kan uppn˚a fullst¨andigt st¨od f¨or ACID. D˚a flera transaktioner ing˚ar i en uppdatering, bulkuppdatering, ¨ar st¨odet f¨or ACID ej p˚aslaget fr˚an b¨orjan men kan specificeras s˚a att ingen eller alla transaktioner genomf¨ors. Under en transaktion l˚aser aldrig CouchDB data utan anv¨ander sig av MVCC(Multi Version Concurency Control). Om tv˚a l¨asningar av samma data g¨ors med avsikt att uppdatera data kommer bara den ena uppdate-ringen att g˚a igenom. F¨or att en uppdatering ska g˚a igenom m˚aste den ha ett uppdaterat revisionsnummer. I fallet d˚a en uppdatering med utdaterat versionsnummer f¨ors¨oker uppdatera kommer CouchDB att returnera felkod 409 och ¨andringen sparas inte. Det ¨ar d˚a upp till klienten att f¨or¨oka l¨osa uppdateringen genom att h¨amta en ny kopia och f¨ors¨oka med uppdateringen igen. S˚a l¨oser CouchDB problemet med f¨orlorade uppdateringar.

Trots att data inte blir l˚ast ser en l¨asning samma data under hela tiden eftersom klienten som l¨aser l¨aser en kopia av data.

5.3

Skalbarhet

CouchDB kan replikera data f¨or att kunna best˚a av flera synkroniserade databaser[16]; i ett distribuerat system kommer data att bli inkonsistent.

Det l¨oser CouchDB genom versionshantering. Versionshanteringen v¨aljer de-terministiskt en vinnare bland de olika versionerna.

Det g˚ar att komma ˚at de andra versionerna utifall applikationen vill sl˚a ihop flera versioner ¨anda tills CouchDB utf¨or en rensning av gammalt data och tar bort versioner som inte l¨angre ¨ar aktuella. Det g¨or systemet under perioder d˚a belastningen inte ¨ar h¨og. F¨or en vy visas endast vinnaren bland versionerna.

Det g˚ar att k¨ora CouchDB i klusterkonfiguration med hj¨alp av ramverket Lounge. Det g¨ors genom att sprida ut data p˚a flera maskiner. Anrop till databasen sker genom en proxy som dirigerar anropen bland de olika delarna av databasen.

N¨ar CouchDB k¨ors i ovanst˚aende konfigurationer g¨aller inte ACID utan BASE. Uppdateringar kommer att fortplanta sig genom noderna och uppn˚a konsistent data s˚a sm˚aningom. I distribuerat l¨age uppn˚ar allts˚a CouchDB A och P men inte C.

CouchDBs klusterkonfiguration ¨ar v¨aldigt speciell f¨or att den kan kopiera upp databasen p˚a flera olika noder som kan ha sin egen version och de synkroniseras automatiskt. Noderna beh¨over inte vara uppkopplade hela tiden utan kan g˚a offline och sen uppdateras allt automatiskt vid ett senare tillf¨alle. Det ¨ar n˚agot som idag anv¨ands av molnlagringstj¨ansten UbuntuOne. CouchDB drar s˚a pass lite resurser att den kan k¨oras p˚a nya smartphones. Det g¨or att molntj¨ansterna g˚ar bra att ¨aven k¨ora p˚a mobila enheter.

5.4

Index

Dokumentdatabaser, som CouchDB ¨ar, ¨ar en variant av key/value databaser och d¨arf¨or har alla dokument en unik nyckel. Dokumenten lagras i en b-tr¨adstruktur och har ett index d¨ar med. Det indexet kommer att uppdateras automatiskt.

Vyer indexeras f¨or att bli effektivare. Map/Reduce funktionerna f¨or en vy g˚ar igenom alla dokument f¨orsta g˚angen f¨or att vid senare anrop ha ett uppbyggt index. Det kan ses som s˚a kallade “thunks”. Det ¨ar en konstruktion som bara evalueras f¨orsta g˚angen och sparar sedan ner resultatet.

I CouchDB g˚ar det att fulltextindexera med Apache Lucene. Fulltextin-dexeringen ¨ar ett externt projekt och finns inte fr˚an i grunddatabasen. Ef-tersom APIerna ¨ar avancerade finns det utvecklare som skapat egna indexe-ringar med hj¨alp av det befintliga APIet. Vyer returnerar par av nyckel och ett v¨arde. N¨ar CouchDB s¨oker i en vy g˚ar det endast att g¨ora s˚a p˚a nyckeln. Behandling av v¨ardet sker i applikationslagret. Det g˚ar inte att anv¨anda sig av tecken f¨or att matcha regulj¨ara uttryck men det g˚ar att fr˚aga efter inter-valler av v¨arden. F¨or att skapa mer komplicerade fr˚agor kr¨avs det en smart design av map och reduce funktionerna. F¨or mer avancerad s¨okfunktionalitet m˚aste Lucene pluginen anv¨andas.

5.5. COUCHDB API KAPITEL 5. COUCHDB

5.5

CouchDB API

Till utv¨arderingen av CouchDB har den senaste stabila versionen 1.0.1 anv¨ants. Anledningen till versionsnumret ¨ar att n¨ar version 1.0 sl¨apptes m¨arktes snart en bugg som snabbt ˚atg¨ardades. APIet som anv¨ants ¨ar bib-lioteket Ektorp med versionsnummer 1.1.1[18]. Namnet Ektorp ¨ar lite av en ordlek fr˚an den svenska utvecklaren. Ektorp ¨ar en soffmodell fr˚an IKEA och CouchDB betyder soffa p˚a engelska. Detta bibliotek mappar objekt till databasen men abstraherar ¨aven konstruktioner vyer och repositories.

5.5.1

L˚

agniv˚

a JSON/javascript API

CouchDB har ett RESTful HTTP-baserad[16] API. Enda v¨agen att kommu-nicera ¨ar genom GET, PUT, DELETE och POST metoder som inneh˚aller Javascript-funktioner och data ¨ar 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˚a hur en bloggpost skulle kunna struktureras i CouchDB APIet. M˚asvingarna, {}, anv¨ands f¨or att representera ett objekt och hakpa-renteserna, [], anv¨ands f¨or att representera en array.

function(doc) {

if(doc.age && doc.name) { emit(doc.age, doc.name); }

}

Figur 5.2: Exempel p˚a en lagrad funktion som anv¨ands vid f¨orfr˚agning.

F¨alten age och name i figur 5.2 kontrolleras och emitteras ut ifall de passerar de specificerade kraven. Detta ¨ar map-funktionen i Map/Reduce-modellen. Emitteringen plockas sedan upp av en reduce-funktion, om s˚adan finns, som s¨atter samman allt till ett slutgiltigt svar.

Som tidigare n¨amnts klarar CouchDB av att modellera relationer med hj¨alp av att skapa funktioner enligt map/reduce-modellen. De skapas genom att lagra funktioner som tar in tv˚a dokument och matchar tv˚a v¨arden. Det har stora likheter med ett SQLspr˚aks JOIN funktion.