Context. Light weight process virtualization has been used in the past e.g., Solaris zones, jails in Free BSD and Linux’s containers (LXC). But only since 2013 is there a kernel support for user namespace and process grouping control that make the use of lightweight virtualization interesting to create virtual environments comparable to virtual machines. Telecom providers have to handle the massive growth of information due to the growing number of customers and devices. Traditional databases are not designed to handle such massive data ballooning. NoSQL databases were developed for this purpose. Cassandra, with its high read and write throughputs, is a popular NoSQL database to handle this kind of data. Running the database using operating system virtualization or containerization would offer a significant performance gain when compared to that of virtual machines and also gives the benefits of migration, fast boot up and shut down times, lower latency and less use of physical resources of the servers. Objectives. This thesis aims to investigate the trade-off in performance while loading a Cassandra cluster in bare-metal and containerized environments. A detailed study of the effect of loading the cluster in each individual node in terms of Latency, CPU and Disk throughput will be analyzed. Methods. We implement the physical model of the Cassandra cluster based on realistic and commonly used scenarios or database analysis for our experiment. We generate different load cases on the cluster for bare-metal and Cassandra in docker scenarios and see the values of CPU utilization, Disk throughput and latency using standard tools like sar and iostat. Statistical analysis (Mean value analysis, higher moment analysis, and confidence intervals) are done on measurements on specific interfaces in order to increase the reliability of the results. Results.Experimental results show a quantitative analysis of measurements consisting Latency, CPU and Disk throughput while running a Cassandra cluster in Bare Metal and Container Environments.A statistical analysis summarizing the performance of Cassandra cluster is surveyed. Results.Experimental results show a quantitative analysis of measurements consisting Latency, CPU and Disk throughput while running a Cassandra cluster in Bare Metal and Container Environments.A statistical analysis summarizing the performance of Cassandra cluster is surveyed. Conclusions. With the detailed analysis, the resource utilization of the database was similar in both the bare-metal and container scenarios. Disk throughput is similar in the case of mixed load and containers have a slight overhead in the case of write loads for both the maximum load case and 66% of maximum load case. The latency values inside the container are slightly higher for all the cases. The mean value analysis and higher moment analysis helps us in doing a finer analysis of the results. The confidence intervals calculated show that there is a lot of variation in the disk performance which might be due to compactions happening randomly. Future work in the area can be done on compaction strategies.

De nos jours, des millions de sources de données différentes produisent une énorme quantité de données non structurées et semi-structurées qui changent constamment. Les systèmes d'information doivent gérer ces données tout en assurant la scalabilité et la performance. En conséquence, ils ont dû s'adapter pour supporter des bases de données hétérogènes, incluant des bases de données No-SQL. Ces bases de données proposent une structure de données sans schéma avec une grande flexibilité, mais sans séparation claire des couches logiques et physiques. Les données peuvent être dupliquées, fragmentées et/ou incomplètes, et ils peuvent aussi changer à mesure des besoins de métier.La flexibilité et l’absence de schéma dans les systèmes NoSQL orientés documents, telle que MongoDB, permettent d’explorer des nouvelles alternatives de structuration sans faire face aux contraintes. Le choix de la structuration reste important et critique parce qu’il y a plusieurs impacts à considérer et il faut choisir parmi des nombreuses d’options de structuration. Nous proposons donc de revenir sur une phase de conception dans laquelle des aspects de qualité et les impacts de la structure sont pris en compte afin de prendre une décision d’une manière plus avertie.Dans ce cadre, nous proposons SCORUS, un système pour l’analyse et l’évaluation des structures orientés document qui vise à faciliter l’étude des possibilités de semi-structurations orientées document, telles que MongoDB, et à fournir des métriques objectives pour mieux faire ressortir les avantages et les inconvénients de chaque solution par rapport aux besoins des utilisateurs. Pour cela, une séquence de trois phases peut composer un processus de conception. Chaque phase peut être aussi effectuée indépendamment à des fins d’analyse et de réglage. La stratégie générale de SCORUS est composée par :1. Génération d’un ensemble d’alternatives de structuration : dans cette phase nous proposons de partir d’une modélisation UML des données et de produire automatiquement un large ensemble de variantes de structuration possibles pour ces données.2. Evaluation d’alternatives en utilisant un ensemble de métriques structurelles : cette évaluation prend un ensemble de variantes de structuration et calcule les métriques au regard des données modélisées.3. Analyse des alternatives évaluées : utilisation des métriques afin d’analyser l’intérêt des alternatives considérées et de choisir la ou les plus appropriées. / Nowadays, millions of different data sources produce a huge quantity of unstructured and semi-structured data that change constantly. Information systems must manage these data but providing at the same time scalability and performance. As a result, they have had to adapt it to support heterogeneous databases, included NoSQL databases. These databases propose a schema-free with great flexibility but with a no clear separation of the logical and physical layers. Data can be duplicated, split and/or incomplete, and it can also change as the business needs.The flexibility and absence of schema in document-oriented NoSQL systems, such as MongoDB, allows new structuring alternatives to be explored without facing constraints. The choice of the structuring remains important and critical because there are several impacts to consider and it is necessary to choose among many of options of structuring. We therefore propose to return to a design phase in which aspects of quality and the impacts of the structure are considered in order to make a decision in a more informed manner.In this context, we propose SCORUS, a system for the analysis and evaluation of document-oriented structures that aims to facilitate the study of document-oriented semi-structuring possibilities, such as MongoDB, and to provide objective metrics for better highlight the advantages and disadvantages of each solution in relation to the needs of the users. For this, a sequence of three phases can compose a design process. Each phase can also be performed independently for analysis and adjustment purposes. The general strategy of SCORUS is composed by:1. Generation of a set of structuration alternatives: in this phase we propose to start from UML modeling of the data and to automatically produce a large set of possible structuring variants for this data.2. Evaluation of Alternatives Using a Set of Structural Metrics: This evaluation takes a set of structuring variants and calculates the metrics against the modeled data.3. Analysis of the evaluated alternatives: use of the metrics to analyze the interest of the considered alternatives and to choose the most appropriate one(s).