Databases are a cornerstone in data storage since they store and organize large amounts of data while allowing users to access specific parts of data easily. Databases must however adapt to an increasing amount of users without negatively affect the end-users. CochroachDB (CRDB) is a distributed SQLdatabase that combines consistency related to relational database management systems, with scalability to handle more user requests simultaneously while still being consistent. This paper presents a study that evaluates the scalability properties of CRDB by measuring how latency is affected by the addition of more nodes to a CRDB cluster. The findings show that the latency can decrease with the addition of nodes to a cluster. However, there are cases when more nodes increase the latency.

The development of database systems is moving more and more towards handling large quantities of data, also known as Big Data. New database systems have been developed both within NoSQL and the newer system architecture called NewSQL used to tackle the problems that arise with Big Data. NewSQL is becoming more popular due to its ability to handle the security behind data transactions and simultaneously offer scalability. This has led to database systems constantly being optimized. This report goes into detail on how the handling of datatypes affect how database systems are built based on their architecture and code base.  An experiment was conducted on two NewSQL databases, VoltDB and CockroachDB. The purpose of the experiment was to find out how datatypes can be optimized based on time differences in datatypes and then present causes to those time differences. There were clear time differences which showed what datatypes were fastest. When analyzing the codebase and architecture it became clear that VoltDB handles datatypes when compiling while CockroachDB does so during execution.  Another potential reason is that the time differences have to do with their differences in architecture.  This report has, with the available resources, started to build the foundation for a better standard in how datatypes can be implemented in code to increase the performances of database systems. More research is required due to time constraints that can strengthen and expand the results reached in this paper. / Utvecklingen av databassystem rör sig alltmer mot att hantera stora datamängder, även kallat Big Data. Nya databassystem har utvecklats både inom NoSQL och det nyare NewSQL för att tackla problemen med Big Data. För att hantera både säkerheten bakom databastransaktioner och samtidigt behålla skalbarheten så börjar NewSQL klättra alltmer i databasvärlden. Det har lett till att databassystem effektiviseras så mycket som möjligt. Denna rapport går in i detalj på hur hantering av vissa datatyper påverkas av hur databassystem är uppbyggda baserat på deras arkitektur och kodbas. För att ta reda på hur hantering av datatyper kan effektiviseras utfördes ett experiment på NewSQL databaserna VoltDB och CockroachDB för att hitta tidsskillnader för datatyper och sedan ta fram orsaker till dessa skillnader. Det fanns klara tidsskillnader för vilka datatyper som var snabbast och vid analys av kodbas och arkitektur framgick det att VoltDB hanterar datatyper vid kompilering medan CockroachDB gör det vid exekvering. Dessutom ser deras arkitekturer olika ut vilket kan ytterliggare bidra till tidsskillnaderna. Med de resurser som varit tillgängliga har denna rapport påbörjat ett arbete till att lägga en grund för att ta fram en bättre standard till hur datatyper kan implementeras i kod för att öka prestandan i databassystem. På grund av de tidsbegränsningar som funnits behöver mer forskning tas fram som kan stärka och utvidga resultatet som uppnåtts i detta arbete.

The increased demand for using large databases that scale easily and stay consistent requires service providers to find new solutions for storing data in databases. One solution that has emerged is cloud-native databases. Service providers who effectively can transit to cloud-native databases will benefit from new enterprise applications, industrial automation, Internet of Things (IoT) as well as consumer services, such as gaming and AR/VR. This consequently changes the requirements on a database's architecture and infrastructure in terms of being compatible with the services deployed in a cloud-native environment - this is where CockroachDB comes into the picture. CockroachDB is relatively new and is built from the ground up to run in a cloud-native environment. It is built up with nodes that work as individual machines, and these nodes form a cluster. The authors of this report aim to evaluate the characteristics of the Cockroach database to get an understanding of what it offers to companies that are in a cloud-infrastructure transition phase. For the scope of characteristics, this report is focusing on performance, throughput, stress-test, version hot-swapping, horizontal-/vertical scaling, and node disruptions. To do this, a CockroachDB database was deployed on a Kubernetes cluster, in which simulated traffic was conducted. For the throughput measurement, the TPC-C transaction processing benchmark was used. For scaling, version hot-swapping, and node disruptions, an experimental method was performed. The result of the study confirms the expected outcome. CockroachDB does in fact scale easily, both horizontally and vertically, with minimal effort. It also shows that the throughput remains the same when the cluster is scaled up and out since CockroachDB does not have a master write-node, which is the case with some other databases. CockroachDB also has built-in functionality to handle configuration changes like version hot-swapping and node disruptions. This study concluded that CockroachDB lives up to its promises regarding the subjects handled in the report, and can be seen as a robust, easily scalable database that can be deployed in acloud-native environment.

This study conducted an experiment on NoSQL and NewSQL database management systems where the average throughput of Cassandra, CockroachDB, MongoDB, and VoltDB was compared using five workloads composed of different proportions of read and update queries. How much these different workload compositions affect throughput for each individual database management system was also investigated. The results showed that VoltDB had the highest throughput overall, and its throughput was affected the least by the workloads’ composition. MongoDB had similar high throughput consistency across workloads but at a much lower throughput level, and its throughput was affected much more by the workload compositions than VoltDB. Cassandra had extremely high throughput for 100 percent update workloads,even beating VoltDB in certain cases, but showed underwhelming results for all other workloads. CockroachDB’s throughput was by far the worst at workloads that had any update queries, but was comparable and sometimes even better than Cassandra and MongoDB with 100 percent read workloads. CockroachDB’s throughput proved to be the most affected by the query composition of workloads.

The world is becoming more and more digitized which in turn puts pressure on existing applications and systems to be able to handle large quantities of data. And  in some cases, that data also needs to be operated in secure and isolated environments. To address these needs, a new category  of databases has emerged, by the name of NewSQL. The downside of this new category is that it still remains unexplored in some areas, such as how each database under that category performs towards each other, or even towards databases belonging to other categories. One major aspect, in terms of performance is latency, since it affects the overall user-experience. In order to clear up some of the unexplored areas within NewSQL, two databases were studied in the context of their latency performance: CockroachDB and Vitess. The study was divided into two main parts. The first one, was a quantitative study, which was about gathering data on how each database performed in terms of latency when serving the create, read, update, and delete-operations. No clear differences in latency were found for the create- and read-operations. While the results for update- and delete-operations showed significant differences where Vitess had lower latency than CockroachDB.  The second part of this study was a qualitative study, dedicated to analyze and inspect each database architecture and source code. The intention was to identify potential factors that may affect latency performance. The outcome from the analysis was that three main factors could be identified. The first identified factor is that CockroachDB had a layered architecture and that it needed to translate SQL queries into a set of key-value operations. The second one is that the databases makes use of different storage engines, which in turn can have differences in performance. The third and final identified factor is that MySQL, which was integrated with Vitess, had existed for a longer period of time compared to CockroachDB. Which indicates that the database probably has been more optimized over the years.