CumuloNimbo: Parallel-Distributed Transactional Processing

Data consistency is big issue while using NoSQL Cloud data stores. They ensure scalability and high availability properties for web applications, but while providing these they sacrifice data consistency. Some available applications cannot afford data inconsistency. To achieve Data consistency in multi-item transactions on web applications, CloudTPS is best solution. CloudTPS acts as a scalable transaction manager which guarantees full ACID properties for multi-item transactions on web applications. It does not depend on the presence of server failures and network partitions. There is no effect of failures and network partitions on functionality of CloudTPS. HBase and Hadoop provides scalable data layers. Hence we perform this approach on top of this scalable data layers.

2016

As the computational power used by large-scale applications increases, the amount of data they need to manipulate tends to increase as well. A wide range of such applications requires robust and flexible storage support for atomic, durable and concurrent transactions. Historically, databases have provided the de facto solution to transactional data management, but they have forced applications to drop control over data layout and access mechanisms, while remaining unable to meet the scale requirements of Big Data. More recently, key-value stores have been introduced to address these issues. However, this solution does not provide transactions, or only restricted transaction support, compelling users to carefully coordinate access to data in order to avoid race conditions, partial writes, overwrites, and other hard problems that cause erratic behaviour. We argue there is a gap between existing storage solutions and application requirements that limits the design of transaction-orient...

2010 Second International Symposium on Data, Privacy, and E-Commerce, 2010

We propose a consistency model for a data store in the Cloud and work towards the goal of deploying Database as a Service over the Cloud. This includes consistency across the data partitions and consistency of any replicas that exist across different nodes in the system. We target applications which need stronger consistency guarantees than the applications currently supported by the data stores on the Cloud. We propose a cost-effective algorithm that ensures distributed consistency of data without really compromising on availability for fully replicated data. This paper describes a design in progress, presents the consistency and recovery algorithms for relational data, highlights the guarantees provided by the system and presents future research challenges. We believe that the current notions of consistency for databases might not be applicable over the Cloud and a new formulation of the consistency concept may be needed keeping in mind the application classes we aim to support.

Many distributed storage systems achieve high data access throughput via partitioning and replication, each system with its own advantages and tradeoffs. In order to achieve high scalability, however, today's systems generally reduce transactional support, disallowing single transactions from spanning multiple partitions. Calvin is a practical transaction scheduling and data replication layer that uses a deterministic ordering guarantee to significantly reduce the normally prohibitive contention costs associated with distributed transactions. Unlike previous deterministic database system prototypes, Calvin supports disk-based storage, scales near-linearly on a cluster of commodity machines, and has no single point of failure. By replicating transaction inputs rather than effects, Calvin is also able to support multiple consistency levels-including Paxosbased strong consistency across geographically distant replicas-at no cost to transactional throughput.

2013

Eventual consistency improves the scalability of large datasets in cloud systems. We propose a novel technique for managing different levels of replica consistency in a replicated relational DBMS. To this end, data is partitioned and managed by a partial replication protocol that is able to define a hierarchy of nodes with a lazy update propagation. Nodes in different layers of the hierarchy may maintain different versions of their assigned partitions. Transactions are tagged with an allowance parameter k that specifies the maximum degree of data outdatedness tolerated by them. As a result, different degrees of transaction criticality can be set and non-critical transactions may be completed without blocking nor compromising the critical ones.

2019 IEEE 35th International Conference on Data Engineering Workshops (ICDEW), 2019

Existing relational database systems often suffer from rapid increases or significant variability of transactional workloads but lack support for scalability or elasticity. Database replication has been employed to scale workload performance but past approaches make various performance versus consistency tradeoffs and typically lack the mechanisms and policies for dynamically adding and removing replicas. This paper presents Hihooi, a replication-based middleware system that is able to achieve scalability, strong consistency, and elasticity for existing transactional databases. These features are enabled by (i) a novel replication algorithm for propagating database modifications asynchronously and consistently to all replicas at high speeds, and (ii) a new routing algorithm for directing incoming transactions to consistent replicas. Our experimental evaluation validates the high scalability and elasticity benefits offered by Hihooi, which form the key ingredients towards a truly auto-scaling system.

Lecture Notes in Computer Science, 2010

The Cloud is fast gaining popularity as a platform for deploying Software as a Service (SaaS) applications. In principle, the Cloud provides unlimited compute resources, enabling deployed services to scale seamlessly. Moreover, the pay-as-you-go model in the Cloud reduces the maintenance overhead of the applications. Given the advantages of the Cloud, it is attractive to migrate existing software to this new platform. However, challenges remain as most software applications need to be redesigned to embrace the Cloud. In this paper, we present an overview of our current ongoing work in developing epiC-an elastic and efficient power-aware data-intensive Cloud system. We discuss the design issues and the implementation of epiC's storage system and processing engine. The storage system and the processing engine are loosely coupled, and have been designed to handle two types of workload simultaneously, namely data-intensive analytical jobs and online transactions (commonly referred as OLAP and OLTP respectively). The processing of large-scale analytical jobs in epiC adopts a phase-based processing strategy, which provides a fine-grained fault tolerance, while the processing of queries adopts indexing and filter-andrefine strategies.

F1 is a distributed relational database system built at Google to support the AdWords business. F1 is a hybrid database that combines high availability, the scalability of NoSQL systems like Bigtable, and the consistency and usability of traditional SQL databases. F1 is built on Spanner, which provides synchronous cross-datacenter replication and strong consistency. Synchronous replication implies higher commit latency, but we mitigate that latency by using a hierarchical schema model with structured data types and through smart application design. F1 also includes a fully functional distributed SQL query engine and automatic change tracking and publishing.

ACM Transactions on Database Systems, 2014

As more data management software is designed for deployment in public and private clouds, or on a cluster of commodity servers, new distributed storage systems increasingly achieve high data access throughput via partitioning and replication. In order to achieve high scalability, however, today's systems generally reduce transactional support, disallowing single transactions from spanning multiple partitions. This article describes Calvin, a practical transaction scheduling and data replication layer that uses a deterministic ordering guarantee to significantly reduce the normally prohibitive contention costs associated with distributed transactions. This allows near-linear scalability on a cluster of commodity machines, without eliminating traditional transactional guarantees, introducing a single point of failure, or requiring application developers to reason about data partitioning. By replicating transaction inputs instead of transactional actions, Calvin is able to support ...

Yahoo Cloud Service Benchmark Client (YCSB). It can be used to benchmark new cloud database systems i.e. TPC-C and TPCE focus on emulating database applications to compare different DBMS implementations. It has ready adapters for different NoSQL Databases. YCSB allows benchmarking multiple systems and comparing them by creating " workloads ". One can create and run on multiple systems on the same hardware configuration, and same workloads against each system. Many factors go into deciding which data store should be used for production applications, including basic features, data model, and the performance characteristics for a given type of workload. It's critical to have the ability to compare multiple data stores intelligently and objectively so that you can make sound architectural decisions. The Yahoo! Cloud Serving Benchmark (YCSB), an open source framework for evaluating and comparing the performance of multiple types of data-serving systems has long been the open standard for this purpose. In this paper, we designed a specific workload called Closed Economy Workload (CEW), which can run within the YCSB+T framework. In YCSB+T we develop new workload i.e. Closed Economy Workload (CEW) extended from workload from YCSB.As well as we concentrate on additional methods used to loads data or execute the workload on the database to validate its consistency. We observed that the number of transactions scales linearly up to 16 client threads. Our main motto is deal with data management access i.e. SELECT/UPDATE, with a large collection of items and operations that access and modify those items (get/put). We share our experience with using CEW to evaluate some NoSQL systems.