HBase-QoD: Vector-Field Consistency for Replicated Cloud Storage

Abstract—There has been extensive recent research in dis-tributed systems regarding consistency in geo-replicated systems. NoSQL databases have introduced a new paradigm in this field, where user data location and replication mechanisms work to-gether to be able to offer best-in-class distributed applications. As such, that means running costly operations under lower system latency while still ensuring data read is still valid for application logic processing. Therefore, several consistency models (like the eventual) use a flexible data consistency approach, that consists in taking advantage of those where staleness of data can be tolerated temporarily. We materialize that the idea in the context of an extensible record store. We assign priority to data depending of data seman-tics and serve it to applications when it is just required, avoiding overloading the network during large periods of disconnection or partitions. It is a practical and flexible approach that currently is not implemented in HBase as such, but even though, it is a desired feature in some community forums of the Apache project itself. We will introduce the data semantics used for non-relational data stores and built around the core architecture of an existing well-known system as such, enabling it to trigger data replication selectively with the support of a three-dimensional field vector. In addition, grouping of operations is possible, ensuring atomic changes and therefore valid updates are propagated. Using this paradigm we can realize bandwidth savings in simulated peak loads scenarios in regard to high overhead of replication between data centers. We still provide different levels of consistency to different users or applications needs (e.g., regarding timeliness, number of pending updates and divergence bounds). We verify the implementation of the Quality-of-Data based vector on a set of distributed clusters. Levels of data consistency are enforced while performance of the cluster is monitored to ensure it remains stable, and updates can be tagged and grouped atomically in logical batches, akin to transactions. I