Big data storage technologies: a survey <s> Brewer's CAP theorem <s> A transaction is a transformation of state which has the properties of atomicity (all or nothing), durability (effects survive failures) and consistency (a correct transformation). The transaction concept is key to the structuring of data management applications. The concept may have applicability to programming systems in general. This paper restates the transaction concepts and attempts to put several implementation approaches in perspective. It then describes some areas which require further study: (1) the integration of the transaction concept with the notion of abstract data type, (2) some techniques to allow transactions to be composed of sub- transactions, and (3) handling transactions which last for extremely long times (days or months). <s> BIB001 </s> Big data storage technologies: a survey <s> Brewer's CAP theorem <s> The cost of reconciling consistency and state management with high availability is highly magnified by the unprecedented scale and robustness requirements of today's Internet applications. We propose two strategies for improving overall availability using simple mechanisms that scale over large applications whose output behavior tolerates graceful degradation. We characterize this degradation in terms of harvest and yield, and map it directly onto engineering mechanisms that enhance availability by improving fault isolation, and in some cases also simplify programming. By collecting examples of related techniques in the literature and illustrating the surprising range of applications that can benefit from these approaches, we hope to motivate a broader research program in this area. <s> BIB002 </s> Big data storage technologies: a survey <s> Brewer's CAP theorem <s> The CAP theorem asserts that any networked shared-data system can have only two of three desirable properties. However, by explicitly handling partitions, designers can optimize consistency and availability, thereby achieving some trade-off of all three. The featured Web extra is a podcast from Software Engineering Radio, in which the host interviews Dwight Merriman about the emerging NoSQL movement, the three types of nonrelational data stores, Brewer's CAP theorem, and much more. <s> BIB003
We describe the significance of Brewer's CAP theorem in the evaluation of distributed systems. For this purpose, we first describe other criteria and evolution of the CAP theorem. With the emergence of distributed storage systems, the need to reconsider ACID BIB001 constraints (atomicity, consistency, isolation, and durability) became urging, as it does not ensure availability. Although availability may not be a requirement for some network services, it is most likely to be considerable. Many researchers have presented their viewpoints to explain the basic requirements of a distributed storage system for big data.  , for example, identified them as incremental scalability, provisioning of overflow growth, high availability, and cost effectiveness for scalable network services. The authors showed that it is very difficult for networked clusters to fulfill all these requirements and presented the BASE (basic availability, soft state, and eventual consistency) model  . This model can be preferably adopted when ACID is not applicable, and it provides a better support to faults and partial failures in clusters at very little cost. When discussing consistency and availability, it seems that a strongly consistent system prohibits more than one copy of data; thus, the concept of high availability is compromised, and it discourages replication to increase users' access to the required service. BIB002 introduced a tradeoff to design distributed systems and presented the CAP principle (consistency, availability, and partition resilience). Before explaining the CAP principle and its tradeoff to categorize distributed systems, we provide below a brief definition of the three basic concepts considered related to this principle, namely consistency, availability, and partition resilience. Consistency refers to having the same up-to-date data at each node (Oracle, 2015a) , availability suggests quick accessibility to data storage resources with minimum downtime (Oracle, 2015a) , and partition resilience is related to fault tolerance in case of unresponsive nodes or a sub-network  . Initially the authors claimed that a simultaneous provision of these three features as explained above is not possible for a distributed system and two out of three were supposed to be guaranteed BIB002 . For instance, there is a possibility that a distributed system compromises partition resilience and satisfies the other two. Existence of any two of these three features can present a distributed system. This principle invited criticism from experts, and, later, Brewer clarified the misleading concept of 'choosing two out of three' and explained that most of the time there is a choice between consistency and availability depending upon the user access pattern or nature of data BIB003 . As far as partition resilience is concerned, Brewer showed that it is rare to face the partitioning problem in a system and that a lot of options exist for partition handling and recovery. This explanation is depicted in Fig. 7 . Thus, the theorem suggests a design of the distributed system be leaning towards either consistency or availability where partition resilience cannot be forfeited.