Performance evaluation of database replication systems.

One of the most demanding needs in cloud computing is that of having scalable and highly available databases. One of the ways to attend these needs is to leverage the scalable replication techniques developed in the last decade. These techniques allow increasing both the availability and scalability of databases. Many replication protocols have been proposed during the last decade. The main research challenge was how to scale under the eager replication model, the one that provides consistency across replicas. In this paper, we examine three eager database replication systems available today: Middle-R, C-JDBC and MySQL Cluster using TPC-W benchmark. We analyze their architecture, replication protocols and compare the performance both in the absence of failures and when there are failures.

Comparison of Architectures and Performance of Database Replication Systems

One of the most demanding needs in cloud computing and big data is that of having scalable and highly available databases. One of the ways to attend these needs is to leverage the scalable replication techniques developed in the last decade. These techniques allow increasing both the availability and scalability of databases. Many replication protocols have been proposed during the last decade. The main research challenge was how to scale under the eager replication model, the one that provides consistency across replicas. This thesis provides an in depth study of three eager database replication systems based on relational systems: Middle-R, C-JDBC and MySQL Cluster and three systems based on In-Memory Data Grids: JBoss Data Grid, Oracle Coherence and Terracotta Ehcache. Thesis explore these systems based on their architecture, replication protocols, fault tolerance and various other functionalities. It also provides experimental analysis of these systems using state-of-the art benchmarks: TPC-C and TPC-W (for relational systems) and Yahoo! Cloud Serving Benchmark (In- Memory Data Grids). Thesis also discusses three Graph Databases, Neo4j, Titan and Sparksee based on their architecture and transactional capabilities and highlights the weaker transactional consistencies provided by these systems. It discusses an implementation of snapshot isolation in Neo4j graph database to provide stronger isolation guarantees for transactions.

Autogestor de contenidos dinámico (ACD)

Este proyecto se centra en la construcción de una herramienta para la gestión de contenidos de muy diversos tipos, siendo fácilmente adaptable a cada uno de los contextos. Permite guardar los contenidos necesarios gracias a un formulario previamente personalizado, de este modo hay un editor que se dedica solamente a la introducción de los contenidos y un administrador que personaliza los campos del formulario según los contenidos. En esencia la herramienta sirve de apoyo a dos tipos de usuario, desarrolladores (administrador) y redactores (editor), a los primeros les simplifica las tareas de conceptualización de las estructuras de datos de las que se desea tener persistencia y sirve como base para construir los editores que usan los redactores, por otro lado proporciona un API sencillo, potente y ágil para recuperar los datos introducidos por los redactores. La herramienta a su vez está pensada para ser interoperable, es decir, no obliga a usar un tipo de almacenamiento persistente concreto. Puede utilizar desde los sencillos archivos de texto, con lo que puede desplegarse en servidores treméndamente básicos. Por otro lado, si se necesita potencia en las búsquedas, nada debe impedir el uso de bases de datos relacionales como MySql. O incluso si se quiere dar un paso más y se quiere aprovechar la flexibilidad, potencia y maleabilidad de las bases de datos NoSql (como MongoDB) no es costoso, lo que hay que hacer es implementar una nueva clase de tipo PersistentManager y desarrollar los tipos de búsqueda y recuperación de contenidos que se necesiten. En la versión inicial de la herramienta se han implementado estos tres tipos de almacenes, nada impide usar sólo alguno de ellos y desechar el resto o implementar uno nuevo. Desde el punto de vista de los redactores, les ofrece un entorno sencillo y potente para poder realizar las tareas típicas denominadas CRUD (Create Read Update Delete, Crear Leer Actualizar y Borrar), un redactor podrá crear, buscar, re-aprovechar e incluso planificar publicación de contenidos en el tiempo. ABSTRACT This project focuses on building a tool for content management of many types, being easily adaptable to each context. Saves the necessary content through a previously designed form, thus there will be an editor working only on the introduction of the contents and there will be an administrator to customize the form fields as contents. Essentially the tool provides support for two types of users, developers (administrator) and editors, the first will have simplified the tasks of conceptualization of data structures which are desired to be persistent and serve as the basis for building the structures that will be used by editors, on the other hand provides a simple, powerful and agile API to retrieve the data entered by the editors. The tool must also be designed to be interoperable, which means not to be bound by the use of a particular type of persistent storage. You can use simple text files, which can be deployed in extremely basic servers. On the other hand, if power is needed in searches, nothing should prevent the use of relational databases such as MySQL. Or even if you want to go a step further and want to take advantage of the flexibility, power and malleability of NoSQL databases (such as MongoDB) it will not be difficult, you will only need to implement a new class of PersistentManager type and develop the type of search and query of content as needed. In the initial version of the tool these three types of storage have been implemented, it will be entitled to use only one of them and discard the rest or implement a new one. From the point of view of the editors, it offers a simple and powerful environment to perform the typical tasks called CRUD (Create Read Update Delete), an editor can create, search, re-use and even plan publishing content in time.