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.

Context. In the field of computer science, the concept of cloud computing plays a prominent role which can be hosted on the internet to store, manage and also to process the data. Cloud platforms enables the users to perform large number of computing tasks across the remote servers. There exist several cloud platform providers like Amazon, Microsoft, Google, Oracle and IBM. Several conventional databases are available in cloud service providers in order to handle the data. Cassandra is a NoSQL database system which can handle the unstructured data and can scale large number of operations per second even across multiple datacentres. Objectives. In this study, the performance evaluation of NoSQL database in AWS cloud service provider has been performed. The performance evaluation of a three node Cassandra cluster is performed for different configuration of EC2 instances. This performance has been evaluated using the metrics throughput and CPU utilization. The main aim of this thesis was to evaluate the performance of Cassandra under various configurations with the YCSB benchmarking tool. Methods. A literature review has been conducted to gain more knowledge about the current research area. The metrics required to evaluate the performance of Cassandra were identified through literature study. The experiment was conducted to compute the results for throughput and CPU utilization under the different configurations t2.micro, t2.medium and t2.small for 3 node and 6 node cluster using YCSB benchmarking tool. Results. The results of the experiment include the metrics, throughput and CPU utilization which were identified in the literature review. The results calculated were plotted as graphs to compare their performance for three different configurations. The results obtained were segregated as two different scenarios which were for 3 node and 6 node clusters. Conclusions. Based on the obtained values of throughput the optimal or sub-optimal configuration of a data centre running multiple instances of Cassandra such that the specific throughput requirements are satisfied.

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.

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

This thesis deals with NoSQL database performance issue. The aim of the paper is to compare most common prototypes of distributed database systems with emphasis on performance and scalability. Yahoo! Cloud Serving Benchmark (YCSB) is used to accomplish the aforementioned aim. The YCSB tool allows performance testing through performance indicators like throughput or response time. It is followed by a thorough explanation of how to work with this tool, which gives readers an opportunity to test performance or do a performance comparison of other distributed database systems than of those described in this thesis. It also helps readers to be able to create testing environment and apply the testing method which has been listed in this thesis should they need it. This paper can be used as a help when making an arduous choice for a specific system from a wide variety of NoSQL database systems for intended solution.

“Pay-as-you-go” is one of the basic properties of Cloud computing. It means that people pay for the resources or services that they use. Moreover, the concept of load balancing has been a controversial issue in recent years. It is a method that is used to split a task to some smaller tasks and allocate them fairly to different resources resulting in a better performance. Considering these two concepts, the idea of “Elasticity” comes to attention. An Elastic system is one which adds or releases the resources based on the changes of the system variables. In this thesis, we extended a distributed storage called Voldemort by adding a controller to provide elasticity. Control theory was used to design this controller. In addition, we used Yahoo! Cloud Service Benchmark (YCSB) which is an open source framework that can be used to provide several load scenarios, as well as evaluating the controller. Automatic control is accomplished by adding or removing nodes in Voldemort by considering changes in the system such as the average service time in our case. We will show that when the service time increases due to increasing the load, as generated by YCSB tool, the controller senses this change and adds appropriate number of nodes to the storage. The number of nodes added is based on the controller parameters to decrease the service time and meet Service Level Objectives (SLO). Similarly, when the average service time decreases, the controller removes some nodes to reduce the cost of using the resources and meet “pay-as-you-go” property.