Background: Cassandra is a NoSQL database, where the data in the background is stored in the immutable tables which are called SSTables. These SSTables are subjected to a method called Compaction to reclaim the disk space and to improve READ performance. Size Tiered Compaction Strategy and Leveled Compaction Strategy are the most used generic compaction strategies for different use cases. Space Amplification and Write Amplification are the main limitations of the above compaction strategies, respectively. This research aims to address the limitations of existing generic compaction strategies. Objectives: A new random compaction strategy will be created to improve the efficiency and effectiveness of compaction. This newly created random compaction strategy will be evaluated by comparing the read, write and space amplification with the existing generic compaction strategies, for different use cases. Methods: In this study, Design Science has been used as a research method to answer both the research questions. Focus groups meetings have been conducted to gain knowledge on the limitations of existing compaction strategies, newly created random compaction strategy, and it’s appropriate solutions. During the evaluation, The metrics have been collected from Prometheus server and visualization is carried out in Grafana server. The compaction strategies are compared significantly by performing statistical tests. Results: The results in this study showed that the random compaction strategy is performing almost similar to Leveled Compaction Strategy. The Random Compaction Strategy solves the space amplification problem and write amplification problem in the Size Tiered Compaction Strategy and Leveled Compaction Strategy, respectively. In this section, eight important metrics have been analyzed for all three compaction strategies. Conclusions: The main artefact of this research is a new Random Compaction Strategy. After performing two iterations, a new stable random compaction strategy is designed. The results were analyzed by comparing the Size Tiered Compaction Strategy, Leveled Compaction Strategy and Random Compaction Strategy on two different use cases. The new random compaction strategy has performed great for Ericsson buffer management use case.

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.

Keeping response times low is crucial in order to provide a good user experience. Especially the tail latency proves to be a challenge to keep low as size, complexity and overall use of services scale up. In this thesis we look at reducing the tail latency for reads in the Apache Cassandra database system by implementing the new replica selection algorithm called C3, recently developed by Lalith Suresh, Marco Canini, Stefan Schmid and Anja Feldmann. Through extensive benchmarks with several stress tools, we find that C3 indeed decreases the tail latencies of Cassandra on generated load. However, when evaluating C3 on production load, results does not show any particular improvement. We argue that this is mostly due to the variable size records in the data set and token awareness in the production client. We also present a client-side implementation of C3 in the DataStax Java driver in an attempt to remove the caveat of token aware clients. The client-side implementation did give positive results, but as the benchmark results showed a lot of variance we deem the results to be too inconclusive to confirm that the implementation works as intended. We conclude that the server-side C3 algorithm will work effectively for systems with homogeneous row sizes where the clients are not token aware. / För att kunna erbjuda en bra användarupplevelse så är det av högsta vikt att hålla responstiden låg. Speciellt svanslatensen är en utmaning att hålla låg då dagens applikationer växer både i storlek, komplexitet och användning. I denna rapport undersöker vi svanslatensen vid läsning i databassystemet Apache Cassandra och huruvida den går att förbättra. Detta genom att implementera den nya selektionsalgoritmen för replikor, kallad C3, nyligen framtagen av Lalith Suresh, Marco Canini, Stefan Schmid och Anja Feldmann. Genom utförliga tester med flera olika stressverktyg så finner vi att C3 verkligen förbättrar Cassandras svanslatenser på genererad last. Dock så visade använding av C3 på produktionslast ingen större förbättring. Vi hävdar att detta framförallt beror på en variabel storlek på datasetet och att produktionsklienten är tokenmedveten. Vi presenterar också en klientimplementation av C3 i Java-drivrutinen från DataStax, i ett försök att åtgärda problemet med tokenmedventa klienter. Klientimplementationen av C3 gav positiva resultat, men då testresultaten uppvisade stor varians så anser vi att resultaten är för osäkra för att kunna bekräfta att implentationen fungerar så som den är avsedd. Vi drar slutsatsen att C3, implementerad på servern, fungerar effektivt på system med homogen storlek på datat och där klienter ej är tokenmedvetna.

Context. Cloud computing is growing fast and has established itself as the next generationsoftware infrastructure. A major role in cloud computing is the virtualization of hardware toisolate systems from each other. This virtualization is often done with Virtual Machines thatemulate both hardware and software, which in turn makes the process isolation expensive. Newtechniques, known as Microservices or containers, has been developed to deal with the overhead.The infrastructure is conjoint with storing, processing and serving vast and unstructureddata sets. The overall cloud system needs to have high performance while providing scalabilityand easy deployment. Microservices can be introduced for all kinds of applications in a cloudcomputing network, and be a better fit for certain products.Objectives. In this study we investigate how a small system consisting of a Cassandra clusterperform while encapsulated in LXC and Docker containers, compared to a non virtualizedstructure. A specific loader is built to stress the cluster to find the limits of the containers.Methods. We constructed an experiment on a three node Cassandra cluster. Test data is sentfrom the Cassandra-loader from another server in the network. The Cassandra processes are thendeployed in the different architectures and tested. During these tests the metrics CPU, disk I/O,network I/O are monitored on the four servers. The data from the metrics is used in statisticalanalysis to find significant deviations.Results. Three experiments are being conducted and monitored. The Cluster test pointed outthat isolated Docker container indicate major latency during disk reads. A local stress test furtherconfirmed those results. The step-wise test in turn, implied that disk read latencies happened dueto isolated Docker containers needs to read more data to handle these requests. All Microservicesprovide some overheads, but fall behind the most for read requests.Conclusions. The results in this study show that virtualization of Cassandra nodes in a clusterbring latency in comparison to a non virtualized solution for write operations. However, thoselatencies can be neglected if scalability in a system is the main focus. For read operationsall microservices had reduced performance and isolated Docker containers brought out thehighest overhead. This is due to the file system used in those containers, which makes disk I/Oslower compared to the other structures. If a Cassandra cluster is to be launched in a containerenvironment we recommend a Docker container with mounted disks to bypass Dockers filesystem or a LXC solution.

The paper provides a comparative analysis of existing monitoring systems, identifying their advantages and disadvantages. After this a new version of the system of monitoring of the server infrastructure at various levels was designed and developed, and the implementation of which was also presented in a thesis. / В работе проведён сравнительный анализ существующих систем мониторинга, выявлены их достоинства и недостатки. Был спроектирован и разработан новый вариант системы мониторинга серверной инфраструктуры на различных уровнях, результаты введения в эксплуатацию которого также изложены в магистерской диссертации.

Context: In the field of computer science and communication systems, cloud computing plays animportant role in Information and Technology industry, it allows users to start from small and increase resources when there is a demand. AWS (Amazon Web Services) and GCP (Google cloud Platform) are two different cloud platform providers. Many organizations are still relying onstructured databases like MySQL etc. Structured databases cannot handle huge requests and data efficiently when number of requests and data increase. To overcome this problem, the organizations shift to NoSQL unstructured databases like Apache cassandra, Mongo DB etc. Conclusions: From the literature review, I have gained knowledge regarding the cloud computing, problems existed in cloud, which leads to setup this research in evaluating the performance of cassandra on AWS and GCP. The conclusion from the experiment is that as the thread count increases throughput and latency has increased gradually till thread count 600 in both the clouds. By comparing both the clouds throughput values, AWS scales up compare to GCP. GCP scales up, when compared to AWS in terms of latency.  Keywords: Apache Cassandra, AWS, Google Cloud Platform, Cassandra Stress, Throughput, Latency

A majority of classic Greek and Roman literature focusing on the subject of the Trojan War and its characters portray a male dominant society in Bronze Age Greece. Homer's Iliad follows the heroes Achilles and Hector, while his Odyssey traces the journey of Odysseus on his way home to Ithaca. However, important female characters are either given short page time or are described in a negative light. My goal in completing this thesis is to give voice to the women who were portrayed in a negative way and to offer possible explanations leading up to this portrayal. I also hope to show that although men fought the war, women had to suffer the consequences. Clytemnestra, as queen of Mycenae, was left alone in her kingdom for years. She watched her husband comply with the sacrifice of her eldest daughter in order for the Greeks to win a victory over Troy. Cassandra knew the future of events, but she could not find believers to help prevent the fall of Troy. After the fall, she became Agamemnon's concubine in a foreign land. Because a majority of the Greek plays and poems are tragedies, neither woman's life has a happy or fulfilling end. It is not my goal to change this, but to give possible explanations as to what led to their fates. In writing The Fates of Clytemnestra and Cassandra, I hope to give readers of Greek and Roman literature and Trojan War enthusiasts another perspective on one of the greatest wars in literary history by showing the trials of these two important women.

Företaget Nordicstation hanterar stora datamängder åt Swedbank där datalagringen sker i relationsdatabasen Microsoft SQL Server 2012 (SQL Server). Då det finns andra databashanterare designade för stora datavolymer är det oklart om SQL Server är den optimala lösningen för situationen. Detta examensarbete har tagit fram en jämförelse med hjälp av prestandatester, beträffande exekveringstiden av databasfrågor, mellan databaserna SQL Server, Cassandra och NuoDB vid hanteringen av stora datamängder. Cassandra är en kolumnbaserad databas designad för hantering av stora datavolymer, NuoDB är en minnesdatabas som använder internminnet som lagringsutrymme och är designad för skalbarhet. Resultaten togs fram i en virtuell servermiljö med Windows Server 2012 R2 på en testplattform skriven i Java. Jämförelsen visar att SQL Server var den databas mest lämpad för gruppering, sortering och beräkningsoperationer. Däremot var Cassandra bäst i skrivoperationer och NuoDB presterade bäst i läsoperationer. Analysen av resultatet visade att mindre access till disken ger kortare exekveringstid men den skalbara lösningen, NuoDB, lider av kraftiga prestandaförluster av att endast konfigureras med en nod. Nordicstation rekommenderas att uppgradera till Microsoft SQL Server 2014, eller senare, där möjlighet finns att spara tabeller i internminnet. / The company Nordicstation handles large amounts of data for Swedbank, where data is stored using the relational database Microsoft SQL Server 2012 (SQL Server). The existence of other databases designed for handling large amounts of data, makes it unclear if SQL Server is the best solution for this situation.  This degree project describes a comparison between databases using performance testing, with regard to the execution time of database queries.  The chosen databases were SQL Server, Cassandra and NuoDB. Cassandra is a column-oriented database designed for handling large amounts of data, NuoDB is a database that uses the main memory for data storage and is designed for scalability. The performance tests were executed in a virtual server environment with Windows Server 2012 R2 using an application written in Java. SQL Server was the database most suited for grouping, sorting and arithmetic operations. Cassandra had the shortest execution time for write operations while NuoDB performed best in read operations. This degree project concludes that minimizing disk operations leads to shorter execution times but the scalable solution, NuoDB, suffer severe performance losses when configured as a single-node. Nordicstation is recommended to upgrade to Microsoft SQL Server 2014, or later, because of the possibility to save tables in main memory.

No description available.

Η παρούσα διατριβή μελετά τη διαχρονική διαδρομή ενός αρχαίου μύθου, την πρόσληψή του από τους νεοέλληνες συγγραφείς και τις αλληλεπιδράσεις μεταξύ των ποιητών, με απώτερο στόχο τη διαχρονική ανάγνωση του μύθου της Κασσάνδρας. Ο Όμηρος αναφέρει για πρώτη φορά το όνομα της Κασσάνδρας και επικεντρώνεται στην ομορφιά και στο θάνατό της. Στα Κύκλια Έπη και στη λυρική ποίηση η Κασσάνδρα εμφανίζεται με προφητικές ικανότητες. Στην τραγική και ελληνιστική ποίηση το μυθικό πρόσωπο αποκτά αυτοδύναμο πρωταγωνιστικό ρόλο. Στον Αισχύλο και στον Ευριπίδη εμφανίζεται ως εμπνευσμένη προφήτισσα. Στην Αλεξάνδρα του Λυκόφρονα η Κασσάνδρα, έγκλειστη σε μια φυλακή, προφητεύει την άλωση της Τροίας, το νόστο των Ελλήνων, τη δική της τύχη και τον πόλεμο Ευρώπης-Ασίας. Tο πέρασμα από την παραδοσιακή στη νεοτερική ποίηση σηματοδοτεί μια νέα λειτουργία του μυθικού προσώπου. Ο Παλαμάς εκμεταλλεύτηκε ποιητικά το μυθικό πρόσωπο περισσότερο από τους άλλους ποιητές στην προσπάθειά του να ανασυνθέσει ολιστικά το παρελθόν. Στις νεοτερικές της αποτυπώσεις η Κασσάνδρα συμβολοποιείται και εμφανίζεται άλλοτε ως χρησμολόγος δεινών (Σικελιανός, Καρέλλη), άλλοτε ως σύμβολο διαχρονικών αξιών (Παλαμάς, Σεφέρης, Ρίτσος), άλλοτε αποτελεί απλά πηγή ποιητικής έμπνευσης και δημιουργίας (Πολέμης, Καβάφης). Ο μύθος της Κασσάνδρας αποτέλεσε πόλο έλξης τόσο για τους αρχαίους όσο και για τους νεοέλληνες συγγραφείς. Έτσι έχει δημιουργηθεί ένα μετα-μυθικό υπερκείμενο που εμπλουτίζεται και εξελίσσεται, επιτρέποντας παράλληλα το διακειμενικό διάλογο ανάμεσα στους συγγραφείς και την παλίνδρομη κίνηση παρελθόντος-παρόντος. / The present thesis studies a mythical figure, the interactions between ancient Greek and modern Greek poets, with final objective the diachronic reading of the myth of Cassandra. Homer in the mid-eighth century BC is the first poet who mentions her name. He focused on her beauty and described her death. In Epic Cycle and in lyric poetry Cassandra is presented as a prophet. In tragic and hellenistic poetry she acquires a self-reliant leading role. Exploring her role in the plays of Aeschylus and Euripides leads to an understanding of her role as a seer. Kassandra, also appears in Lykophron, who wrote an obscure poem in the third century BC called Alexandra. In this poem Cassandra, imprisoned, prophesies the fate of Troy, the nostos of Greeks, her fate and the battle between Europe and Asia. The figure of Kassandra reappears in greek poetry through the transition from traditional to modern poetry. In most greek poets, such as Palamas, Seferis, Cavafis, Silelianos, Ritsos, Cassandra becomes a symbol. The specific parallels between the myth and the experiences of the poets create anachronisms which eliminate the time-distance, present the mythical figure as a symbol in order to represent a dramatic view of the different modern reality.