Thesis (Doctoral)--Université Paris IV-Sorbonne, Littérature comparée, 2003. / "8 mars 2003". Includes bibliographical references and index.

Context. Cassandra is a NoSQL Database which handles large amount of data simultaneously and provides high availability for the data present. Compaction in Cassandra is a process of removing stale data and making data more available to the user. This thesis focusses on analyzing the impact of Cassandra compaction on Cassandra’s performance when running inside a Docker container. Objectives. In this thesis, we investigate the impact of Cassandra compaction on the database performance when it is used within a Docker based container platform. We further fine tune Cassandra’s compaction settings to arrive at a sub-optimal scenario which maximizes its performance while operating within a Docker. Methods. Literature review is performed to enlist different compaction related metrics and compaction related parameters which have an effect on Cassandra’s performance. Further, Experiments are conducted using different sets of mixed workload to estimate the impact of compaction over database performance when used within a Docker. Once these experiments are conducted, we modify compaction settings while operating under a write heavy workload and access database performance in each of these scenarios to identify a sub-optimal value of parameter for maximum database performance. Finally, we use these sub-optimal parameters to perform an experiment and access the database performance. Results. The Cassandra and Operating System related parameters and metrics which affect the Cassandra compaction are listed and their effect on Cassandra’s performance has been tested using some experiments. Based on these experiments, few sub-optimum values are proposed for the listed metrics. Conclusions. It can be concluded that, for better performance of Dockerized Cassandra, the proposed values for each of the parameters in the results (i.e. 5120 for Memtable_heap_size_in_mb, 24 for concurrent_compactors, 16 for compaction_throughput_mb_per_sec, 6 for Memtable_flush_writers and 0.14 for Memtable_cleaup _threshold) can be chosen separately but not the union of those proposed values (confirmed from the experiment performed). Also the metrics and parameters affecting Cassandra performance are listed in this thesis.

Big data is a developing term that describes any large amount of structured and unstructured data that has the potential to be mined for information. To store this type of large amounts of data, cloud storage systems are necessary. These cloud storage systems are developed such that they are capable of keeping the data accessible and available to the users over a network. To store big data new platforms are required. Some of the popular big data platforms are Mongo, Cassandra and Hadoop. In this thesis we used Cassandra database system because it is a distributed database and also open source. Cassandra’s architecture is master less ring design that is easy to setup and easy to maintain. Apache Cassandra is a highly scalable distributed database designed to handle big data management with linear scalable and seamless multiple data center deployment. It is a NoSQL database system which allow schema free tables so that a data item could have a variable set of columns unlike in relational databases. Cassandra provides with high scalability with no single point of failure. For the past few years’ container based virtualization has been evolving rapidly. Container based virtualization such as LXC have been focused here. Linux Containers (LXC) is an operating system level virtualization method for running multiple isolated Linux systems on a single control host. It does not resemble a virtual machine, but provides a virtual environment that has its own CPU, memory, network, etc. space and the resource control mechanism. In this thesis work performance of Apache Cassandra database has been analyzed between bare metal and Linux Containers(LXC). A three node Cassandra cluster has been created on both bare metal and Linux container. Assuming one node as seed and Cassandra stress utility tool has been used to test the load of Cassandra cluster. The performance of Cassandra cluster database has been evaluated in bare metal and Linux Container which is the goal of this thesis work. Linux containers (LXC) are deployed in all the servers. A three node Cassandra database cluster has been created in these servers and also in Linux Container(LXC). Port forwarding is the technique used here for making communication between Cassandra in LXC which is the goal of this thesis work. The performance metrics which determine the performance of Cassandra cluster database are selected according to it. The network configuration parameters are changed according to the behavior of Cassandra. By doing changes in these parameters Cassandra starts running according to the required configuration, after this Cassandra cluster performance will be analyzed. This is done with different write, read and mixed load operations and compared with Cassandra cluster performance on bare metal. The results of the thesis show an analysis of measurements of performance metrics like CPU utilization, Disk throughput and latency while running on Cassandra cluster in both bare metal and Linux Containers. A quantitative and statistical analysis of performance of Cassandra cluster is compared. The physical resources utilized by the Cassandra database on native bare metal and Linux Containers (LXC) is similar. According to the results, CPU utilization is more for Cassandra database in Linux Containers. Disk throughput is also more in Linux Containers except in the case of 66% load write operation. Bare metal has less latency compared to Linux Containers in all the scenarios.

Database is the important part of modern application. From SQL to RDBMS,database moved to frequently transmit and operate lots of data. On ACID, it is focus on the consistence, but it does not suit right now. In the proposed article, we use YCSB to try some different workloads and the special of Cassandra, MongoDB, HBase, and MySQL Cluster to find the difference between SQL and NoSQL. In addition, we also analyze the performance of the four operations (insert, update, scan, and read) in Cassandra, MongoDB, and HBase, and simulate some conditions. Those test supplies the reference for user to select the database.

Submitted by Felipe Lapenda (felipe.lapenda@ufpe.br) on 2015-03-11T11:54:24Z No. of bitstreams: 2 TESE Kyara Maria de Almeida.pdf: 1830899 bytes, checksum: f307582ac0956a305ffc3d4a9ff7473d (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) / Made available in DSpace on 2015-03-11T11:54:24Z (GMT). No. of bitstreams: 2 TESE Kyara Maria de Almeida.pdf: 1830899 bytes, checksum: f307582ac0956a305ffc3d4a9ff7473d (MD5) license_rdf: 1232 bytes, checksum: 66e71c371cc565284e70f40736c94386 (MD5) Previous issue date: 2014-02-25 / Coordenação de Aperfeiçoamento de Pessoal de Nível Superior / Este trabalho tem como inspiração a escritora paulistana Cassandra Rios (1932-2002), e as ressonâncias provocadas por sua obra, que constam de mais de cinquenta livros, sendo a maioria romances, muitos deles censurados em décadas distintas do século XX. Tomando como referência temporal os anos entre 1955-2001, respectivamente anos da primeira e da última aparição do nome de Cassandra Rios, enquanto viva, na impressa escrita, o objetivo da tese é problematizar as condições históricas que possibilitaram a emergência do nome autoral de Cassandra Rios e a inscrição de sua vida enquanto uma tragédia de folhetim. Usando como metáfora a composição do enredo da tragédia grega, que caracteriza-se pela mudança de sorte do herói realizada através da peripécia (peripetéia), do reconhecimento (anagnórisis), e da catástrofe (sparagmós), de forma mais específica, no primeiro capítulo discuto a questão da força do nome e como o nome Cassandra Rios passou a constituir um caleidoscópio de imagens, nem sempre congruentes, nem sempre díspares, possibilitando a existência de seu nome autoral; no segundo capítulo, discuto como as escritas de Cassandra Rios constroem um “eu” trágico a partir da relação entre a autora, sua arte de escrever e os dispositivos da sexualidade; no terceiro capítulo, analiso as narrativas da autora que tratam das posturas assumidas por sua família e pelo aparato da censura ditatorial (1964-1985) diante o seu sucesso literário, além das narrativas sobre o câncer que a atingira, enquanto experiências do limite que serão convocadas nos discursos de Cassandra Rios para que esta produzisse uma inscrição de sua vida enquanto uma peça trágica. Quanto às fontes, procurei analisar os discursos contidos nas duas autobiografias escritas por Cassandra Rios, “Censura, minha luta meu amor-1977” e “Mezzamaro, Flores e Cassis: o pecado de Cassandra- 2000”; como também as entrevistas concedidas a vários jornais e revistas, e matérias que veicularam informações sobre a autora e sua obra. Assim, essa tese defende que se o nome de Cassandra Rios passou a operar enquanto força autoral, não foi apenas por ter sido acessada por milhares de leitores ou porque escrevia sobre temáticas eróticas de forma folhetinesca. Mas, também porque a autora se embrenhou em construir seu próprio nome, e por rasurar alguns dos códigos morais vigentes no século XX, entrou em contato com defensores desses códigos, no espaço familiar, estatal, jurídico, midiático, literário, que também puseram seu nome em circulação. Ora se distanciando, ora se aproximando dos significados que lhes foram atribuídos, enquanto tática, narrou a si mesma com a dramaticidade com que produzia seus romances, na construção de sua vida enquanto uma tragédia de folhetim.

Context. The present trend in a large variety of applications are ranging from the web and social networking to telecommunications, is to gather and process very large and fast growing amounts of information leading to a common set of problems known collectively as “Big Data”. The ability to process large scale data analytics over large number of data sets in the last decade proved to be a competitive advantage in a wide range of industries like retail, telecom and defense etc. In response to this trend, the research community and the IT industry have proposed a number of platforms to facilitate large scale data analytics. Such platforms include a new class of databases, often refer to as NoSQL data stores. Apache Cassandra is a type of NoSQL data store. This research is focused on analyzing the performance of different compaction strategies in different use cases for default Cassandra stress model. Objectives. The performance of compaction strategies are observed in various scenarios on the basis of three use cases, Write heavy- 90/10, Read heavy- 10/90 and Balanced- 50/50. For a default Cassandra stress model, so as to finally provide the necessary events and specifications that suggest when to switch from one compaction strategy to another. Methods. Cassandra single node network is deployed on a web server and its behavior of read and write performance with different compaction strategies is studied with read heavy, write heavy and balanced workloads. Its performance metrics are collected and analyzed. Results. Performance metrics of different compaction strategies are evaluated and analyzed. Conclusions. With a detailed analysis and logical comparison, we finally conclude that Level Tiered Compaction Strategy performs better for a read heavy (10/90) workload while using default Cassandra stress model , as compared to size tiered compaction and date tiered compaction strategies. And for Balanced Date tiered compaction strategy performs better than size tiered compaction strategy and date tiered compaction strategy.

Sectra has a customer database with approximately 1600 customers across the world. In this system there exists not only medical information but alsoinformation about the environment which the system runs in, usage  pattern and much more. This report is about storing data received from log les into a suitable database. Sectra wants to be able to analyze this information so that they can make strategic decisions and get a better understanding of their customers' needs. The tested databases are MongoDB, Cassandra, and MySQL. The results shows that MySQL  is not suitable for storing large amount of data with the current conguration. On the other hand, both MongoDB and Cassandra performed well with the growing amount of data.

Context: There is continuous growth in data generation due to wide usage of modern communication systems. Systems have to be designed which can handle the processing of these data volumes efficiently. Mediation systems are meant to serve this purpose. Databases form an integral part of the mediation systems. Suitability of the databases for such systems is the principle theme of this work. Objectives: The objective of this thesis is to identify the key requirements for databases that can be used as part of Mediation systems, gain a thorough understanding of various features, the data models commonly used in databases and to benchmark their performance. Methods: Previous work that has been carried out on various databases is studied as a part of literature review. Test bed is set up as a part of experiment and performance metrics such as throughput and total time taken were measured through a Java based client. Thorough analysis has been carried out by varying various parameters like data volumes, number of threads in the client etc. Results: Cassandra has a very good write performance for event and batch operations. Cassandra has a slightly better read performance when compared to MySQL Cluster but this differentiation withers out in case of fewer number of threads in the client. Conclusions: On evaluation of MySQL Cluster and Cassandra we conclude that they have several features that are suitable for mediation systems. On the other hand, Cassandra does not guarantee ACID transactions while MySQL Cluster has good support. There is need for further evaluation on new generation databases which are not mature enough as of now.

Context. Apache Cassandra is an open-source, scalable, NoSQL database that distributes the data over many commodity servers. It provides no single point of failure by copying and storing the data in different locations. Cassandra uses a ring design rather than the traditional master-slave design. Virtualization is the technique using which physical resources of a machine are divided and utilized by various virtual machines. It is the fundamental technology, which allows cloud computing to provide resource sharing among the users.  Objectives. Through this research, the effects of virtualization on Cassandra are observed by comparing the virtual machine arrangement to physical machine arrangement along with the overhead caused by virtualization.  Methods. An experiment is conducted in this study to identify the aforementioned effects of virtualization on Cassandra compared to the physical machines. Cassandra runs on physical machines with Ubuntu 14.04 LTS arranged in a multi node cluster. Results are obtained by executing the mixed, read only and write only operations in the Cassandra stress tool on the data populated in this cluster. This procedure is repeated for 100% and 66% workload. The same procedure is repeated in virtual machines cluster and the results are compared.  Results. Virtualization overhead has been identified in terms of CPU utilization and the effects of virtualization on Cassandra are found out in terms of Disk utilization, throughput and latency.  Conclusions. The overhead caused due to virtualization is observed and the effect of this overhead on the performance of Cassandra has been identified. The consequence of the virtualization overhead has been related to the change in performance of Cassandra.

This thesis deals with the complex event processing problem. In theoretical part you can find explanation of basic terms and description of used technologies. Reader also becomes fammiliar with basics of work with esper. Practical part is about building administrative interface, which after connecting to server part of application enables user to use basic functionality of esper engine without previous programming knowledge. Part of this chapter is about system set-up, installation and launching the application as it is not considered to be a trivial task.