Software Projekt NoSQL vs RMDB

Transkript

1 Software Projekt NoSQL vs RMDB Skrevet af Carsten Sørensen, Hans Jørgen Frandsen, Peter Haislund Department of Computer Science, University of Aarhus Aabogade 34, 8200 Arhus N, Denmark , , Gruppe Side 1 af 13

2 Indholdsfortegnelse 1 Motivation Hypotese Metode Analyse og resultat Domænemodel Krav Domænemodellen NoSQL databaser Valg af Document Store MongoDB s datastruktur Datastruktur Referencing or Embedding MongoDB skema eksempler Enkelt reference Dobbelt reference Embedded Generer MongoDB data Performance værktøj mod MongoDB MongoDB profiling værktøj C# som profiling værktøj Valg af profiling værktøj Querys performance mod MongoDB Inserts Selects Updates Deletes Relateret arbejde Konklusion Referencer Side 2 af 13

3 1 Motivation I denne rapport vil der blive kigget på fordelene og ulemperne ved at bruge en NoSQL database, med en relationel datastruktur (Normaliseret). Den normaliseret struktur vil blive sammenlignet med den struktur som NoSQL databasen er bygget til, på performance grundlag, i forhold til Selects, Inserts og Updates. 2 Hypotese NoSQL er en databaseteknologi, som er udviklet til løsning af et meget specifikt problem: meget store datamængder distribueret over mange noder med en simpel datastruktur. RDBM er mere allround og kan lagre mange forskelligartede og komplekse datastrukturer. Det er trivielt, at RDBM er velegnet til at lagre datastrukturer med mange relationer, men kan vi finde et skema, som muliggør at samme type datastruktur kan gemmes effektivt i en NoSQL database? Givet datastruktur A i Figur 1, vil det være muligt at vælge skemaer, som henholdsvis favoriserer opdateringer kontra forespørgsler? Vil det være muligt at finde et skema, som går på kompromis så rimelig performance kan tilsikres i begge scenarier? Figur 1 - Datastruktur A 3 Metode Ved at fremstille forskellige skemaer for henholdsvis en-til-en, en-til-mange og mange-til-mange, både i form af normaliseret data struktur og ikke normaliseret data struktur, vil der blive kigget på performance fordelen via inserst, updates og selects. Først skal der kigges på hvilken NoSQL database kan bruges til denne sammenligning. Hvilken NoSQL database der understøtter normaliseret data på en måde som ses anvendelig, men stadig har fordel i sin NoSQL baggrund. Når NoSQL databasen er valgt, skal der konstrueres forskellige eksempler på relations skemaerne, både i en normaliseret og ikke normaliseret form. Side 3 af 13

4 Disse tabeller skal efterfølgende fyldes med tilfældigt data, som kan repræsentere et virkelig miljø, med flere tusinde rækker. Efterfølgende skal der laves gennemsnitsmålinger på inserts, updates og selects, hvor hastighederne sammenlignes. Slutteligt vil der blive analyseret på om der evt. kan optimeres på nogle af tabellerne, for at lave et kompromis, så der måske kan opnås en optimal performance inden for alle 3 query typer. 4 Analyse og resultat 4.1 Domænemodel Krav Før vi lægger os fast på en domænemodel, vil vi opstille nogle krav, som vi har til denne. Vores hovedfokus er relationer, hvorfor vi vil sikre, at den indeholder de tre typer relationer: 1. En til en 2. En til mange 3. Mange til mange Når vi har en model, som indeholder de tre type relationer, som man arbejder med i en RDBM, kan vi betragte denne model som repræsentativ for alle de modeller, som kan laves i en RDBM Domænemodellen Figur 2 Entity diagram Her har vi et databasediagram, som viser relationerne mellem tabeller i et simpelt ordresystem. Vi har begrænset kolonnerne til et minimum, da de er mindre interessante i denne sammenhæng. Et sådant databasediagram er imidlertid ikke særlig godt til at illustrere relationer og entiteter i en domænemodel. Til dette formål har vi et Entity-Relation-diagram i stedet for. Side 4 af 13

5 Figur 3 ER diagram For at bevare vores ER diagram simpelt har vi undladt attributes, hvor de ikke har nogen betydning. Vi har dog medtaget Quantity på Contains, da den kan have betydning og for at demonstrere at der er forskel på Contains og IsResponsibleFor. Lad os tjekke, som vi har de tre slags relationer, som vi har brug for. 1. En til en: LogsOnWith er en typisk relation, som benyttes i RDBM for at undgå null værdier. En kunde kan sagtens være oprettet i ordresystemet, men hvis web frontenden ikke har været benyttet har kunden intet login. 2. En til mange: Has er et typisk eksempel mellem en kunde og ordre. En kunde kan have mange ordrer, men hver ordre har kun en kunde. 3. Mange til mange: Contains og IsResponsibleFor er begge eksempler på mange til mange relationer og viser henholdsvis relationerne mellem ordre og produkt samt kunde og kundeansvarlig. Der er dog forskel på dem. Contains indeholder antal, som i den RDBM bare gemmes i den relationstabel, som benyttes i en mange til mange relation. Vil der være forskel på, hvordan vi kan løse Contains og IsResponsibleFor i MongoDB? 4.2 NoSQL databaser Udvalget af NoSQL databaser er et voksende område, hvor 4 af de mest brugte typer af NoSQL er [Wiki NoSQL]: - Key-Value store - Document store - Graph - BigTable Side 5 af 13

6 Efter at have kigget på de forskellige typer af NoSQL, er valget faldet på Document Store typen. Dette skyldes blandt andet, at typen ville være mulig til at repræsentere en relationel database struktur. Dokument strukturen gør det muligt at benytte foreign key s til at sammenkæde flere dokumenter og derved normalisere data strukturen. Vi vil kigge nærmere på Key-Value store og Document store, da disse gemmer data i en datastruktur, som minder om RDBM. RDBM gemmer objekter i tabeller som kan have en unik nøgle Key-Value stores gemmer objekter med en unik nøgle Document stores gemmer dokumenter med en unik nøgle Det er muligt at lagre relationer i såvel Document stores som Key-Value stores, idet relationen opnås ved at gemme fremmednøglen i objektet/dokumentet. Den afgørende forskel på de to type NoSQL databaser er, om data er gemt i en struktur, som er kendt for databasen. Key-Value stores bruger typisk objekter, som skal læses op i hukommelsen før indholdet kan fortolkes. Document stores benytter dokumenter, hvis indhold kan fortolkes af databasen. Dette bevirker, at der kan laves forespørgsler, som inkluderer alle de felter, som findes i dokumentet og herudover kan der også laves indekser på de forskellige felter, så forespørgselshastigheden kan forøges, hvis der er andre felter end nøglen, som bliver brugt. Mulighederne i Document stores minder således mest om det, som er muligt i RDBM, hvorfor vi vælger denne type i vores analyser Valg af Document Store Der findes flere forskellige Document Store database typer. En liste af hvilke Document store databaser der findes, kan ses i tabellen her under [Wiki NoSQL]: Tabel 1 NoSQL document databaser Side 6 af 13

7 Ud af de mange muligheder er valget faldet på MongoDB af 2 hovedårsager. 1. I forbindelse med vores undervisning er MongoDB blevet brugt og dette har skabt kendskab til brugen af MongoDB som database og dens skema struktur. 2. MongoDB har et C# interface, som er det foretrukne sprog til implementering af et stub program, til at fylde dummy data i databasen MongoDB s datastruktur MongoDB bruger BSON objekter, til sin dokument struktur. BSON er en sammensætning af Binary og JSON [BSON]. BSON understøtter en del typer, så som Intergers, Doubles, Strings, Objects, Arrays og flere. Dette gør at det er muligt at repræsentere de samme typer som i en RDBM. MongoDB understøtter desuden B-Tree s til indeksering af data. Selve dokumentstrukturen er bygget op omkring key til value, som ses i billedet her under: Figur 4 MongoDB dokument struktur Et eksempel på et dokument med flere typer, kan ses i billedet under: var customer = { _id: 1, name: Alan petersen, address: Loop 1, Californien, username: AlanUsr, password: pass1234, responsible: { employeeid: 10, firstname: Jens, lastname: Johnson }, orders: [ { orderid: 30, date: new Date( Jun 01, 2010 ) }, { orderid: 31, date: new Date( Jun 04, 2010 ) } ] } Side 7 af 13

8 Tabel 2 - MongoDB skema eksempel Som det kan ses indeholder feltet responsible et dokument som value og feltet orders indeholder et array af dokumenter. MongoDB s datastruktur understøtter at der er dokumenter i dokumenter Datastruktur Referencing or Embedding Ved design af MongoDB dokumenter (skemaer), bruges enten Referencing eller Embedding. Dette er kort sagt, om dataen gemmes normaliseret eller denormaliseret. Embedding Embedding er til ikke normaliseret data struktur, for at opnå performance når man laver søgninger dataene. Embedding skal helst bruges når der er tale om: - Contains relationer, som i f.eks. en-til-en relationer. - En-to-mange, hvor mange relationerne, helst skal ses i sammenhæng med den ene. Dette kunne f.eks. ses som en bruger, som indeholder alle lån af film fra blockbuster. Fordelene ved at bruge embedding er hurtigere læsninger og mulighed for at lave opslag fulde dataopslag med en forespørgsel. Dog er der ulemper, så som at et dokument må ikke fylde mere end BSON s maximale dokumentstørrelse på 16Mb. Her kan dog bruges GridFS i stedet for ved store datamængder. Referencing Referencing giver muligheden for at lave relationer mellem forskellige dokumenter. Dette gør det muligt at normalisere sin data. Dette giver kort sagt muligheden for at lave foreign key relationer, som kendes fra RDBM. Referencing skal helst bruges når der er tale om: - Når embedding ikke giver læsnings performance, men bare laver data dupletter. - Ved komplekse mange til mange relationer. Fordelene ved referencing, er at det er muligt at modulere mere komplekse datarelationer og gør det nemmere at opdatere data. Ulemperne er derimod mere arbejde af klienten ved at skulle lave flere queries for at få hele sit udtræk. 4.3 MongoDB skema eksempler Vi er kommet frem til 3 MongoDB dokumentskemaer over den valgte domæne model (se Figur 2) Enkelt reference Enkelt reference er det skema som ligner det rationelle domæne mest. Her kender customer til employee, via employee s _id, som er gemt under customer s responsibles array. Side 8 af 13

9 Fordelen er at man undgår redundant data og skemaet bliver enklere at arbejde med, da der kun er referencer til id erne på de andre tabeller. I figuren (Figur 5) her under, kan ses de informationer de forskellige skemaer indeholder. employee customer order product firstname:string lastname:string name:string address:string username:string password:string responsibles: int[] orders:int[] date: datetime orderitems:orderitem[] orderitem quantity: int productid: int name:string ean:string price:double Figur 5 - Eksempel på brug af enkelt reference Dobbelt reference En udvidelse til enkelt reference er dobbelt reference, hvor der er referencer begge veje. Dette vil sige at f.eks. kender customer id erne på order i enkelt reference, men order kender ikke noget til customer. Ved dobbelt reference, kender order også til customer id er. Fordelene er, at det muligt f.eks. at finde alle ordrer til en kunde uden at skulle slå op i customer. Ulemperne er dog at der skal holdes styr på id erne i to skemaer. I figuren (Figur 6) her under, kan ses de informationer de forskellige skemaer indeholder. employee customer order product firstname:string lastname:string customers:int[] name:string address:string username:string password:string responsibles: int[] orders:int[] date: datetime customerid:int orderitems:orderitem[] orderitem quantity: int productid: int name:string ean:string price:double orders:int[] Figur 6 - Eksempel på brug af dobbelt reference Side 9 af 13

10 4.3.3 Embedded Embeddede skemaer er bygget som ét stort skema præcist som MongoDB er designet til. Fordelene er at dataene er samlet et sted. F.eks. kan man finde alle employee s under den kunde man kigger på og der undgåes derved at skulle lave et ekstra opslag, for at hente denne information. Ulemperne er dog redundant data, da f.eks. to employees kan have ansvar for den samme kunde. Dette kan skabe problemer ved opdateringer, da man skal finde alle steder, hvor den ansatte findes og opdatere. I figuren (Figur 7) kan ses de informationer som de forskellige skemaer indeholder. customer name:string address:string username:string password:string responsibles:employee[] employee firstname:string lastname:string orders:order[] order date: datetime customerid:int orderitems:orderitem[] orderitem quantity: int name:string ean:string price:double Figur 7 - Eksempel på brug af embedding 4.4 Generer MongoDB data For at have noget data at arbejde på, har vi lavet en C# applikation, som generer data der kan anses for at være et eksempel på realistisk data. Med realistisk data menes der, at felterne har data og koblingen mellem ordre og kunder er skiftende. Ergo har alle kunder ikke samme antal ordre. 4.5 Performance værktøj mod MongoDB Til at lave målinger på queries mod MongoDB databasen, er der flere muligheder: - MongoDB shell (MongoDB indbygget værktøj). - C# querys med stopur tidsmålinger. - Andre programmerings sprog. Side 10 af 13

11 4.5.1 MongoDB profiling værktøj MongoDB har indbygget et profilings værktøj [MongoDbProfiling], som gør det muligt at se performance af sine queries. Dette giver et reelt indblik i hastigheden for en query for at finde noget data. Værktøjet For at starte profilering for en Shell instans, skal følge scripts køres når man starter sin shell. db.setprofilinglevel(2); For at se de 10 sidste profileringer for en given collection, skal følgende scripts køres. db.system.find( { ns: <DatabaseNavn>.<Collection> } ).limit(10).sort({ ts: -1 }).pretty(); Et eksempel på dette kan ses her under: db.setprofilinglevel(2); db.product.find(); db.system.profile.find( { ns: OrderingSemi.Product } ).limit(1).sort( { ts: -1 }).pretty(); Ud fra dette kan query tiden ses under feltet millis, som i dette tilfælde er 1 ms. Side 11 af 13

12 Fordele og ulemper Værktøjet givet et nemt og overskueligt billede af de enkelte querys på de forskellige collections. Dette gælder alle queries mod databasen, som også gælder MapReduce funktioner. Ulempen er dog at det ikke giver et billede ud fra det værktøj man bruger, som f.eks. C# C# som profiling værktøj C# har ikke noget værktøj til at lave performance på MongoDB databaser, men vi har dog valgt at anvende C# s indbygget stopurs klasse (StopWatch). Dette gør det muligt at lave tidsmålinger rundt omkring queries mod databasen, som kan ses i et eksempel herunder: var sw = new Stopwatch(); var query = Query.EQ("Orders.OrderItems.Ean", ean); sw.start(); var count = this.customer.find(query).count(); sw.stop(); return sw.elapsedmilliseconds; Tabel 3 - Eksempel på anvendelse af C# StopWatch Dette giver tiden for MongoDB database om at finde det data man laver en query efter. Herefter kommer der ofte noget data mapning til objekter. Dette vil der dog ikke blive taget højde for i dette projekt, da der kigges på tiden af databasen Valg af profiling værktøj MongoDB s indbygget profiling værktøj er simpelt og lige til at bruge, men dette er ikke helt praktisk, når der skal kigges på reference tabeller, da der så skal laves MapReduce funktioner. Her valgte vi at bruge C#, da der kan laves tidsmålinger på at slå op i en tabel, hvorefter der laves queries mod en anden tabel med data fra den første. 4.6 Querys performance mod MongoDB Inserts Selects 1. Find antal produkter ud fra en ordre a. Done 2. Find alle produkter (distinct) a. Done 3. Find all kunder, find hver ordres samlede pris 4. Find alle kunder, som har købt EAN a. Done Side 12 af 13

13 db.customer.find({'orders.orderitems.ean':"570014"}); Nye forslag 5. Map-Reduce for at finde hvor mange der er solgt af ean x Updates 1. Øg prisen med 10% på EAN X 2. Ændre navnet på ansat X Deletes 1. Slet kunde og dermed også tilhørende ordrer og orderitems 5 Relateret arbejde Links til læsning (intern brug): Beksrivelse (MongoDB) One to Many One to One Data model tanker Glossary Lidt af det hele Lidt af det hele mere Link Konklusion 7 Referencer [Wiki NoSQL] [BSON] [MongoDbProfiling] Side 13 af 13