JÄMFÖRELSE AV NOSQL
DATABASER I EN NODE.JS REST API
Med fokus på att hämta data
COMPARISON OF NOSQL
DATABASES IN A NODE.JS REST API
Focus on retrieving data
Examensarbete inom huvudområdet Informationsteknologi
Grundnivå 30 högskolepoäng
Vårtermin 2020
Adam Sykes
Sammanfattning
Innehållsförteckning
1.
Introduktion ... 1
2.
Bakgrund ... 2
2.1. Rest API ... 2 2.2. Node.js ... 3 2.3. NoSQL ... 4 2.3.1. MongoDB ... 5 2.3.2. Couchbase ... 5 2.4. Relaterade Arbeten ... 53.
Problemformulering ... 7
4.
Metodbeskrivning ... 8
4.1. Alternativa Metoder ... 8 4.2. Etik... 95.
Genomförande ... 10
5.1. Litteraturstudie ... 10 5.2.2. Test script ... 13 5.3. Pilotstudie ... 145.3.1. Hämta data utifrån ett slumpvis valt år ... 15
5.3.2. Hämta all data ... 17
5.3.3. Hämta data över en viss befolkningsmängd ... 19
5.3.4. Resultat och Reflektion ... 21
6.
Utvärdering ... 22
6.1. Ändringar av mätningar ... 22
6.2. Presentation och analys av mätningar ... 22
6.2.1. Hämtning av all data ... 23
6.2.2. Hämtning av data från ett slumpvis valt år ... 24
6.2.3. Hämtning av data över en slumpvis vald befolkningsmängd ... 25
6.2.4. Hämtning av enstaka dokument med slumpvis vald landskod ... 27
6.2.5. Hämtning av ett fält med slumpvis vald landskod ... 28
7.
Slutsats ... 30
7.1. Sammanfattning ... 30
7.2. Diskussion ... 31
1
1.
Introduktion
Detta arbete jämför de två NoSQL databaserna MongoDB och Couchbase i en Node.js utvecklad REST api. För att se vilken databashanterare som har kortast responstid i att hämta befolkningsdata genom nämnda REST api. Båda NoSQL databaser är dokument-drivna, vilket betyder att datan grupperas i en dokument liknande stil istället för tabeller. NoSQL i sig är en typ av databashanterare där datan inte sparas i tabeller som SQL databaser. Datan har inte heller relationer mellan sig som i SQL databaser. MongoDB och Couchbase kopplas då ihop med det utvecklade Node.js REST api:t. Node.js är en plattform för Javascript på servern och REST är en arkitekturstil. Ett REST api är en separation mellan användaren och servern, där en begäran skickas till en URI. Den utvecklade koden bestämmer då vad som ska hända med den begäran, t.ex spara datan som skickas i en databas.
I valet av webbteknologier är responstiden en av de viktigaste aspekterna. En lång responstid leder till att användare byter tjänst (Rajamony 2001). Därför ska responstiden i att hämta data testas.
Efter pilotstudien skapades ytterligare 2 endpoints, tillsammans med de första 3. För att kunna testa databaserna ytterligare. Sättet att mäta ändrades också från 3x2000 mätningar till en stor mätserie på 6000 mätpunkter för varje endpoint. Mätningar sker i egenutvecklade skript där varje mätpunkt sparas i en array i localstorage, som sedan manuellt kopieras in i Google Sheets (Google 2020) för att kunna skapa grafer.
2
2.
Bakgrund
Denna del beskriver de teknologierna som ska användas i studien.
2.1. Rest API
REST (Representational State Transfer) är en arkitekturstil på servern för en användare-server förbindelse. Vanligtvis används HTTP protokollet och dess fyra huvudsakliga metoder: Post, Get, Put och Delete. Även kallade HTTP verb. Dessa HTTP implementationer mappas mot databasoperationerna CRUD (create, read, update och delete). Vilket betyder skapa, läsa, uppdatera respektive radera. Operationerna indikerar hur REST api:t ska hantera datan i en REST begäran, som då skickas till en resurs genom dess unika URI. Resurs är enligt Belqasmi et al (2012) information som är namngett och viktigt nog att bli refererat till, exempelvis ett dokument, en rad i databasen eller ett sökresultat. Berners-Lee et al (1998) skriver att URI (Uniform Resource Identifier) klassificeras som positionsgivare, namn eller båda. Inom URI ingår exempelvis URL som då är en adress som namnger och är ett sätt att hitta resursen på. Se figur 1 nedan för exempel på URI.
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc2396.txt
mailto:John.Doe@example.com
Figur 1 - Exempel på URI från Berners-Lee et al (1998)
En REST begäran innehåller all nödvändig information för att servern ska utföra den, vilket gör REST till stateless eftersom varje begäran ska vara oberoende av en annan. Detta är en av de 3 huvudsakliga REST design principerna enligt Belqasmi et al (2012). Tillsammans med state-lessness är det addressability och uniform interface som är design principerna. Addressabilty är att en resurs kan identifieras genom en URI. Uniform interface betyder att resurserna, inom webb och dess HTTP protokoll, interagerar genom HTTP metoderna Get, Post, etc. som står ovan (Pautasso 2014). Figur 2 nedan visar hur ett REST api arbetar.
3 En REST api är en separation mellan användarens interaktioner och servern samt datalagringen. I praktiken leder detta till ökad skalbarhet, portabilitet på gränssnittet och möjliggör då separat utveckling av ett projekts komponenter, exempelvis gränssnittet och server delen. (Bellotti et al 2019). Eftersom REST är en arkitekturstil kan ett REST api utvecklas i de flesta programmeringsspråken. Exempelvis Java, PHP, .NET, Python eller Node.js (Belqasmi et al 2012; Munonye et al 2018; Bellotti et al 2019). En endpoint är dit begäran skickas och hanteras, en URI. Vad som ska ske när denna endpoint får till exempel en Post begäran bestäms i REST api:t. En av Node.js styrkor är att de kan hantera stora mängder requests (Tilkov & Vinoski 2010), vilket är vad en REST api kommer hantera.
2.2. Node.js
Node.js (Node.js 2020) är en plattform för att kunna exekvera Javascript på en server. Som leder till att man kan bygga en hel webbapplikation med endast ett programmeringsspråk, Javascript. Node.js är byggt på Googles V8 Javascript motor och är gjort i C och C++. Där fokus ligger på prestanda och låg minnesanvändning. Node.js är en asynkron event-driven miljö, vilket betyder att applikationen inte kan bli blockad när den väntar i en input/output operation. Detta gör att den lätt kan hantera en stor mängd med requests (Tilkov & Vinoski 2010). Node.js hanterar även alla exekvering av kod i samma tråd vilket simplifierar utvecklingen av webbapplikationer. Att en tråd används leder till att Node.js kan behandla systemets resurser relativt effektivt, jämfört med webbapplikationer som hanterar varje klient anslutning i en separat tråd (Ojamaa & Düüna 2012).
Routing i Node.js kan underlättas med hjälp av ett antal ramverk. Hahn (2016) skriver att routing bestämmer vilken kod som ska köras när en request anländer till en URI, alltså kan olika typer av requests (Get, Post, etc.) ske på samma URI. Ett ramverk som räknas som ett av de mest robusta men ändå minimala ramverken för en HTTP server till Node.js är Express (Schutt & Balci 2016; Express 2020). I figur 3 nedan visas ett exempel i Express på hur man kan hantera en REST begäran med en Get metod. Först kallas Express ramverket in och dess inbyggda router används. När någon hämtar URI:n (exempel.com/dennaTodo) kallas först en funktion sedan skickas en JSON respons med den todon som överensstämmer med URI:n. Detta är alltså en endpoint
.
const express =
require
(
"express"
);
const router = express.Router();
router.get(
"/:todo"
, getTodo, (req, res) => {
res.json(res.todo);
});
Figur 3 – Kodsnutt av Express (Node.js)
4 naturligt för en utvecklare inom Javascript att använda en NoSQL databas, t.ex MongoDB, eftersom det kan användas mer direkt än en SQL databas.
2.3. NoSQL
Boicea et al (2012) skriver att NoSQL är en klass för databashanterare som skiljer sig från relationsdatabaser eftersom datan lagras i dokument med dynamiska databasscheman. NoSQL databaser överlag kan hantera data snabbare än en relationsdatabas eftersom de har enklare datamodeller. Men en svaghet är komplext frågespråk (Leavitt et al 2010). Inom NoSQL finns det databashanterare med olika datamodeller, de tre största är följande:
Nyckelvärde (Key-Value), denna datamodell består av två delar. Vilket är en nyckel och ett värde, som är data i någon form. Strukturen är enklare och har snabbare frågespråk än en relationsdatabas (Han et al 2011). Men i frågespråket kommer man bara åt datan genom nyckeln, och kan alltså inte söka på ett värde (Hecht et al 2011). Nayak et al (2013) skriver att nyckelvärde databaser exempelvis passar till när användarens session ska lagras eller till användarens kundvagn på en shoppingsida. Exempel på nyckelvärde databaser är Redis och Tokyo Cabinet (Han et al 2011). Kolumn-orienterade (Column-Oriented) sparar all tillhörande data i en kolumn.
Varje kolumn är även databasens index. Denna NoSQL datamodell passar till exempelvis datalager. Exempel på kolumn-orienterade databaser är Cassandra och Hypertable (Han et al 2011)
Dokument-drivna (Document-Driven) databaser organiserar datan som kollektioner av dokument och sparar i JSON eller XML format (Han et al 2011; Leavitt 2010). Det är likt nyckelvärde databaser då varje dokument har en nyckel (ID), men i frågespråket kan man även söka på värdena i dokumentet (Hecht et al 2011). Dokument-drivna NoSQL databaser fokuserar mer på prestandan på lagringen av stora mängder data och på frågespråket än på läs/skriv operationer (Han et al 2011). Exempel på dokument-drivna databaser är MongoDB, Couchbase och SimpleDB. Nayak et al (2013) kommer fram till att NoSQL databaser har ett antal fördelar jämfört med relationsdatabaser. Några av dessa fördelar är att de är skalbara, finns flera datamodeller att välja mellan och att utvecklingen bland NoSQL databaser har gått fort. Samtidigt presenterar Nayak et al (2013) ett antal nackdelar jämfört med relationsdatabaser. Det finns inget standard frågespråk, inget standard gränssnitt, relativt nytt och underhållningen av dem kan vara besvärlig.
5
2.3.1.
MongoDB
MongoDB är en dokument-driven NoSQL databashanterare (MongoDB, Inc 2020) och är någonstans mellan en traditionell relationsdatabas och en icke-relationsdatabas, dock är den mest lik en relationsdatabas jämfört med andra NoSQL databaser. MongoDB sparar datan dokument som är samlade i så kallade collections, vilket kan jämföras med rader i en relationsdatabas. Fördelar med MongoDB, som med dokument-drivna databaser överlag, är att den är väldigt bra på frågespråk och kan hantera stora mängder data. Exempelvis om lagringen är över 50 GB är åtkomsthastigheten 10x snabbare än i en MySQL databas. MongoDB kan även lagra komplexa datatyper. Dessa fördelar leder till att företag med mycket data föredrar MongoDB (Han et al. 2011). Lagringen i MongoDB sker i BSON formatet (figur 4 nedan), och är enligt (MongoDB, Inc 2020) en representation av JSON med extra funktionalitet. BSON står för Binary JSON och är alltså ett binärt format på JSON vilket leder till att integrationen av vissa datatyper är snabb men lätt (Băzăr et al 2014).
{
"_id":
"5cf0029caff5056591b0ce7d"
,
"firstname":
"Jane"
,
"lastname":
"Wu"
,
"address" : {
"street":
"1 Circle Rd"
,
"city":
"Los Angeles"
,
"state":
"CA"
,
"zip":
"90404"
},
"hobbies": [
"surfing"
,
"coding"
]
}
Figur 4 – exempel på ett MongoDB dokument från mongodb.org
2.3.2.
Couchbase
Couchbase är en dokument-driven NoSQL databashanterare och är open source under Apache 2.0 licensen (Couchbase 2020). Den var främst skapad för interaktiva webb- och mobilapplikationer (Băzăr et al 2014). Hubail et al (2019) beskriver Couchbase som ett väldigt skalbart databassystem med en “share-nothing” arkitektur och som använder formatet JSON. Där dokumenten är sparade i så kallade buckets, vilket är en samling av logiskt relaterade dokument. Detta motsvarar en databas i en relationsdatabas (Hubail et al 2019). Couchbase använder frågespråket N1QL (uttalas nickel), ett exempel på att hämta viss data i Node.js visas i figur 5 nedan.
var N1qlQuery = couchbase.N1qlQuery;
var query = N1qlQuery.fromString("SELECT name FROM `travel-sample`
AS Airline WHERE id = 5209"
);
bucket.query(query,function(err,result){
/* handle results */
});
Figur 5 – exempel på att hämta data i Couchbase
2.4. Relaterade Arbeten
6 Boicea et al (2012) kom fram till att MongoDB var snabbare och mer flexibel men att Oracle databasen fortfarande är bästa alternativen för komplexa databaser med relationer mellan tabeller.
Băzăr et al (2014) jämför tre NoSQL databaser i sin studie, dessa är Cassandra, Couchbase och MongoDB. Läs och skriv testerna som utförs visar att Couchbase har lägst responstid. Dock noterar Băzăr et al (2014) att det är komplicerat att välja en NoSQL databas för ett projekt, eftersom alla är optimerade för olika scenarion.
7
3.
Problemformulering
Responstiden är en av de viktigaste delarna i beslutet av webbteknologi. Quality of Service används för att upptäcka en lämplig webbteknologi, vilket baseras på responstid, tillgänglighet och pålitlighet (Kulnarattana & Rongviriyapanish 2009). I detta arbete ska responstiden av databashanterare jämföras i en REST api skapad i Node.js, vilket är till nytta för utvecklare när de ska välja databas för ett liknande projekt. Responstiden blir viktig då Rajamony (2001) skriver att det finns stor chans att kunden byter till en konkurrerande tjänst om responstiden är för långsam. Det finns två faktorer som leder till långa responstider: dåligt nätverk och tiden det tar för servern att leverera en respons. Det är alltså tiden att leverera en respons som en utvecklare kan förbättra. Responstiden är i detta arbete definierad som tiden det tar för datan att anlända till klienten efter att klienten begärt den mätt i millisekunder.
Node.js är genom sin händelsedrivna arkitektur snabb på att hantera data mellan klient och server (Bangare et al. 2016). Att just Node.js är snabb på att hantera data gör det intressant att jämföra med andra NoSQL databashanterare inom gränserna av ett REST api, för att då kunna välja den optimala databashanteraren för just denna typ av applikation. Băzăr et al (2014) och Li et al (2013) har visat i sina tester i läs-, skriv- och raderingshastighet att Couchbase har lägre responstid än MongoDB. Detta arbete ska ta reda på om detta stämmer inom en Node.js REST api för befolkningsdata.
Valet av dataset är av relativt stor vikt då det är hur fort datan hämtas från databasen via REST api:t som ska mätas. Det som spelar roll är att datasetet inte har några relationer mellan tabeller eller dokument då NoSQL databaserna MongoDB och Couchbase ska användas. Han et al (2011) kommer i sin studie fram till att MongoDB endast ska användas om man inte behöver relationer. Datasetet som kommer användas är fylld med data om världens befolkning, den har fälten: Land, Landkod, Befolkning och Årtal (Datahub 2020). Denna data har ingen relation utan är en JSON fil som då, enligt Han et al (2011), passar till MongoDB men även till Couchbase då Hubail et al (2019) skriver att just JSON formatet används i Couchbase. Detta dataset har en okomplicerad struktur (4 entydiga värden). Vilket kan påvisa för hur snabb responstiden skulle kunna vara för ett dataset med liknande struktur.
Problemet är att kunder byter tjänst om applikationen har längre responstider än konkurrensen. Rajamony (2001) skriver att användare som ofta får en lång responstid byter tjänst, det finns två faktorer som leder till långa responstider: dåligt nätverk och tiden det tar för servern att leverera en respons. Återigen är det alltså tiden att leverera responsen en utvecklare kan förbättra. Detta arbete kan hjälpa utvecklare fatta ett beslut av databashanterare när en utveckling av en Node.js REST api sker.
Frågeställningen: Vilken databashanterare har kortast responstid i att hämta data i en Node.js REST api?
Nollhypotes: MongoDB kommer inte att ha kortare responstid i att hämta data i en REST API än Couchbase.
8
4.
Metodbeskrivning
I detta arbete kommer ett teknologi-orienterat experiment genomföras, eftersom verktyg kommer att användas för mätningen av responstid. Människoorienterat experiment passar ej i detta arbete då automatiska mätningar ska ske för att undvika mänskliga fel. Wohlin et al (2012) skriver att det är lättare att kontrollera ett teknologi-orienterad än ett människoorienterat experiment ifall de inte görs slumpartade. Eftersom människoorienterade experiment kan bli påverkade av yttre faktorer. Testningen av de två databashanterarna i REST api:t kommer ske i en kontrollerad miljö för att kunna manipulera beteendet och verifiera att villkoren för databaserna är lika. Wohlin et al (2012) nämner att på detta sätt kan man efterlikna beteenden från verkligheten. Ett experiment kan bekräfta i vilken situation och kontext som standarder, metoder eller verktyg passar till och används i detta fall för att bekräfta en hypotes (Wohlin et al 2012). Vilket även svarar på frågeställningen. I detta fall kan det styrka vilken av NoSQL databaserna som lämpar sig bäst till en REST api med befolkningsdata. Eftersom experimentet sker på två olika databaser och inte på en befintlig applikation finns det ingen baseline att utgå ifrån. Variabeln i experimentet är databasen då det är denna som ändras och jämförs i testerna.
I experimentet ska REST api:t och databaserna köras på samma dator. Eftersom allting är lokalt på samma dator undviks nätverkslagg och yttre faktorer. Det som ska mätas är tiden det tar för REST api:t att hämta data från databasen och skicka det till en webbplats, alltså responstiden. Men det är endast ändringen av databas som kommer vara skillnaden mellan de olika testen, och är alltså då den enda faktorn för skillnad. I detta arbete ska endast hämtning av data ske. Denna hämtning kommer vara uppdelad i olika sökfrågor: all data, ett specifikt år och alla länder över en viss population.
För att svara på frågeställningen utifrån ovanstående metod behövs ett antal delmål uppnås. Dessa är följande:
1. Utveckla koden för arbetet. MongoDB och Couchbase databaser ska skapas och behöver då olika REST api endpoints för att kunna testas mot varandra. Dessa endpoints skapas i Express (nodejs) och ska kunna hämta all data, data med ett specifikt år och data med alla länder över en viss population från respektive databashanterare.
2. Utveckla script för att skicka Get requests till REST api:t och mäta responstiden på att hämta all data, data med ett specifikt år och data över en viss population.
3. Samla in testdata genom scripten.
4. Analysera testdatan för att svara på frågeställningen.
4.1. Alternativa Metoder
9
4.2. Etik
10
5.
Genomförande
I detta kapitel förklaras implementation av koden, exempelvis hur en endpoint ser ut i MongoDB respektive Couchbase. Hur mätningarna sker i test scripten visas även och slutligen presenteras alla mätningar från pilotstudien där en slutsats framförs. Koden för implementationen och test scripten är upplagda på Github1.
5.1. Litteraturstudie
För att utföra implementationen av artefakten och test scripten togs det inspiration från ett flertal källor. Det mest självklara var att läsa de olika databasernas och teknologiernas dokumentation. De dokumentations sidor som användes var för Couchbase (Couchbase 2020b), Express (Express 2020b) och Mongoose (Mongoose 2020b). Dokumentation sidan för Mongoose var väldigt tydlig och visade exakt vad som behövdes för att exempelvis hämta data över en viss befolkningsmängd. När det uppstod mindre problem med koden googlades problemet och Stack Overflow (Stack Overflow 2020) var oftast hemsidan som var till mest hjälp. Stack Overflow är en hemsida där vem som helst kan skapa en tråd med en fråga där andra programmerare hjälper till. Eftersom sidan är väldigt populär finns det redan en tråd för nästan alla problem man kan tänka sig. Exempel på en Stack Overflow tråd som var till hjälp handlade om att hämta slumpmässiga dokument i MongoDB2. Då det aldrig uppstod stora problem under utvecklingen fungerade det utmärkt att förlita sig på Stack Overflow och respektive dokumentations sida. Det fanns redan en del kännedom om Express och MongoDB innan på grund av befintlig kunskap. Couchbase frågespråk var väldigt likt frågespråket i SQL. Detta lärde man sig i kursen Databassystem på Högskolan i Skövde.
5.2. Implementation
5.2.1.
REST api
Ramverket Express användes för att skapa en webbserver och REST api endpoints för MongoDB och Couchbase. I Express skapas så kallade “routes” där funktionaliteten i en endpoint programmeras. I figur 6 nedan hämtas all data från MongoDB när någon hämtar från URI:n “exempel.se/mongodb”. Sedan skickas all data till webbläsaren som visar den i JSON format. Det är första raden kod som bestämmer att URI:n “exempel.se/mongodb” ska använda koden från filen mongo.js i routes.
1 https://github.com/a17adasy/exjobb
11 /*
app.js */
app.use("/mongodb", require("./routes/mongo")); /*
mongo.js */
// shows all documents from mongodb database router.get("/", async (req, res) => {
try {
const data = await MongoPop.find(); res.send(data);
} catch (err) {
console.log(err); }
});
Figur 6 – Kodsnutt på att hämta all data från MongoDB
Det skapades 3 endpoints för MongoDB och 3 likadana för Couchbase. Till MongoDB användes tillägget Mongoose (Mongoose 2020) som gör det lättare att hantera och hämta data från en MongoDB databas. Couchbase använder sig av ett SQL liknande språk för att hämta data, vilket gör det välbekant att arbeta med. En likadan endpoint som ovan skapades på detta sätt i Couchbase, figur 7 nedan. De tre endpointsen har samma funktionalitet för MongoDB och Couchbase, och det är att hämta all data, data med ett specifikt år och slutligen all data som är över en viss population. Med detta skapat uppnås delmål 1, som har beskrivits ovan. En rad att notera i Figur 7 är res.send där endast rows skickas vilket då undviker metadata som annars följer med i JSON datan från Couchbase. Detta var något som märktes under arbetets gång.
/*
app.js */
app.use("/couchbase", require("./routes/couchbase")); /*
couchbase.js */
// shows all documents from the Couchbase database router.get("/", async (req, res) => {
try {
const result = await cluster.query("SELECT * FROM
`population`"); res.send(result.rows); } catch (err) { console.log(err); } });
Figur 7 – kodsnutt på att hämta all data från Couchbase
12 kollar koden genom MongoDB databasen och matchar värdet i databasen mot värdet i URI:n. Efter detta visas all matchande data i JSON i webbläsaren.
// Shows all documents with the same year as from the :year value from the url
router.get("/:year", async (req, res) => { try {
const theYear = parseInt(req.params.year);
const data = await MongoPop.find({ Year: theYear }); res.send(data);
} catch (err) {
console.log(err); }
});
Figur 8 – Kodsnutt på att hämta data från ett specifikt år från MongoDB
Datasetet läggs in i MongoDB genom att kopiera in JSON datan och ladda upp, men för Couchbase uppstod några komplikationer när detta gjordes. Eftersom man var tvungen att definiera ett id manuellt. Då detta gjordes automatiskt i MongoDB skapades en endpoint för att hämta datan från MongoDB och infoga det i Couchbase, detta visas i figur 9 nedan. En positiv sidoeffekt är att detta säkerställer att datan är likadan i båda databaserna. Koden kan även ses i commit 636c41e3.
router.post("/mongo-to-couch", async (req, res) => { await MongoPop.find()
.lean()
.exec((err, alldata) => { if (err) console.log(err); try {
alldata.map(async (data) => { await collection.insert( data._id.toString(), {
"Country Code": data["Country Code"], "Country Name": data["Country Name"], Value: data.Value,
Year: data.Year, },
function (err, result) {}
Figur 9 – Infoga data från MongoDB till Couchbase
I MongoDB behövs en modell skapas som databasen kommer följa, och som används när man ska hämta data. Detta underlättar mongoose med. Modellen exporteras och används i andra filer genom att kalla på den. MongoPop i figur 7 ovan är modellen som används i detta arbete och visas i figur 10 nedan. I mongoose schemat bestäms databasens namn och värdetyper. Couchbase har inget sådant krav för datamodellering till databasen, vilket kan ses i figur 9 ovan när datan läggs in i Couchbase databasen.
13 const mongoose = require("mongoose");
const MongoSchema = new mongoose.Schema({ countryName: String,
countryCode: String, year: Number,
value: Number, });
const MongoPop = mongoose.model("MongoPop", MongoSchema); module.exports = MongoPop;
Figur 10 – MongoDB modell med mongoose
När en Couchbase databas initieras, skapas inga index. Vilket leder till att det inte går att söka och få fram data från Couchbase genom endpointsen som skapats. Därför behövdes en index skapas. Detta görs på Couchbase webbaserade kontrollpanel som följer med i installationen. I den konsolen används koden som visas i figur 11 nedan varje gång Couchbase databasen har skapats.
CREATE PRIMARY INDEX
`population-primary-index` on `population`
Figur 11 – Skapa ett index för Couchbase
För att testa dessa endpoints behöver man hämta från REST api:t genom URI:n som har bestämts, exempelvis localhost/mongodb/2007. För detta skapades olika script som beskrivs i mer detalj i nästa kapitel.
5.2.2.
Test script
14 function fetchingAll(uri, db) {
let end;
let start = performance.now(); fetch(`${uri}`, { method: "GET", mode: "cors", cache: "default", }) .then((response) => { return response.json(); }) .then((data) => {
const stringified = JSON.stringify(data); div.innerHTML = stringified;
end = performance.now(); })
.then(() => {
const result = end - start;
// put performance result in localstorage });
}
Figur 12 – Kodsnutt på att hämta all data och mäta responstiden
Två av test skripten har varsin Array med 2000 värden för befolkningsmängd respektive årtal. Dessa värden var slumpmässigt genererade genom MongoDB, koden för detta visas i figur 13 nedan och kan även ses i commit ba129294. I figuren hämtas 2000 slumpmässiga dokument från MongoDB och årtalet skrivs ut i webbläsaren. Samma sak gjordes för befolkningsmängden.
// only for getting array for testing
router.get("/random", async (req, res) => { try {
const randomData = await MongoPop.aggregate([ { $sample: { size: 2000 } },
]);
const data = randomData.map((d) => { return d.Year; }); res.send(data); } catch (err) { console.log(err); } });
Figur 13 – Kodsnutt för att generera slumpmässiga värden
5.3. Pilotstudie
För att testa att databaserna går att jämföra som planerat utfördes en pilotstudie. Pilotstudien är en mindre variant av den senare studien för att kunna hitta förbättringar och isåfall ändra sättet att mäta på för den riktiga studien. I denna pilotstudie utfördes det 3 mätserier för varje
15 sökfråga, där varje sökfråga hade 2000 mätningar. Exempelvis när sökfrågan för att hämta alla data utifrån ett år utfördes en mätserie genom att iterera genom en array bestående av 2000 år. Detta gjordes då 3 gånger där databasen raderades och skapade igen efter varje mätserie. Att skapa databasen igen gjordes för att säkerställa att ingenting hände under ytan i MongoDB eller Couchbase mellan mätningarna. Pilotstudien utfördes lokalt på samma dator och blev totalt 18 mätserier med 2000 mätningar i varje. Datorn som genomförde pilotstudien körde Windows 10 Pro version 1903 64-bitar med följande hårdvara: Intel Core i5-7600 3.50 GHz, GTX 1070 och 16GB RAM. Versionerna på databashanterarna är MongoDB Community Server 4.2.3 samt Couchbase Community Edition 6.0.0.
5.3.1.
Hämta data utifrån ett slumpvis valt år
Att hämta all data från MongoDB och Couchbase med ett slumpvis valt år skedde 2000 gånger i 3 mätserier. Mätningarna av responstiden för att hämta datan och visa i JSON format i webbläsaren kan ses i figur 14 nedan. Här kan man se att MongoDB har betydligt lägre responstid än Couchbase i samtliga mätserier på att söka fram och hämta data med ett specifikt årtal.
I figur 15 nedan på genomsnittet av att hämta data utifrån ett slumpmässigt år kan man se att standardavvikelsen är låg, vilket betyder att mätningarna som gjordes inte har några stora störningar. Ett anova test gjordes även på dessa mätningar som visade ett p-värde på 0.00, under gränsen på 0.05. Ett sådant lågt p-värde betyder att det finns en statistisk skillnad.
16
Figur 15 – Genomsnitt på att hämta data utifrån år
För att visa spikar på ett tydligt sätt valdes endast en mätserie, mätserie 3. Denna kan man se i figur 16 nedan. Det finns en spik på respektive databas som sticker ut. En i mitten för Couchbase och en nästan i början på MongoDB.
17
5.3.2.
Hämta all data
Andra testet som gjordes var att hämta all data från MongoDB och Couchbase. Databasen som används i detta arbete består av 14,885 NoSQL dokument och har en total storlek på 1.4MB. All denna data hämtades 2000 gånger och presenterades i webbläsaren i ett JSON format. Dessa mätningar visade att MongoDB och Couchbase var väldigt jämna i att hämta hela databasmängden, men att MongoDB fortfarande var lite snabbare, se figur 17 och 18 nedan. P-värdet är 1.00, alltså över gränsen på 0.05. Detta är ett väldigt högt p-värde men betyder att det inte finns en statistisk signifikant skillnad på MongoDB och Couchbase på att hämta all data.
18
Figur 18 – Genomsnitt på att hämta all data
För att visa spikar på ett tydligt sätt valdes endast en mätserie, mätserie 3. Denna kan man se i figur 19 nedan. Som standardavvikelsen indikerade på figur 17 ovan finns det massiva spikar i mätningen på att hämta all data. Då detta hämtar samma mängd data varje gång borde spikarna bero på något annat problem. Exempelvis andra applikationer i bakgrunden på testdatorn.
19
5.3.3.
Hämta data över en viss befolkningsmängd
Den tredje och sista av testerna i pilotstudien var att hämta data över en vald befolkningsmängd. JSON datan som presenteras i webbläsaren är även sorterad i fallande ordning, genom respektive databas. Precis som tidigare tester gjordes detta test 3 gånger med 2000 mätningar i varje. Värdena för befolkningsmängden är 2000 stycken slumpmässigt genererade från datan, som ligger i en Array. I linjediagrammet (Figur 20 nedan) visas de 3 respektive mätserierna för MongoDB och Couchbase. Grafen visar att MongoDB har en dubbelt så låg responstid som Couchbase på att hämta data över en befolkningsmängd på samtliga mätserier.
Figur 20 – Mätserier på att hämta data över en befolkningsmängd
20
Figur 21 – Genomsnitt på mätserier på att hämta data över en befolkningsmängd
För att visa spikar på ett tydligt sätt valdes endast en mätserie, mätserie 3. Denna kan man se i figur 22 nedan. På denna graf är spikarna som väcker uppmärksamhet på slutet av Couchbase. Grafen är brusig eftersom det som hämtas är allt över en befolkningsmängd, vilket gör att mängden data som hämtas är annorlunda varje gång.
21
5.3.4.
Resultat och Reflektion
Med mätningarna från denna pilotstudie kan man tydligt visa att MongoDB har en kortare responstid på att hämta data än Couchbase. Viktigt att notera är att en av testerna, hämta all data, inte hade en statistisk skillnad. En slutsats man kan dra från de två andra testerna är att MongoDB är snabbare än Couchbase på att “söka” fram och hämta data. MongoDB hade en ~9x lägre responstid på att hämta data utifrån år och ~1.9x lägre responstid på att hämta data över en viss befolkningsmängd, med en fallande sortering. Det viktiga är att denna pilotstudie visar att studien är utvärderingsbar genom den valda metoden.
Utifrån ovanstående grafer kan man se att Couchbase alltid är runt 500ms. Varför detta är fallet är svårt att säga nu. Men en teori är att Couchbase alltid hämtar all data men endast skickar vidare den filtrerade datan. Medans MongoDB endast hämtar datan som var sökt på. MongoDB verkar alltså vara bättre på att hämta en delmängd av all data. Detta kan undersökas närmare genom att endast hämta ett NoSQL dokument från respektive databas. För att då se om Couchbase fortfarande är runt 500ms.
22
6.
Utvärdering
De ändringarna gjordes efter pilotstudien förklaras. Senare presenteras och analyseras mätningarna från studien.
6.1. Ändringar av mätningar
Efter pilotstudien optimerades mätskripten, och 2 nya endpoints lades till i REST api:t. Den första hämtar ett NoSQL dokument i taget från varje databas genom att söka på dokumentets unika landskod. Den andra som skapades söker också på landskod men visar endast ett fält från datasetet, vilket är befolkningsmängden för varje del av världen. Sedan behövdes även två mätskript skapas med samma struktur som tidigare för kunna testa dessa endpoints. Sättet att mäta ändrades från att dela upp varje sökfråga i 3 mätserier som i pilotstudien till att ha en större mätserie på varje. I denna studie är det nu 6000 mätningar på varje mätserie för varje sökfråga. Vilket kan ses i commit 5f433435. Varje sökfråga har alltså endast en mätserie per databas istället. Scriptet är hårdkodat på 6000 eftersom det genererades 10000 test värden ifall fler skulle behövas senare. Mätskripten optimerades genom att ta bort en tidsbestämd setTimeout för att istället använda asynkron kod, som visas i figur 23 nedan. Detta kan även ses i commit 7120e526.
async function getOne
(database) {
for (let i =
0
; i <
6000
; i++) {
console
.log(i);
await fetchingOne(
`
${pc}${database}
/country-code/`
,
codes[i],
`
${database}
Code`
);
}
}
Figur 23 – Kodsnutt på det uppdaterade asynkrona mätskriptet
6.2. Presentation och analys av mätningar
Fem olika sökfrågor, med fem REST api endpoints för respektive databas, testades med en mätserie på 6000 mätningar var. Ett Anova test utfördes även på varje test där p-värdet visade 0.00 på samtliga. Detta betyder att det finns en statistisk skillnad på alla mätningar. Mellan varje test raderades databaserna och skapades igen, och fylldes då med datasetet igen. Det säkerställdes även att onödiga program var stängda genom aktivitetshanteraren. Även om störningar blir minimerade är det omöjligt att undvika. Så tydliga enstaka spikar i grafer beror förmodligen på en störning i mätningen och kan då säkert räknas bort. Studien utfördes lokalt på samma dator och det blev totalt 10 mätserier med 6000 mätningar i varje. Datorn som genomförde pilotstudien körde Windows 10 Pro version 1903 64-bitar med följande hårdvara: Intel Core i5-7600 3.50 GHz, GTX 1070 och 16GB RAM. Versionerna på databashanterarna är MongoDB Community Server 4.2.3 samt Couchbase Community Edition 6.0.0.
23
6.2.1.
Hämtning av all data
Hela datasetet består av 14,885 NoSQL dokument med en storlek på 1.4MB. Detta hämtades 6000 gånger för MongoDB respektive Couchbase. Dessa mätserier kan man se i linjediagrammet i figur 24 nedan. I grafen syns ett antal spikar. För Couchbase är det de 3 spikarna runt 1000ms som behöver kollas på. Detta är förmodligen på grund av störningar i mätningen och kan räknas bort, samma med MongoDB spiken precis i början.
Figur 24 – Brusdata på att hämta all data
24
Figur 25 – Medelvärde på att hämta all data
6.2.2.
Hämtning av data från ett slumpvis valt år
Denna mätning hämtade all data från ett specifikt år. Det var då 6000 slumpmässigt genererade år som användes för mätningarna. Linjediagrammet i figur 26 nedan visar att Couchbase har en noterbar spik i mitten runt 750ms. Som innan kan detta bero på någon typ av störning i mätningarna men det är enda som sticker ut.
25 Figur 27 nedan visar att Couchbase har ett mycket högre medelvärde på att hämta data baserat på år. MongoDB har en mycket kortare responstid på 21 ms, vilket är ~19.5x snabbare än Couchbase. Couchbase går aldrig ens under 250ms, vilket kan ses i figuren ovan. Standardavvikelsen är även låg på MongoDB samt Couchbase i stapeldiagrammet nedan. Så även fast Couchbase har en mycket långsammare responstid är den stabilt långsammare.
Figur 27 – Medelvärde på att hämta data baserat på år
6.2.3.
Hämtning av data över en slumpvis vald befolkningsmängd
26
Figur 28 – Brusdata på att hämta över en befolkningsmängd
I stapeldiagrammet (figur 29 nedan) är standardavvikelsen för MongoDB relativt stor och överlappar med Couchbase standardavvikelse. Anova testet visade dock ett p-värde på 0.00 vilket påvisar en signifikant statistisk skillnad på mätserierna i denna mätning. Vilket leder till att man fortfarande dra en mer pålitlig slutsats i denna mätning, att just MongoDB är snabbare på att hämta data över en befolkningsmängd och sortera.
27
6.2.4.
Hämtning av enstaka dokument med slumpvis vald landskod
En av de nya funktionaliteterna i REST api:t efter pilotstudien är att hämta ett dokument i taget från respektive databas genom att söka på dess unika landskod. Detta mättes genom att, precis som för alla andra, att slumpmässigt generera 6000 landskoder. I figur 30 nedan kan man se alla mätpunkter där Couchbase har ett mycket större omfång än MongoDB. Inga signifikanta spikar utan det som visas här är att Couchbase är väldigt upp och ner i responstiden på att hämta ett dokument. Mängden data är i princip densamma varje hämtning vilket gör detta resultat svårt att tolka.
Figur 30 – Brusdata på att hämta ett dokument
28
Figur 31 – Medelvärde på att hämta ett dokument
6.2.5.
Hämtning av ett fält med slumpvis vald landskod
29
Figur 32 – Brusdata på att hämta ett fält från ett dokument med landskod
Medelvärdet på mätserierna (figur 33 nedan) följer trenden och Couchbase är mycket långsammare på att hämta data, MongoDB är ~29.8x snabbare på att hämta ett fält. Standardavvikelsen här är även minimal, som indikerar att det borde varit störningar i mätningen i kapitel 6.2.4 ovan.
30
7.
Slutsats
Precis som i pilotstudien är MongoDB snabbare på att hämta data i en Node.js REST api på sökfrågorna som har testats ovan. Dessa mätningar gjordes för att kunna svara på frågeställningen som skapades, “Vilken databashanterare har kortast responstid i att hämta data i en Node.js REST api?”. I pilotstudien upptäcktes det att Couchbase alltid hade en responstid runt 500ms. För att testa detta ytterligare skapades då 2 nya endpoints. Den första endpointen som skapades hämtar ett helt dokument och den andra endpointen hämtar ett fält från ett dokument. Detta visas på figur 31 och 33 ovan. Att Couchbase var snabbare på att hämta ett helt dokument än ett fält är förvånande, men Couchbase hade här en responstid på 211 respektive 402ms. Vilket bevisar att Couchbase endast skickar delmängden av datan som efterfrågas vilket var ett frågetecken som uppstod i pilotstudien.
Det enda testet som Couchbase var nära MongoDB på var att hämta all data. Här var skillnaden endast 30ms på medelvärdet (figur 25). I de andra testen ändras responstiden för MongoDB ganska drastiskt, vilket är logiskt då det är olika delmängder av data som hämtas på sökfrågorna. Det konstiga är då att Couchbase håller sig på en jämnare nivå och går endast under ett medelvärde på 400ms en gång (figur 31 ovan), vilket är i testet som hämtar ett NoSQL dokument i taget.
Utifrån mätningarna som gjorts lutar det mot att mothypotesen, MongoDB har kortare responstid än Couchbase, är sann. Eftersom resultatet på varje test var att MongoDB hade kortare responstid, ofta väldigt mycket kortare, är detta enda slutsatsen som kan dras.
7.1. Sammanfattning
Detta arbete jämförde MongoDB och Couchbase i en Node.js utvecklad REST api, för att se vilken databashanterare som har kortast responstid i att hämta data. Artefakten som skapades var en REST api utvecklad i Node.js ramverket Express. Paketet Mongoose användes till utvecklingen av MongoDB endpointsen. Totalt skapades 5 endpoints till MongoDB respektive Couchbase, som hanterade 5 olika fall:
Hämta data Hämta data på ett år
Hämta data över en befolkningsmängd och sortera i fallande ordning Hämta ett dokument och slutligen
Hämta ett fält från ett dokument
De två sista skapades efter pilotstudien för att kunna testa databashanterarna utförligare, alltså från att hämta all data till att hämta endast ett fält. Studien bestod av 6000 mätningar på varje endpoint. Det var ett teknologi-orienterat experiment som valdes då egna mätskript utvecklades. Exakt det som mättes var tiden det tog att skicka en REST begäran till endpointen, hämta data från databasen och sedan visa det i JSON i webbläsaren.
31
7.2. Diskussion
Băzăr et al (2016) visade i sin studie att Couchbase var bättre på att hämta data än MongoDB, vilket inte alls visades i denna studie. Då MongoDB hade kortare responstid i samtliga test. I sina tester skapade Băzăr et al (2016) scenarier som simulerade att en interaktiv applikation skapades, sedan mättes latens medelvärdet på systemets belastning. I detta arbete testades det annorlunda genom att mäta responstiden i att hämta och visa datan i webbläsaren. Även fast databaserna kördes på samma dator och testades lokalt utan nätverkslagg, kanske de kan konfigureras på andra sätt för att optimera resultatet. I nuläget testades databaserna som de kom utan ytterligare konfiguration. Exempelvis skulle konfigurationen av RAM kunna vara en faktor för ett annat resultat.
Eftersom MongoDB har så mycket snabbare responstid än Couchbase med detta strukturellt enkla dataset på befolkningsdata finns det andra områden och sätt att testa för att få ett bredare resultat, och då se på ett större sätt vilken av dessa databaser som passar i vilken situation. Det självklara är att det endast är hämtning av data som testas i denna studie. Detta är en väsentlig del av en databashanterare. Men de andra grundläggande funktionerna: lägga till, ändra och radera testades ej. Detta är något som borde testas i en större studie. Ett kortsiktigt sätt att utveckla studien är att just testa mer än att hämta data. Denna studie har simpla sökfrågor då datasetet är väldigt enkelt. Att testa med ett mer komplext dataset skulle då vara intressant ur ett långsiktigt perspektiv. Exempelvis flera tabeller som kopplas ihop med ett värde. Eller om datasetet har fler “nivåer”, som Arrays i Arrays. För att då kunna testa mer komplexa sökfrågor. Detta för att se vilken av databashanterarna som kan hantera mer svåra former av datahämtning. Eftersom Couchbase medelvärde på responstiden är nära MongoDB på att hämta all data, kan det då vara av intresse att använda ett större dataset i tester för att se om Couchbase är mer lämplig för att hantera större mängder data.
Något som kan skapa frågetecken kring trovärdighet är just att vissa mätningar hade enstaka spikar, vilket indikerar störningar. Men eftersom de var få och inte speciellt stora kan det inte ha påverkat resultatet mycket egentligen. Speciellt eftersom MongoDB hade mycket kortare responstid på nästan alla mätningar. Ett annat problem kring resultatets trovärdighet är att paketet Mongoose användes för MongoDB, när inget paket användes för Couchbase. Även om det är osannolikt att det har stor effekt på resultatet kan det finnas bakomliggande funktioner i mongoose som gör MongoDB mer effektiv jämfört med Couchbase vanliga kod i Node.js REST api:t.
Kring etiken som skrivits i kapitel 4.2 har ett antal metoder använts för att säkerställa att det följts. Datan som slumpades fram för testen lades i en array för att det skulle vara samma data och i rätt ordning under mätningarna av MongoDB och Couchbase. Databaserna hade samma förhållanden eftersom de kördes på samma dator och de gjordes om mellan varje mätning. För att då säkerställa att ingenting hände i bakgrunden. För att andra ska kunna replikera är koden öppen för alla på Github7.
Samhällsnyttan är att valet av databas i en REST api för utvecklare kan hjälpas åt med resultatet från denna studie. Att MongoDB i samtliga tester är snabbare än Couchbase kan leda till att folk väljer MongoDB ifall de har simpla dataset, som i denna studie. I större drag kan detta leda till nöjdare användare då datan kan hämtas snabbare.
32
Referenser
Bangare, S. L., Gupta, S., Dalal, M. & Inamdar, A. (2016). Using Node.js to Build High Speed and Scalable Backend Database Server. International Journal of Research in Advent Technology (IJRAT), NCPCI 2016. 19 Mars 2016, ss. 61-64.
Băzăr, C., & Iosif, C. S. (2014). The transition from rdbms to nosql. a comparative analysis of three popular non-relational solutions: Cassandra, mongodb and couchbase. Database Systems Journal, 5(2), ss. 49-59.
Bellotti, F., Berta, R., Kobeissi, A., Osman, N., Arnold, E., Dianati, M., Nagy, B. & De Gloria, A. (2019). Designing an IoT Framework for Automated Driving Impact Analysis. 2019 IEEE Intelligent Vehicles Symposium (IV). 9-12 Juni 2019, ss. 1111-1117. IEEE.
doi:10.1109/IVS.2019.8813989
Belqasmi, F., Singh, J., Melhem, S.Y.B., Glitho, R.H. (2012). SOAP-Based vs. RESTful Web Services: A Case Study for Multimedia Conferencing. IEEE Internet Computing, 16(4). ss. 54-63. doi:10.1109/MIC.2012.62
Berners-Lee, T., Fielding, R., & Masinter, L. (1998). Uniform resource identifiers (URI): Generic syntax. https://www.hjp.at/doc/rfc/rfc3986.html#sec_1.1.1 [2020-06-03]
Boicea, A., Radulescu, F., & Agapin, L. I. (2012). MongoDB vs Oracle--database comparison. 2012 third international conference on emerging intelligent data and web technologies, Bucharest, Rumänien 19-27 September 2012, ss. 330-335. IEEE.
doi:10.1109/EIDWT.2012.32
Couchbase (2020). About us | Couchbase. https://www.couchbase.com/about [2020-02-14]
Couchbase (2020b). Couchbase Documentation.
https://docs.couchbase.com/home/index.html [2020-04-17]
Datahub (2020). Population figures for countries, regions (e.g. Asia) and the world. https://datahub.io/core/population [2020-02-14]
Express (2020). Express - Node.js web application framework. https://expressjs.com/ [2020-02-17]
Express (2020b). Express 4.x - API Reference. https://expressjs.com/en/4x/api.html [2020-04-17]
33 Han, J., Haihong, E., Le, G., & Du, J. (2011). Survey on NoSQL database. 2011 6th international conference on pervasive computing and applications, Port Elizabeth, Sydafrika 26-28 Oktober 2011, ss. 363-366. IEEE.
doi:10.1109/ICPCA.2011.6106531
Hahn, E. (2016). Express in Action: Writing, building, and testing Node.js applications. Manning Publications.
Hecht, R., & Jablonski, S. (2011). NoSQL evaluation: A use case oriented survey. 2011 International Conference on Cloud and Service Computing, Hong Kong, Kina 12-14 December 2011, ss. 336-341. IEEE.
doi:10.1109/CSC.2011.6138544
Hubail, M. A., Alsuliman, A., Blow, M., Carey, M., Lychagin, D., Maxon, I., & Westmann, T. (2019). Couchbase analytics: NoETL for scalable NoSQL data analysis. Proceedings of the VLDB Endowment, 12(12), ss. 2275-2286.
doi: 10.14778/3352063.3352143
Kulnarattana, L. & Rongviriyapanish, S. (2009). A client perceived QoS model for web services selection. International Conference on Electrical Engineering/Electronics, Computer, Telecommunications and Information Technology, 6(2). Pattaya, Chonburi, Thailand 6-9 May 2009, ss. 731-734.
doi:10.1109/ECTICON.2009.5137151
Leavitt. N. (2010). Will NoSQL Databases Live Up to Their Promise? Computer, 43(2), 2010. ss. 12-14. IEEE.
doi:10.1109/MC.2010.58
Li, Y. & Sathiamoorthy, M. (2013). A performance comparison of SQL and NoSQL databases. 2013 IEEE Pacific Rim Conference on Communications, Computers and Signal Processing (PACRIM), Victoria, Canada 27-19 Augusti 2013. IEEE.
doi:10.1109/PACRIM.2013.6625441
Masse, M. (2011). REST API Design Rulebook: Designing Consistent RESTful Web Service Interfaces. O'Reilly Media, Inc.
MDN (2020). Using Fetch. https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch [2020-04-07]
MDN (2020b). performance.now(). https://developer.mozilla.org/en-US/docs/Web/API/Performance/now#Example [2020-04-11]
MongoDB, Inc (2020). The database for modern applications. https://www.mongodb.com/ [2020-02-14]
34 Mongoose (2020). Mongoose v.5.9.9. https://mongoosejs.com/docs/guide.html [2020-04-17]
Munonye, K. & Martinek, P. (2018). Performance Analysis of the Microsoft. Net- and Java-Based Implementation of REST Web Services. 2018 IEEE 16th International Symposium on Intelligent Systems and Informatics (SISY), Subotica, Serbien 13-15 September 2018. ss. 197-196. IEEE.
doi:10.1109/SISY.2018.8524705
Nayak, A., Poriya, A., & Poojary, D. (2013). Type of NOSQL databases and its comparison
with relational databases. International Journal of Applied Information, 5(4), Mars 2013. ss.
16-19.
Node.js (2020). About | Node.js. https://nodejs.org/en/about/ [2020-02-14]
Ojamaa, A. & Düüna, K. (2012). Assessing the security of Node.js platform. 2012 International Conference for Internet Technology and Secured Transactions. London, UK 10-12 December 2012. ss. 348-355. IEEE.
Pautasso, C. (2014). Restful web services: principles, patterns, emerging technologies. Web Services Foundations, ss. 31-51. Springer, New York, NY.
Rajamony R. & Elnozahy M. (2001). Measuring Client-Perceived Response Times on the WWW. 3rd USENIX Symposium on Internet Technologies and Systems. San Francisco, USA 26-28 mars, s. 16. ACM.
doi:10.1007/978-1-4614-7518-7_2
Schutt, K. & Balci, O. (2016). Cloud software development platforms: A comparative overview. 2016 IEEE 14th International Conference on Software Engineering Research, Management and Applications (SERA), Towson, MD, USA 8-10 June 2016, ss. 3-13. IEEE.
doi:10.1109/SERA.2016.7516122
Tilkov, S. & Vinoski, S. (2010). Node.js: Using JavaScript to Build High-Performance Network Programs. IEEE Internet Computing, 14(6), November - December 2010. ss. 80-83. IEEE. doi:10.1109/MIC.2010.145s
Wohlin, C., Runeson, P., Höst, M., Ohlsson, M.C., Regnell, B. & Wesslén, A. (2012). Experimentation in Software Engineering. Berlin. Springer.
