This thesis has for its aim to contribute to the problematics of big data distribution on the database level. Particular means of data distribution are analysed, especially in regard to its possible decentralised usage. Acquired findings are consequently used for the creation of the database system concept that enables saving and sharing of biological samples created by measuring with the aid of mass spectrometer.

Research in the area of load balancing in distributed systems has not yet come with an optimal load balancing technique. Existing approaches work primarily with replication and sharding. This thesis overviews existing knowledge in this area with focus on shard- ing, and provides an experiment comparing a state-of-the-art load balancing technique called Weighed-Move with a random baseline and an existing domain-specific balancing implementation. As a significant part of the project, we engineered a generic and scal- able load balancer that may be used in any distributed system and deployed it into an existing ad system called Sklik. The major challenges appeared to be tackling various problems related to data consistency, performance and synchronization, together with solving compatibility issues with the rest of the still-evolving ad system. Our experiment shows that the domain-specific load balancing implementation produces data distribution that enables better performance, but Weighed-Move proved to have a great potential and its results are expected to be enhanced by further work on our implementation. 1

Este trabajo presenta un catálogo de técnicas y patrones de diseño aplicados actualmente en bases de datos NoSQL. El enfoque propuesto consiste en una presentación del estado del arte de las bases de datos NoSQL, una exposición de los conceptos claves relacionados y una posterior exhibición de un conjunto de técnicas y patrones de diseño orientados a la escalabilidad y alta disponibilidad. Para tal fin, • Se describen brevemente las características principales de los bases de datos NoSQL, cuales son los factores que motivaron su aparición, sus diferencias con sus pares relacionales, se presenta el teorema CAP y se contrasta las propiedades ACID contra las BASE. • Se introducen las problemáticas que motivan las técnicas y patrones de diseño a describir. • Se presentan técnicas y patrones de diseños que solucionen las problemáticas. • Finalmente, se concluye con un análisis integrador, y se indican otros temas de investigación pertinentes.

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.

No description available.