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.

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.

Databases are used extensively for websites and a large amount of websites are built upon Wordpress. Wordpress uses MySQL compatible databases and for many larger websites itcan be imperative to have the best possible performance. Recently, NewSQL databases have been appearing that combine the features of NoSQL databases with SQL compatibility and ACID compliance that is usually not found in NoSQL databases. Due to their recency, thereis a knowledge gap in the literature regarding NewSQL databases. Therefore, this work compares the performance of the NewSQL database TiDB against the SQL database MariaDB in a performance benchmark. The benchmark includes three testing approaches with an aim of testing multiple performance aspects. These include load testing, complex queries and performance in a realistic environment. Results from this thesis show that TiDB achieves better average response time for complex queries and in load testing where the databases and load is large but gets worse results for simple queries and small datasets. MariaDB performs better when used with a web server andwith tests that involve write-operations.

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.