Midroc automation uses databases for many different projects, both internally and in customer projects. At present, they are mainly using relational databases. There is an interest in researching different types of databases not based on the relational model. Midroc automation wants to know if there are any advantages of using a non-relational database. This project will compare two different databases. To make this comparison Microsoft SQL and MongoDB has been selected. MongoDB is a document type database which belongs to the category of non-relational databases commonly referred to as NoSQL. An application with a GUI and CRUD operations for each database has been implemented. This implementation was done using C# .NET in Visual Studio. The result of the comparison shows that MongoDB is more flexible while developing a database. It is also easier to make changes to an existing database while working with MongoDB. It is however harder to find information and support online when working with MongoDB. / Midroc Automation använder databaser till många olika projekt, både internt och mot sina kunder. Idag använder de främst databaser baserade på relationsmodellen. De är intresserade av att utreda om det finns några andra typer av databaser som inte är baserade på relationsmodellen och också om dessa skulle innebära några fördelar. I detta projekt kommer man att jämföra två olika databaser. För att göra denna jämförelse har man valt att undersöka Microsoft SQL och MongoDB. MongoDB är en databas av dokumenttyp som tillhör de moderna icke-relationella databaserna kallade NoSQL. För att göra jämförelsen har en applikation med tillhörande GUI och CRUD-operationer implementerats för varje databas. Implementationen har gjorts med hjälp av C# .NET i utvecklingsverktyget Visual Studio. Resultatet av jämförelsen visar att MongoDB är mer flexibelt vid utveckling av databasen. Det är också enklare att göra ändringar till en befintlig databas med MongoDB. Det är dock svårare att hitta information och hjälp online då man utvecklar en Mongo databas.

Database is the important part of modern application. From SQL to RDBMS,database moved to frequently transmit and operate lots of data. On ACID, it is focus on the consistence, but it does not suit right now. In the proposed article, we use YCSB to try some different workloads and the special of Cassandra, MongoDB, HBase, and MySQL Cluster to find the difference between SQL and NoSQL. In addition, we also analyze the performance of the four operations (insert, update, scan, and read) in Cassandra, MongoDB, and HBase, and simulate some conditions. Those test supplies the reference for user to select the database.

Linux network application framework can help programmers developing network service applications on Linux. Programmers can concentrate on the business logic of applications, and do not have to care about network transmission and serialization between client and server. In addition, application¡¦s client and server can be implemented by different programming languages and communicate with each other according to the programming languages supported by framework. This paper chooses Thrift and Etch to be the topic of Linux network application framework, and introduces their interface definition language, serialization and network architecture. This paper also makes experiments on the implementation of MongoDB, choosing of serialization and situation of multiple clients to a single server to get the performances of two frameworks. In general, Thrift has richer features and slightly better performance than Etch.

Sectra has a customer database with approximately 1600 customers across the world. In this system there exists not only medical information but alsoinformation about the environment which the system runs in, usage  pattern and much more. This report is about storing data received from log les into a suitable database. Sectra wants to be able to analyze this information so that they can make strategic decisions and get a better understanding of their customers' needs. The tested databases are MongoDB, Cassandra, and MySQL. The results shows that MySQL  is not suitable for storing large amount of data with the current conguration. On the other hand, both MongoDB and Cassandra performed well with the growing amount of data.

"NoSQL solution" is today a term that represents a wide spectrum of ways of storing and requesting data. From graph-oriented databases to key-value databases, each solution has been developed to be the best choice in a specific case and for given parameters. As NoSQL solutions are new, there is no guide explaining which solution is best depending on someone's use case. In the first part of this document, we give an overview of each type of solution, explaining when and why a certain type of solution would be a good or a poor choice for a given use case. Once a company has chosen the technology that seems to fit well its need, it faces another problem : how to deploy this new type of data store. Directly deploying a production store would certainly result in poor performances, because some pieces of knowledge are absolutely necessary to implement an efficient NoSQL store. However, there is no "best practices" guide to get this knowledge. This is the reason why building a prototype, with fewer resources, can improve everyone's knowledge. Then, with the experience retrieved from this first experience, engineers and technicians can deploy a store that will be much more efficient than the store they would have deployed without the prototype experience. For this reason, we decided to implement a MongoDB prototype store. Building this prototype, we have tested several configurations that resulted in different levels of performance. In the second part of this document, we explain the main result we got from our experiments. These results could be useful for other companies that are willing to use MongoDB, but they mostly show why a specific knowledge is essential to deploy a good NoSQL store.

Speed is a very important factor in websites and other types of applications and almost all applications stores some type of data, normally in a database. For an example a blog typically saves users, posts and comments. There’s a high risk that as the amount of data in the database grows, the time for inserting and requesting specific data increases. If it takes more than some seconds to view a specific page, a user will normally leave the site. However, it’s a fact that the database will grow while the application will become more popular but it’s possible to save a lot of time if using right database, and structure. In this thesis MongoDB and MySQL will be compared with focus on time consumption. SQL (Structured Query Language) is the language which most databases use. This kind of database stores data in structured tables and noting can be added to them if the type of data is incorrect. SQL also support relations between tables. MySQL is a very popular relational database management system (RDBMS) which for example websites frequently makes use of. NoSQL is a new type of databases where the data is stored in collections without any kind of structure, unlike the well known SQL databases where the data is stored in structured tables. Because of the non-structure, these types of databases are designed to be fast and scalable over multiple machines. Mongodb is a such kind of NoSql-database. Tests has been done both on inserting and processing when handling up to 4 millions entities, MongoDB performs better in almost every test. Results shows that the processing time is shorter using MongoDb in the cases that this thesis is covering, and that it’s possible to implement a much fast application when using MongoDb instead of Mysql as database.

Val av databas kan vara ett svårt val då det finns en uppsjö av alternativ. Detta är ett val som alla har framför sig vid skapandet av ett nytt projekt. Denna undersökning av jämförelse med databaser kan underlätta valet av en databas.Genom ett eget experiment av två databashanterare (Mysql och Mongodb), så testades databaserna med läs, skriv och uppdateringsoperationer. En server skapades för att testa databaserna så att en jämförelse kunde ske med latenstider. Med hjälp av tidigare forskning i ämnet så gjordes en jämförelse också.Experimentet visade att Mysql var snabbare och hade lägre latenstider vid läsoperationer, men resultaten från litteraturstudien var oklara eftersom en studie visade på att Mysql var snabbare medan en annan studie visade att Mongodb var snabbare. Resultaten från både experimentet och litteraturstudien visade att vid skriv och uppdateringsoperationer så var Mongodb snabbare med lägre svarstider.Alla resultat i experimentet finns i appendix. / Choosing a database can be a difficult task as there are a plethora of options available. This is a decision that everyone faces when creating a new project. This comparison study of databases can facilitate the choice of a database. Through an own experiment of two database managers (MySQL and MongoDB), the databases were tested with read, write, and update operations. A server was created to test the databases so that a comparison could be made with latency times. Using previous research on the subject, a comparison is also made. The experiment showed that MySQL was faster and had lower latency times for read operations, but the results from the literature study were unclear as one study showed that MySQL was faster while another study showed that MongoDB was faster. The results from both the experiment and the literature study showed that for write and update operations, MongoDB was faster with lower response times. All results from the experiment are available in the appendix.

The main goal of this project has been to investigate how a message queue can be used to handle error codes in log files more actively. The project has followed the Design Science Research Methodology for development and implementation of the solution. A model of the transaction system was developed and emulated in newly developed applications. Two experiments were performed, the first of which tested a longer run time with intervals between messages and the second a time measurement of how long it takes to send 20 000 messages. The first experiment showed that the message queue was able to handle all messages which gave a high throughput of 22.5 messages per second without any messages being lost. The implemented consumer application received all messages and successfully counted the number of error codes in the received data. The experiments that have been carried out have proven that a message queue can be implemented to handle error codes in log files more actively. The future work that can be performed may include an evaluation of the security of the system, comparisons of performance compared to other message queues, performing the experiments on more powerful computers and implementation of machine learning to classify the log data. / Målet med det här projektet har varit att undersöka hur en meddelandekö kan användas för att felhantera felkoder i loggfiler mer aktivt. Projektet har följt Design Science Research Methodology för utveckling och implementering av lösningen. En modell av transaktionssystemet togs fram och emulerades i nyutvecklade applikationer. Två experiment utfördes varav det första testade en längre körning med intervall mellan meddelanden och det andra en tidmätning för hur lång tid det tar att skicka 20 000 meddelanden. Det första experimentet visade att meddelandekön klarade av att hantera meddelanden som skickades över två timmar. Det andra experimentet visade att systemet tog 14 minuter och 45 sekunder att skicka och hantera alla meddelanden, vilket gav en hög genomströmning av 22.5 meddelanden per sekund utan att några meddelanden gick förlorade. Den implementerade mottagarapplikationen tog emot alla meddelanden och lyckades räkna upp antalet felkoder som presenterades i den inkomna datan. De experiment som har utförts har bevisat att en meddelandekö kan implementeras för att felhantera felkoder i loggfiler mer aktivt. De framtida arbeten som kan utföras omfattar en utvärdering av säkerheten av systemet, jämförelser av prestanda jämfört med andra meddelandeköer, utföra experimenten på kraftfullare datorer och en implementering av maskininlärning för att klassificera loggdatan.

It is not always that easy to accurately interpret a parking signs The driver is expected to keep track of what every road sign, direction, prohibition, and amendment means, both by themselves and in combination with each others In addition, the driver must also keep track of the time, date, if there is a holiday, week number, etcs This can make the driver unsure of the rules, or interpret the rules incorrectly, which can lead to hefty fnes or even a towed vehicles By developing a mobile application that can analyze a photograph of a parking sign and quickly give the driver the verdict, the interpretation process can be made easys The purpose of this study has been to examine available technology within image and text analysis and then develop a prototype of an Android application that can interpret a photograph of a parking sign and quickly give the correct verdict, with the help of said technologys The constructed prototype will be evaluated partly by user tests to evaluate the application’s usability, and partly by functionality tests to evaluate the accuracy of the analysis processs Based on the results from the tests, a conclusion was drawn that the application gave a very informative and clear verdict, which was correct most of the time, but ran into problems with certain signs and under more demanding environmental circumstancess The tests also showed that the interface was perceived as easy to understand and use, though less interaction needed from the user was desireds There is a great potential for future development of ParCam, where the focus will be on increasing the automation of the processs / Att tolka en parkeringsskylt korrekt är inte alltid så  enkelt. Föraren förväntas ha koll på vad alla vägmärken, anvisningar, förbud, och tillägg betyder, både för sig själva och i kombination med varandra. Dessutom måste föraren även ha koll på  tid, datum, ev. helgdag, veckonummer m.m. Detta kan leda till att föraren blir osäker på vad som gäller eller tolkar reglerna felaktigt, vilket kan leda till dryga böter och även bortbogserat fordon. Genom att utveckla en mobilapplikation som kan analysera ett fotografi av en parkeringsskylt och snabbt ge svar kan denna tolkningsprocess underlättas för föraren. Syftet med denna studie har varit att utforska befintliga teknologier inom bild- och textanalys och därefter konstruera en prototyp av en Android-app som med hjälp av denna teknologi samt användarens mobilkamera kunna tolka fotografier av en parkeringsskylt och snabbt ge en korrekt utvärdering. Den konstruerade prototypen kommer att utvärderas dels genom användartester för att testa applikationens användbarhet och dels genom analys av utdata för att mäta analysens träffsäkerhet. Från testerna drogs slutsatsen att applikationen gav ett väldigt tydligt och informativt svar där analysen var korrekt de allra flesta gångerna, men stötte på problem med vissa skyltar och under svårare miljöförhållanden. Testerna visade också att gränssnittet upplevdes lätt att använda, men skulle helst kräva mindre inblandning från användaren. Det finns stor utvecklingspotential för ParCam, där fokus kommer att läggas på utökad automatisering av processen.

Context MongoDB is an open-source, scalable, NoSQL database that distributes the data over many commodity servers. It provides no single point of failure by copying and storing the data in different locations. MongoDB uses a master-slave design rather than the ring topology used by Cassandra. Virtualization is the technique used for accessing multiple machines in a single host and utilizing the various virtual machines. It is the fundamental technology, which allows cloud computing to provide resource sharing among the users. Objectives Studying and identifying MongoDB, Virtualization on AWS and OpenStack. Experiments were conducted to identify the CPU utilization associated when Mongo DB instances are deployed on AWS and physical server arrangement. Understanding the effect of Replication in the Mongo DB instances and its effect on MongoDB concerning throughput, CPU utilization and latency. Methods Initially, a literature review is conducted to design the experiment with the mentioned problems. A three node MongoDB cluster runs on Amazon EC2 and OpenStack Nova with Ubuntu 16.04 LTS as an operating system. Latency, throughput and CPU utilization were measured using this setup. This procedure was repeated for five nodes MongoDB cluster and three nodes production cluster with six types of workloads of YCSB. Results Virtualization overhead has been identified in terms of CPU utilization and the effects of virtualization on MongoDB are found out in terms of CPU utilization, latency and throughput. Conclusions It is concluded that there is a decrease in latency and increases throughput with the increase in nodes. Due to replication, increase in latency was observed.