Academic literature 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.