Dissertations / Theses on the topic 'NoSQL-databaser'

Syftet med studien är att göra en fördjupning inom NoSQL-databaser och undersöka vilka uppgifter som de olika NoSQL-grupperna passar bäst till i ett socialt nätverk, som t.ex. Facebook och Twitter. Det finns fyra olika typer av NoSQL-databaser: kolumndatabaser, grafdatabaser, nyckelvärdedatabaser och dokumentdatabaser. Frågan är vilken NoSQL-databas ska man välja till en viss uppgift i ett givet socialt nätverk. När man ska utveckla ett socialt nätverk, som kräver lagring av data, är det viktigt att känna till vilken typ av databas som bör användas till en vis typ av uppgift. För att få svar på frågorna har det gjorts en undersökning över vad tidigare forskning har kommit fram till. Det har även gjorts en praktisk studie med alla fyra NoSQL-grupper i ett experiment med lagring av användaruppgifter, meddelanden och vänner.
The purpose of the study is to deepen within NoSQL databases and investigate what tasks the different NoSQL groups fit best in a social network, such as Facebook and Twitter. The data is, for example, about the storage of personal data or social networking. There are four different types of NoSQL databases: column databases, graph databases, key value databases and document databases. The question is which NoSQL database should be chosen for a particular task in a given social network. When developing a social network that requires data storage, it is important to know what kind of database should be used for a certain type of task.In order to answer the questions, an investigation has been made of what previous research has reached. There has also been a practical study of all four NoSQL groups in an experiment with storing user information, messages and friends.

Arbetet jämför fyra olika NoSQL-databaser med fokus på tidseffektivitet. De fyra databaserna är MongoDB, RavenDB, ArangoDB och Couchbase. Studien består av en benchmark för att mäta tidseffektiviteten av de fyra databaserna och en litteraturstudie av hur tidseffektiviteten påverkas av optimeringslösningar. Tillsammans bidrar dessa metoder till en slutsats från båda perspektiven då de kompletterar varandra och ger en grund för resultatets betydelse. Arbetets grund ligger i ett tidigare examensarbete som går ut på att jämföra en SQL-databas mot en NoSQL-databas med en benchmark. Resultatet av studien visar att för de flesta databaser så ökar söktiden för en query i korrelation med ökningen av query-komplexiteten, och att tidseffektiviteten mellan de olika databaserna varierar vid sökningar med hög komplexitet. Framtida arbeten som kan baseras på denna studie är att göra en liknande benchmark på ett dataset som är större eller att en annan typ av databas används.

Den allmänna kunskapen om NoSQL-databaser är begränsad. Den här uppsatsen koncentrerar sig på att sammanställa egenskaper och information om för- och nackdelar som rör dessa databastyper samt relationsdatabaser i en undersökning. Uppsatsen belyser även användningsområden för de olika databastyperna och i en fallstudie testas en grafdatabas förmåga att representera och utföra sökningar av data från ett järnvägsspårnät. Problemområdena undersöktes genom att samla information om olika typer av databaser från artiklar och böcker. Tillämpningsfallet i fallstudien implementerades och testades i en grafdatabas. Resultatet av undersökningen visade att NoSQL-databaser är ett intressant alternativ i vissa fall men att mycket hänsyn måste tas innan man väljer vilken typ av databas som är mest lämpad i den specifika tillämpningen. Resultatet av fallstudien visar att en grafdatabas är särdeles lämpad för att representera och utföra operationer på ett transportnätverk. Detta till stora delar beroende på dess förmåga att representera kopplingarna i ett transportnätverk och i form av de operationerna som finns i grafteorin och som grafmodellen erbjuder.Nyckelord: nosql, relationsdatabas, nyckel/värde-databas, kolumndatabas, objektdatabas, dokumentdatabas, grafdatabas, järnvägsnätverk, transportnätverk

This study presents perceptions towards non-relational, or just NoSQL, databases in IT- and Business Intelligence companies, where we try to determine the need for NoSQL databases in these areas. Earlier studies indicate that the rise of Big Data will force companies to sooner or later expand their data storages to be able to handle the vast amount of data that will emerge, and to find ways to easily manage it. With this in mind, we wanted to determine why some Business Intelligence-companies still had not implemented non-relational databases in their systems, what this would implicate and how necessary it actually is. Our study included a case study at a Business Intelligence-company that still had not adopted these relatively new kinds of databases. First we used a survey to get an idea of what kind of knowledge concerning NoSQL-databases the employees at the company actually had, and to help us create questions for the interviews that would be the next step in our study. Through the interviews we had with three consultants and two developers we gathered a lot of interesting data concerning the company’s attitude towards implementing alternative databases in the system as a complement to their current SQL-based databases. For example, the low level of knowledge about NoSQL-databases of the employees showed a lot of preconceptions and assumptions about these alternative databases, that by extension led to a very skeptical attitude towards them. We learned however that the employees, especially the consultants, worried about the growing amount of data, which already was becoming laborious, and we estimate that companies that has not adopted a solution for this will eventually reach an inflection point where the amount of data will exceed the company’s ability to handle it.

På grund av rådande pandemi (covid-19) hölls Studentkonferens Examensarbete i informatik 2020 genom videokonferens (Zoom)

Purpose – The purpose of this study is to recommend a database and its belonging database model which is optimized for a sensor system. There is a lack of comparisons for databases and data models for bigger sensor systems. The study also brings scientific support for whom wishes to build a sensor system like the one which is included in this paper. Method – This paper starts with a literature study, which purpose is to choose the databases and the database models to be included in the comparison. To achieve the purpose of the study, a quantitative approach has been chosen. The study follows the steps that defines an experimental study within software development according to Shari Lawrence Pfleeger. Four predefined cases are used to compare the databases and the different database models which has been obtained in the literature study. Findings – The literature study shows that Time Series DBMS is the recommended database model to use for implementing sensor systems. The findings of the study also show that TimescaleDB is the preferable database over InfluxDB in four of four predefined cases. The null hypothesis which has been admitted is rejected and the alternative hypothesis is accepted at 1% significance level. Implications – The implications of the paper is to enhance the knowledge about Time Series DBMS, specifically of TimescaleDB and InfluxDB for sensor systems. The result can be implemented and used when resembling sensor systems are created. According to the result of the experiment it is shown that TimescaleDB is better than InfluxDB for sensor systems with similar datastructure. Limitations – Two Time Series DBMS (TimescaleDB and InfluxDB) were used in the experiments in this paper. The experiments was is carried out in Azure and is limited to 10 vCPU:s that a standard account have access to. There were not many beacons available to use for creating testdata. Files with corresponding data that the beacon sends out was created to simulate beacons. Keywords – Time Series DBMS, NoSQL, RDBMS, TimescaleDB, InfluxDB, Sensor systems
Syfte – I problembeskrivningen framgår att det finns brist på vetenskapligt underlag för vilken sorts databas som är optimal att använda för ett sensorsystem. Det saknas jämförelser av prestanda mellan olika databaser och datamodeller i större sensorsystem. Studiens syfte är: ”Att rekommendera en databas och tillhörande databasmodell som är optimerad för ett sensorsystem” Metod – Studien inleds med en litteraturstudie för att genom teorin välja databas och databasmodeller som ska ingå i studien. För att uppnå syftet har en kvantitativ ansats valts. Studien följer de steg som Shari Lawrence Pfleeger definierar som en experimentell studie inom mjukvaruutveckling. Fyra fördefinierade fall används för att jämföra databaserna med olika databasmodeller som erhållits i litteraturstudien. Resultat - Litteraturstudien visar att Time Series DBMS är den databasmodell som rekommenderas att användas i ett sensorsystem. Studiens resultat visar att TimescaleDB presterar bättre än InfluxDB i fyra av fyra fördefinierade fall. Nollhypotesen som har ställts upp förkastas och en mothypotes antas vid 1% signifikansnivå. Implikationer - Studiens implikationer är att öka och fylla vissa kunskapshål kring Time Series DBMS, specifikt TimescaleDB och InfluxDB för sensorsystem. Resultatet kan tillämpas och användas när liknande sensorsystem skall implementeras. Enligt experimentets resultat visar det att TimescaleDB är bättre än InfluxDB för sensorsystem med liknande struktur. Begränsningar – Två Time Series DBMS (TimescaleDB och InfluxDB) ingår i denna studie som experimenten utfördes på. Experimenten utföres i Azure och var begränsade av de 10 vCPU:erna ett standardkonto har tillgång till att använda. Det fanns inte tillgång till ett stort antal beacons för att generera data till experimenten, så filer med motsvarande data skapades för att simulera beacons.  Nyckelord - Time Series DBMS, NoSQL, RDBMS, TimescaleDB, InfluxDB, Sensorsystem

Följande arbete jämför databashanterarna MongoDB och Couchbase responstid i att hämta data i en Node.js REST api. Datasetet har en enkel struktur och består av befolkningsdata. Jämförelsen ska svara på vilken av dessa databashanterare som har kortast responstid i att hämta befolkningsdata i en Node.js REST api, eftersom responstiden är väldigt viktig för användare. Testet sker med egenutvecklade script och mäter tiden det tar att skicka en begäran till REST api:t och visa den hämtade datan på webbläsaren. REST api:t består av 5 endpoints vilket testades 6000 gånger var för MongoDB och Couchbase. MongoDB hade kortast responstid på samtliga test. I framtida arbeten kan resten av CRUD operationerna testas och då inte bara att hämta data, långsiktig kan datasetet ändras för att kunna testa mer komplexa sökfrågor.

Trafiken till webbapplikationer ökar därför ställs det högre krav på att svarstiderna för användaren hålls nere även fast det blir högre trafik och mer data som behöver laddas till webbapplikationerna. Där det vanligaste språket för att hämta data ifrån databaser är PHP som är ett språk som varit med i många år. När det nu finns möjlighet till att skiva all kod i ett och samma språk som JavaScript med Node.js är frågan hur PHP står sig emot JavaScript i svarstider för användaren. Det blir också vanligare med NoSql databaser istället för RDBMS Detta arbete gör ett experiment där JavaScript och PHP ställs emot varandra och kollar hur dom påverkar svarstider. Där även programmeringspåken tar användning av en RDBMS och en NoSql databas. Där resultatet visar på att det inte går att skilja dom åt om man kollar på svarstider.

I detta arbete undersöks det hur en NoSQL-databas presterar jämfört med en relationsdatabas när kommunikation sker med en webbapplikation. Testning sker med hjälp av en PHP-applikation och Ajax för att simulera användningen av en webbapplikation. Den data som kommer lagras i databaserna kommer vara strukturerad och databaserna kommer vara på ett odistribuerat system. Metoden är teknikorienterade experiment men för framtida arbeten kan dessa tester utföras som en fallstudie för att ytterligare simulera en skarp användning av en webbapplikation.I detta arbete förklaras anledningen till framtagningen av NoSQL-databaser. Saker som diskussionen om att NoSQL kommer ta över platsen som de mest använda databaserna från relationsdatabaser tas också upp. Förhoppningsvis kan detta arbete ge viss insikt till den diskussionen.Resultatet av detta arbete visar att NoSQL kan passa bra för databaser som har en last som ärskriv- och uppdateringstung, men också att relationsdatabaser fortfarande passar bra i många fall.

För att spara tid och pengar i ett utvecklingsskede av en applikation, kan med fördel redan befintliga teknologier användas. För att skapa en arkivapplikation där användaren kan titta på och tanka hem arkiverat material utan för stora tidsförluster så krävs teknologier som klarar detta. Teknologin måste även klara av att hantera stora mängder data då arkivering av webben gör att datamängderna i arkivet hela tiden ökar. En teknologi som uppfyller kriterierna i OAIS-modellen som är en standard för arkivering och som kan hantera stora mängder data är NoSQL-databaser. Dessa finns i olika utföranden och är olika svåra att hantera. Denna studie har fokuserat på två populära dokumentbaserade NoSQL-databaser som är lätta att installera och relativt enkla att hantera. Vilken av dessa två NoSQL-databaser är då lämpligast för en applikation som skall lagra webbinnehåll? Frågan besvaras genom ett experiment vars inriktning är att utröna hur de två NoSQL-databaserna fungerar som arkivmedium. Utifrån studiens analys kan svaret ges att de fungerar olika bra i olika situationer. Skall applikationen användas för att lagra relativt små filer i form av PDF eller TXT så är MongoDB det bästa valet av de två. Om det däremot skall hanteras större filer så är CouchDB det bättre valet.

Database security is vital to retain confidentiality and integrity of data as well as prevent security threats such as privilege abuse. The most common form of privilege abuse is excessive privilege abuse, which entails assigning users with excessive privileges beyond their job function, which can be abused deliberately or inadvertently. The thesis’s objective is to determine how to prevent privilege abuse in the NoSQL database MongoDB. Prior studies have noted the importance of access control to secure databases from privilege abuse. Access control is essential to manage and protect the accessibility of the data stored and restrict unauthorised access. Therefore, the study analyses MongoDB’s embedded access control through experimental testing to test various built-in and advanced privileges roles in preventing privilege abuse. The results indicate that privilege abuse can be prevented if users are granted roles composed of the least privileges. Additionally, the results indicate that assigning users with excessive privileges exposes the system to privilege abuse. The study also underlines that an inaccurate allocation of privileges or permissions to users of databases may have profound consequences for the system and organisation, such as data breach and data manipulation. Hence, organisations that utilise information technology should be obliged to protect their interests and databases from others and their members through access control policies.
Datasäkerhet är avgörande för att bevara datats konfidentialitet och integritet samt för att förhindra säkerhetshot som missbruk av privilegier. Missbruk av överflödig privilegier, är den vanligaste formen av privilegier missbruk. Detta innebär att en användare tilldelas obegränsad behörighet utöver det som behövs för deras arbete, vilket kan missbrukas medvetet eller av misstag. Examensarbetets mål är att avgöra hur man kan förhindra missbruk av privilegier i NoSQL-databasen MongoDB. Tidigare studier har noterat vikten av åtkomstkontroll för att säkra databaser från missbruk av privilegier. Åtkomstkontroll är viktigt för att hantera och skydda åtkomlighet för de lagrade data samt begränsa obegränsad åtkomst. Därför analyserar arbetet MongoDBs inbäddade åtkomstkontroll genom experimentell testning för att testa olika inbyggda och avancerade priviligierade roller för att förhindra missbruk av privilegier. Resultaten indikerar att missbruk av privilegier kan förhindras om användare får roller som har färre privilegier. Dessutom visar resultaten att tilldelning av användare med obegränsade privilegier utsätter systemet för missbruk av privilegier. Studien understryker också att en felaktig tilldelning av privilegier eller behörigheter för databasanvändare kan få allvarliga konsekvenser för systemet och organisationen, såsom dataintrång och datamanipulation. Därför bör organisationer som använder informationsteknologi ha som plikt att skydda sina tillgångar och databaser från obehöriga men även företagets medarbetare som inte är beroende av datat genom policys för åtkomstkontroll.

I denna rapport jämförs Azure SQL Database med NoSQL lösningen DocumentDB, under förutsättningarna givna av ett turbaserat flerspelarspel. NoSQL är en relativt ny typ av databas, som till skillnad från dess relationsbaserade kusin har nya lovord angående fantastisk prestanda och oändlig skalbarhet. Det sägs att det är skapt för dagens problem utan gårdagens begränsningar. Warmkitten vill ta reda på om löftena kring NoSQL håller i deras scenario. Eller om den nuvarande SQL lösningen är en bättre match för deras spel med tanke på skalning, snabbhet och anvädningen utav .NET. Jämförelsen gjordes genom att först skapa ett testramverk för spelets flerspelar funktioner. Sedan optimerades både den relations- och den icke-relationsbaserade lösningen, baserat på rekommendationer och experters utlåtande. Testerna kördes sedan under förhållanden som skulle återspegla verkligheten. Rapporten visar att denna nya typ utav databaser helt klart är mogna nog att i vissa scenarion användas istället för de relationsbaserade databaserna, givet att tillräckligt mycket tid ges åt att förstå skillnaderna mellan databastyperna och vad det innebär. Extra betänketid bör läggas på hur NoSQL skalar samt vilka skillnader som det innebär när relations-begränsningarna försvinner. Prestandamässigt så är DocumentDB snabbare under normal användning när det finns lugnare stunder, SQL är bättre för applikationer som behöver köra under långa stunder med hög användning utav databasen. Rapportens slutsats blir en rekommendation till Warmkitten att fortsätta med den redan utvecklade SQL lösningen. Detta då prestandaförbättringarna från NoSQL inte väger upp för den ökade transaktionskomplexiteten, då spelet använder transaktioner i hög utsträckning.
This paper was created to compare Azure SQL Database to the Azure NoSQL solution DocumentDB. This case study is done in the scope of a turn-based multiplayer game created by Warmkitten. NoSQL is a new type of databases, instead of the relational kind we are used to, this new type gives promises of increased performance and unlimited scalability. It is marketed that it is created for the problems of today and not bound by yesterday’s limitations. Warmkitten would like to gain insight if the promises from NoSQL holds for the game they are developing or if the current SQL solution fit their needs. They are most interested in the areas of scaling, performance and .NET interoperability. The comparison was carried out by creating a test suite testing the game functionalities. Then both the SQL and NoSQL solution was optimized based on best practices and expert guidelines. The tests were then run under circumstances mimicking real-world scenarios. The paper shows that NoSQL is a valid replacement to SQL, if enough time and thought is put into the implementation. Given that NoSQL is a good fit for the problem at hand. Our paper shows that performance wise NoSQL is faster under normal load when there are times with less load, SQL is better for applications that will have continuously heavy load. The final verdict of this paper is a recommendation for Warmkitten to continue using SQL for their game. This is because the recorded performance improvements does not outweighs the transactional problems seen in this case study created by the transactional nature of the game.

This work was carried out for Cisco at the Tail-f department. Cisco’s main focus is on network and telecommunication. The Tail-f department is the developer of a network service automatization product that allows customers to automate the process of adding, removing and manage their developed devices and services in their network. In the context of this network service, notifications will arise to notify operators when something has happened. The notifications are currently stored in a configurational database that is currently used for all the data in the network service. The customers have wished for more flexibility and functionality in terms of operating the notification data since they are limited in what queries they may perform in order to analyze their data. The purpose of this project is to find an alternative way of storing the notifications with better functionality and efficiency. A number of different databases were investigated with respect to the functionality and performance requirements of the system. A final storage system ElasticSearch was chosen. ElasticSearch provides flexible schema handling and complex queries which makes it a suitable choice that fulfills the customers’ needs. A generator and subscriber program were built in order to perform tests and insertion of notification data into ElasticSearch. The generator creates notifications manually and the subscriber receives them and performs some parsing and insertion into the storage. The queries and performance of ElasticSearch was measured. The query results show that the new system is able to perform much more complex queries than before such as range queries, filtering and full-text searches. The performance results show that the system is able to handle around 1000 notifications every other millisecond before the system will slow down. This is a sufficient number that satisfies the customers’ needs.
Detta arbete utfördes för Cisco vid Tail-f avdelningen. Cisco fokuserar på nätoch telekommunikation. Tail-f är utvecklare av en automatiseringsprodukt för nätverk som gör det möjligt för kunder att automatisera processen att lägga till, ta bort och hantera sina utvecklade enheter och tjänster i deras nätverk. I samband med nätverkstjänsten kommer notifikationer att meddela operatörer när något har hänt.Meddelandena lagras för tillfället i en konfigurationsdatabas som för närvarande används för lagring av all data inom nätverkstjänsten. Kunderna har önskat efter mer flexibilitet och funktionalitet när det gäller att hantera datat eftersom de är begränsade i vilka sökfrågor de kan utföra för att analysera deras notifikationsdata.Syftet med detta projekt är att hitta ett alternativt sätt att lagra notifikationerna med bättre funktionalitet och effektivitet. Ett antal olika databaser undersöktes med avseende på systemets funktionalitet och prestandakrav. Ett slutgiltigt lagringssystem ElasticSearch valdes. ElasticSearch erbjuder flexibel schema-hantering och komplexa sökfrågor som gör det till ett lämpligt val som uppfyller kundernas behov. En generator och subscriber program utvecklades för att utföra test och införande av notifikationsdata i ElasticSearch. Generatorn skapar meddelanden manuellt och subscribern tar emot dem och utför viss parsing och insättning i lagringssystemet.Sökfrågor och prestanda för ElasticSearch mättes. Sökfrågans resultat visar att det nya systemet kan utföra mycket mer komplexa sökfrågor än tidigare, såsom intervall-sökningar, filtrering och full-text sökning. Resultatet visar att systemet kan hantera cirka 1000 notifikationer varannan millisekund innan systemet saktar ner. Detta är ett tillräckligt antal som uppfyller kundernas behov.

Creating a database to manage medical data is not the easiest. We create a database to be used for a presentation tool that presents medical data about patients that is stored in the database. We examine which of the three databases, MySQL with relational design, MySQL with EAV design and MongoDB that are best suited for storing medical data. The analysis i performed in two steps. The first step handles the database that is most effective to retriev data. The second step examines how easy it is to change the structure of the various databases. The results show that depending on whether efficiency or maintenance is most important, different databases are the best choise. MySQL with relational design proves to be most effective while MongoDB is the easiest to maintain.

Abstract As a developer of database-driven applications you will be faced with difficult choices, when it comes to choosing database, server and programming language. For the result to be satisfactory it requires the different techniques to interact well with each other and also fulfill performance expectations. This is even more important when the application is deployed to the cloud and the response time plays a major role.This paper evaluates different databases and their performance. To test the databases there was an application made in the server script language PHP or Hypertext Preprocessor and it was deployed to Windows Azure cloud platform. The test applications task is to call and load databases by controlled requests which creates, reads, updates and deletes data in an relatively large extent.The results shows that locale databases or databases in the same data center as the server generates the fastest response. The diffrence between NoSQL and SQL is practically nothing when it comes to simple requests. The type of data and the type of usage are major factors in the choice between the two databases.This paper works as a guidance in the choice of database for development of applications in the cloud. Keywords: SQL, NoSQL, databas, cloud, Azure, CouchDB, IrisCouch, database.com, databaseperformance
Abstrakt Som utvecklare av databasdrivna applikationer ställs man inför avgörande val när det kommer till databas, server och programmeringsspråk. För att resultatet ska bli en väl fungerande applikation krävs det att alla tekniker interagerar på ett bra sätt med varandra samt att de uppfyller vissa prestandakrav. Detta blir än viktigare när applikationen lyfts ut i molnet och svarstider spelar en stor roll.I arbetet undersöks olika databasers svarstider med hjälp av en testapplikation som är skriven i scriptspråketet PHP och driftsatt på Windows Azure-plattformen. Applikationens uppgift är att anropa och belasta databaser genom att genomföra kontrollerade operationer som skapar, hämtar, uppdaterar eller tar bort data i relativt stor omfattning.De databaser som praktiskt testats och utvärderats är Azure Table, Azure SQL, CouchDB, IrisCouch samt Database.com.Resultaten visar att lokala databaser, eller databaser inom samma datacenter som servern, generar de snabbaste responstiderna. Skillnaderna mellan NoSQL och SQL är i det närmaste försumbara när det handlar om enklare operationer. I valet mellan de två handlar det i mångt och mycket om vad databaserna ska användas till samt vilken typ av information som ska lagras i dem.Arbetet är tänkt att fungera som en vägledning i valet av databas vid utveckling av molntjänster. Nyckelord: SQL, NoSQL, databas, moln, Azure, CouchDB, IrisCouch, database.com, databasprestanda

Denna studie har undersökt vilken av CouchDB och MongoDB som har lägst svarstider vid hantering av filformaten epub, mobi, txt och html. De operationer som har undersökts är insert, update, select och delete för att se vilken av databaserna som presterar kortast svarstid. Resultatet av undersökningen är att databaserna är bra på olika saker där CouchDB presterade bättre vid inmatning av epub, txt och html-formaten samt vid uppdatering och borttagning av alla format. MongoDB presterade däremot bättre vid hämtning av alla filformaten vilket gör att databaserna är bra i olika situationer beroende på vad databasen ska användas till. Om databasen kommer att utföra många select-operationer passar MongoDB bäst medans vid borttagning och uppdatering passar CouchDB bäst. Vid inmatning beror det på vilket filformat som kommer hanteras mest då databaserna presterade liknande resultat för mobi-formatet medans CouchDB presterade bättre vid de andra formaten.