NoSQL is basically a family name for all Database Management Systems (DBMS) that is not Relational DBMS. The fast growth of all social networks has led to a huge amount of unstructured data that NoSQL DBMS is supposed to handle better than Relational DBMS. Most comparisons performed are between Relational DBMS and NoSQL DBMS. In this paper, the comparison is about non-functional properties for different types of NoSQL DBMS instead. Three of the most common NoSQL types are Document Stores, Key-Value Stores and Column Stores. The most used DBMS of those types are MongoDB, Redis and Apache Cassandra. After working with the databases and performing YCSB Benchmarking the conclusion is that if the database should handle an enormous amount of data, Cassandra is most probably best choice. If speed is the most important property and if all data fits within the memory; Redis is probably the most well suited database. If the database needs to be flexible and versatile, MongoDB is probably the best choice.

The goal of this thesis is to design architecture capable of processing big data with focus on data leaks. For this purpose multiple data storage systems were described a and compared. The proposed architecture can load, process, store and access data for analytic purposes while taking into account authentication and authorisation of users and principles of modern agile infrastructure.

Under pandemin COVID-19 har hemsidor skapats som är specifikt framtagna för att visualisera COVID-19 datan. Visualisering av COVID-19 datan kan resultera i en lång väntetid eftersom att det är flera megabytes av data som ska hämtas från en databas. Väntetiden som skapas av att hämta COVID-19 datan från en databas kan resultera i att hemsidan uppfattas som oresponsiv och ur funktion. Därför genomförs experimentet för att komma fram till vilken databas som har kortast hämtningstid när det kommer till COVID-19 data. I experimentet jämförs databaserna MySQL och MongoDB med fokus på hämtningstider vid hämtning av COVID-19 data. Resultatet av experimentet visar att MySQL är databasen med kortast hämtningstider vid hämtning av COVID-19 data. Utifrån hur experimentet genomfördes finns det även många möjligheter för framtida arbeten. Speciellt för att experimentera runt till exempel andra webbläsare och att använda sig av en extern server för att se omändringarna gör skillnad. / <p>Det finns övrigt digitalt material (t.ex. film-, bild- eller ljudfiler) eller modeller/artefakter tillhörande examensarbetet som ska skickas till arkivet.</p>

This master thesis deals with development of a social network for organizing amateurish matches in collective sports. It is implemented in JavaScript. Client side is written in AngularJS framework. Server side is built on Node.js platform, uses framework Express and NoSQL database MongoDB. Resources stored on server are accessible via REST API. The social network integrates some plugins from existing social networks. For example login dialog or share buttons. The created application supports web browsers Google Chrome, Mozilla Firefox and Internet Explorer version 10 or higher.

In der vorliegenden Arbeit werden die Datenbankmanagementsysteme MongoDB, ScyllaDB, OrientDB, Aerospike und Redis mit dem Yahoo! Cloud Serving Benchmark unter der Verwendung von SSD-Speicher getestet. Dazu werden zuerst die verschiedenen NoSQL-Systemtypen beschrieben. Besonderheiten von SSD-Speicher werden zusammengefasst. Anschließend werden Besonderheiten der ausgewählten Datenbankmanagementsystemen und des Yahoo! Cloud Serving Benchmarks beschrieben, um die durchzuführenden Benchmarks zu planen. Weiterhin wird die verwendete Hardware beschrieben, um eine Replikation dieser Benchmarks zu ermöglichen und ein besseres Bild der zu messenden Performance zu bieten. Nach der Planung der Durchführung der Benchmarks, werden die verschiedenen Datenbankmanagementsysteme auf der oberen Grenze getestet, welche die gegebene Hardware bietet. Mit den Ergebnissen dieser werden weitere Benchmarks unter diversen Bedingungen geplant und durchgeführt. Die Ergebnisse werden jeweils ausgewertet und in dieser Arbeit eingebunden. Diese sind von den gegebenen Umständen stark beeinflusst, sodass allgemeingültige Aussagen nicht möglich sind. Zuletzt wird im Ausblick, welche inhaltliche Lücken und Fragen offen stehen oder weitere zusammenhängende Problemstellungen beschrieben.:1 Einleitung 1.1 Motivation 1.2 Vorgehensweise 2 Gegenstand des Benchmarks 2.1 Modell 2.1.1 Key-Value Store 2.1.2 Document Store 2.1.3 Wide-Column Store 2.1.4 Graph Store 2.1.5 Multi-Model 2.2 Medium 2.2.1 SSD 2.2.2 In-Memory 3 Technische Randbedingungen des Benchmarks 3.1 Ausgewählte Datenbankmanagementsysteme 3.2 Yahoo! Cloud Serving Benchmark 3.3 Genutzte Hardware 3.4 Testlauf des Benchmarks 3.5 Erzielter Vergleich 4 Erste Testreihe: 150GB 21 4.1 Aufgetretene Probleme 4.2 Verwendete Einstellungen 4.3 Ergebnisse: erster Versuch 4.4 Ergebnisse: 150GB 5 Testreihen: Übergreifende Szenarien 5.1 Testreihe 50GB 5.2 Testreihe 10GB 5.3 Testreihe Großes Feld 5.4 Testreihe Sekundärindex 5.5 Testreihe Latenz 5.6 Testreihe Discord 6 Ergebnisse DBMS-intern 6.1 MongoDB 6.2 ScyllaDB 6.3 OrientDB 6.4 Aerospike 6.5 Redis 7 Schlussteil 7.1 Auswertung 7.1.1 YCSB-Tool 7.1.2 MongoDB 7.1.3 ScyllaDB 7.1.4 Aerospike 7.1.5 OrientDB 7.1.6 Redis 7.1.7 SSD-Speicher 7.2 Zusammenfassung 7.3 Ausblick

Elektricitet är någonting vi alla använder dagligen och eftersom elpriserna varierar över tid kan det bli dyrt för vissa hushåll. Det finns många tillvägagångssättför att dra ner på elkonsumtionen och det finns även smarta tekniker som Smart Grid anpassar elkonsumtionen utifrån elpriser. Dessa smarta enheter kommunicerar med Smart Grid control centers databas för att koordinera dess körtid. Problemet är att för att denna lösning ska vidhålla en långtidslösning måste databaserna utföra operationer med låga svarstider. I studien utförs experiment som undersöker vilkenav databaserna MySQL eller MongoDB är mest lämpad och ger svar på hypotesen “För denna undersökning kommer MongoDB att prestera med lägst svarstider”. Detta undersöks genom att jämföra svarstider mellan respektive databas ochresultatet visar att MySQL presterar bättre än MongoDB vid hantering av elpris data. I framtiden vore det intressant att använda andra databaser samt andra tillvägagångssätt för att hantera datan. / <p>Det finns övrigt digitalt material (t.ex. film-, bild- eller ljudfiler) eller modeller/artefakter tillhörande examensarbetet som ska skickas till arkivet. / There are other digital material (eg film, image or audio files) or models/artifacts that belongs to the thesis and need to be archived.</p>

Students wishing to attend student events, as well as the event organisers, currentlyface several inconveniences at the sign-up occasion, due to prevailing solutions’ lack ofdeep consideration for efficiency. This report investigates how a web-based sign-up appli-cation for student events can be implemented to handle high server traffic, by developingand testing a solution that allows for a quick sign-up process, payment directly at the sign-up occasion and the gathering of relevant attendee information.By considering code optimization strategies and the change of database from SQLite toMongoDB, based on the prevailing literature on the topic, a test script together with hightraffic testing was utilised to measure the relative performance of each of these implemen-tations, relative to the initial web-application. Results show that all four aspects tested weresignificant in terms of improving the handling of high traffic. Based on this, the conclusiondrawn was that all four aspects: time optimization, space optimization, minification, and adocument-based database, should be considered when improving a web-application thatallows for handling of high traffic. This finding confirms the prevailing literature on thetopic, however, the implementation phase also raised suggestions for future and improvedresearch on the topic. / Studenter som önskar gå på studentevent, likväl som eventorganisatörerna, möts idagsläget av flertalet olägenheten vid anmälningstillfället, eftersom nuvarande lösningarsaknar djupare hänsyn till effektivitet. Denna rapport undersöker hur en web-baserad an-mälningsapplikation för studentevent kan implementeras för att hantera hög servertrafik,genom att utveckla och testa en lösning som tillåter en snabb anmälningsprocess, betalningdirekt vid anmälningstillfället och insamling av relevant deltagarinformation. Genom att tahänsyn till kodoptimeringsstrategier och byte av databas från SQLite till MongoDB, baseratpå tidigare literatur om området, så används ett testskript och ett test för hög servertrafikför att mäta den relativa prestandan av vardera implementation, relativt till den initialaimplementationen. Resultatet visar att alla fyra undersökta aspekterna var signifikanta föratt förbättra hanteringen av hög trafik. Baserat på detta drogs slutsatsen att alla fyra aspek-terna: “time optimation”, “space optimization”, “minification” och en dokumentbaseraddatabas, borde tas hänsyn till när man implementerar en webbapplikation som tillåter förhantering av hög trafik. Denna upptäckt bekräftar den tidigare litteraturen om områden,men, implementationsfasen lyfte även förslag för framtida och förbättrad forskning på området.

Förmågan att lagra data är en stor bidragande faktor till att vetenskapen ständigt rört sig framåt. Under några tusen år har människan utvecklats från att lagra data på grottväggar till hårddiskar och kraven på prestanda, tillgång och felsäkerhet ökar i rasande takt. För att hantera data i det moderna samhället utvecklas ständigt nya metoder och en av dessa metoder är replikation. Den här undersökningen testar hur replikation påverkar prestandan i en distribuerad MongoDB-lösning. Testerna i undersökningen är automatiserade och körs mot databasen i olika konfigurationer för att se hur prestandan förändras. / The ability to store data is a contributing factor in making science constantly move forward. In a few thousand years man has evolved from storing information on cave walls to hard drives and requirements in performance, availability and fault tolerance are rapidly increasing. To manage information in modern society new methods are constantly evolving and one of these methods is replication. This study tests how replication affects the performance in a distributed MongoDB solution. The tests in this survey are automated and run against the database in different configurations to see how performance changes.

When storing and handling Big Data sets a database management system (DBMS) can be implemented to administrate and query databases. The Swedish Internet is a big unstructured data set that contains all published Swedish Websites since the late 1990’s. NoSQL DBMSs such as MongoDB and CouchDB are particularly suited to store the Swedish Internet. Comparing the search performance of MongoDB and CouchDB in this scenario required the insertion of a subset of the Swedish Internet, querying of the data and measuring the search performance. The results show that CouchDB has in general a superior performance but comes with a drawback which is its indexation time. If a query will only be executed a few amount of times MongoDB is generally the better choice. Further studies needs to be conducted in order to assess the performance of NoSQL DBMSs over the whole dataset.

O acesso a dados baseado em ontologia (OBDA, de Ontology-Based Data Access) propõe facilitar ao usuário acesso a dados sem o conhecimento específico de como eles estão armazenados em suas fontes. Para isso, faz-se uso de uma ontologia como camada conceitual de alto nível, explorando sua capacidade de descrever o domínio e lidar com a incompletude dos dados. Atualmente, os sistemas NoSQL (Not Only SQL) estão se tornando populares, oferecendo recursos que os sistemas de bancos de dados relacionais não suportam. Desta forma, surgiu a necessidade dos sistemas OBDA se moldarem a estes novos tipos de bancos de dados. O objetivo desta pesquisa é propor uma arquitetura nova para sistemas OBDA possibilitando o acesso a dados em bancos de dados relacionais e bancos de dados NoSQL. Para tal, foi proposta a utilização de um mapeamento mais simples responsável pela comunicação entre ontologia e bancos de dados. Foram construídos dois protótipos de sistemas OBDA para sistemas NoSQL e sistemas de bancos de dados relacional para uma validação empírica da arquitetura proposta neste trabalho. / Ontology-based data access (OBDA) proposes to facilitate user access to data without specific knowledge of how they are stored in their sources. For this, an ontology is used as a high level conceptual layer, exploring its capacity to describe the domain and deal with the incompleteness of the data. Currently, NoSQL (Not Only SQL) systems are becoming popular, offering features that relational database systems do not support. In this way, the need arose for shaping OBDA systems to deal with these new types of databases. The objective of this research is to propose a new architecture for OBDA systems allowing access to data in relational databases and NoSQL databases. For this, we propose the use of a simpler mapping responsible for the communication between ontology and databases. Two OBDA system prototypes were constructed: one for NoSQL systems and one for relational database systems for an empirical validation.