TRANSACTIONS (AND EVENT-DRIVEN PROGRAMMING) EE324
|
|
- Kristian Sharp
- 7 years ago
- Views:
Transcription
1 TRANSACTIONS (AND EVENT-DRIVEN PROGRAMMING) EE324
2 Concurrency Control 2 General organization of managers for handling transactions.
3 Two-phase locking is pessimistic 3 Acts to prevent non-serializable schedules from arising: pessimistically ass umes conflicts are fairly likely Can deadlock, e.g. T1 reads x then writes y; T2 reads y then writes x. T his doesn t always deadlock but it is capable of deadlocking Overcome by aborting if we wait for too long, Or by designing transactions to obtain locks in a known and agreed upon ordering
4 Transactions T and U with exclusive locks 4 Transaction T: balance = b.getbalance() b.setbalance(bal*1.1) a.withdraw(bal/10) Transaction U: balance = b.getbalance() b.setbalance(bal*1.1) c.withdraw(bal/10) Operations Locks Operations Locks opentransaction bal = b.getbalance() lock B b.setbalance(bal*1.1) opentransaction a.withdraw(bal/10) lock A bal = b.getbalance() waits for T s lock on B closetransaction unlock A, B lock B b.setbalance(bal*1.1) c.withdraw(bal/10) closetransaction lock C unlock B, C
5 Schemes for Concurrency control 5 Locking Optimistic concurrency control (CDK516.5) Time-stamp based concurrency control (not going to cover)
6 Optimistic Concurrency Control 6 Drawbacks of locking Overhead of lock maintenance Deadlocks Reduced concurrency Optimistic Concurrency Control In most applications, likelihood of conflicting accesses by concurrent transacti ons is low Transactions proceed as though there are no conflicts
7 Optimistic Concurrency Control 7 Three phases: Working Phase transactions read and write private copies of objects ( most recently committed) Validation Phase Once transaction is done, the transaction is validated to establish whether or not its operations on objects conflict with operation s of other transactions on the same object. If not conflict, can commit; else some form of conflict resolution is needed and the transaction may abort. Update Phase if commit, private copies are used to make permanent c hange.
8 Validation of transactions 8 Working Validation Update T 1 Earlier committed transactions T 2 T 3 Transaction being validated T v active 1 Later active transactions active 2
9 Validation conflict detection Tv Ti Rule Write Read Ti must not read objects written by Tv Read Write Tv must not read objects written by Ti Write Write Ti must not write objects written by Tv and Tv must not write objects written by Ti
10 Optimistic concurrency control Transactions are numbered. Validation and update occurs in side the critical section. (Satisfies rule 3) Backward validation Rule 1 is satisfied because all read operations of earlier overlapping transactions were performed before the validation of Tv started; they cannot be affected by Tv s write. Read set of Tv must be compared with the write sets of T2 and T3. (Rule 2) In other words, the read set of the transaction being validated is compared with the write set of other overlapping transactions that have already committed. Thus, we need to keep the write set of T2 and T3 for a while after their commit.
11 Today's Lecture 11 Distributed transactions
12 Distributed Transactions 12 Motivation Provide distributed atomic operations at multiple servers that maintain share d data for clients Provide recoverability from server crashes Properties Atomicity, Consistency, Isolation, Durability (ACID) Concepts: commit, abort, distributed commit
13 Transactions in distributed systems 13 Main issue that arises is that now we can have multiple database serve rs that are touched by one transaction Reasons? Data spread around: each owns subset Could have replicated some data object on multiple servers, e.g. to load-ba lance read access for large client set Might do this for high availability
14 Atomic Commit Protocols 14 The atomicity of a transaction requires that when a distributed transact ion comes to an end, either all of its operations are carried out or non e of them One phase commit Coordinator tells all participants (servers) to commit Keep on repeating it until all participants reply If a participant cannot commit (say because of concurrency control), no way to infor m coordinator. Also, no way for the coordinator to abort.
15 The two-phase commit protocol (2PC) Designed to allow any participant to abort its part of transaction But this means, the whole transaction must be aborted Why? First phase: all participants vote (abort or commit). If voted commit, make all changed permanent (durability) and go to prepared state. Log this fact. Participants will eventually commit (if the coordinator says so) even it crashes. Second phase: Joint decision
16 The two-phase commit protocol Phase 1 (voting phase): 1. The coordinator sends a cancommit? (VOTE_REQUEST) request to each of the participants in the transaction. 2. When a participant receives a cancommit? request it repli es with its vote Yes (VOTE_COMMIT) or No (VOTE_AB ORT) to the coordinator. Before voting Yes, it prepares to commit by saving objects in permanent storage. If the vot e is No the participant aborts immediately.
17 The two-phase commit protocol Phase 2 (completion according to outcome of vote): 3. The coordinator collects the votes (including its own). (a)if there are no failures and all the votes are Yes the coordinator d ecides to commit the transaction and sends a docommit (GLOBA L_COMMIT) request to each of the participants. (b)otherwise the coordinator decides to abort the transaction and se nds doabort (GLOBAL_ABORT) requests to all participants that voted Yes. 4. Participants that voted Yes are waiting for a docommit or doabort reques t from the coordinator. When a participant receives one of these messag es it acts accordingly and in the case of commit, makes a havecommitte d call as confirmation to the coordinator.
18 Communication in two-phase commit protocol 18 Coordinator Participant step 1 status prepared to commit (waiting for votes) cancommit? Yes step 2 status prepared to commit 3 committed docommit (uncertain) havecommitted 4 committed done
19 Commit protocol illustrated 19 ok to commit?
20 Commit protocol illustrated 20 ok to commit? commit ok with us
21 Operations for two-phase commit protocol 21 cancommit?(trans)-> Yes / No Call from coordinator to participant to ask whether it can commit a transaction. Participa nt replies with its vote. docommit(trans) Call from coordinator to participant to tell participant to commit its part of a transaction. doabort(trans) Call from coordinator to participant to tell participant to abort its part of a transaction. havecommitted(trans, participant) Call from participant to coordinator to confirm that it has committed the transaction. getdecision(trans) -> Yes / No Call from participant to coordinator to ask for the decision on a transaction after it has vo ted Yes but has still had no reply after some delay. Used to recover from server crash or d elayed messages.
22 Two-Phase Commit protocol 3 (TV sec 8.5) 22 actions by coordinator: while START _2PC to local log; multicast VOTE_REQUEST to all participants; while not all votes have been collected { wait for any incoming vote; if timeout { write GLOBAL_ABORT to local log; multicast GLOBAL_ABORT to all participants; exit; } record vote; } if all participants sent VOTE_COMMIT and coordinator votes COMMIT{ write GLOBAL_COMMIT to local log; multicast GLOBAL_COMMIT to all participants; } else { write GLOBAL_ABORT to local log; multicast GLOBAL_ABORT to all participants; }
23 Two-Phase Commit protocol actions by participant: write INIT to local log; wait for VOTE_REQUEST from coordinator; if timeout { write VOTE_ABORT to local log; exit; } if participant votes COMMIT { write VOTE_COMMIT to local log; send VOTE_COMMIT to coordinator; wait for DECISION from coordinator; if timeout { multicast DECISION_REQUEST to other participants; wait until DECISION is received; /* remain blocked */ write DECISION to local log; } if DECISION == GLOBAL_COMMIT write GLOBAL_COMMIT to local log; else if DECISION == GLOBAL_ABORT write GLOBAL_ABORT to local log; } else { write VOTE_ABORT to local log; send VOTE ABORT to coordinator; }
24 Two-Phase Commit protocol a) The finite state machine for the coordinator in 2PC. b) The finite state machine for a participant. Coordinator and participants have blocking state. When a fa ilure occurs, other process may be indefinitely waiting. There needs to be a timeout mechanism.
25 Two Phase Commit Protocol Timeouts Wait in Coordinator use a time-out mechanism to detect participant crashes. Send GLOBAL_ABORT Init in Participant Can also use a time-out and send VOTE_ABORT Ready in Participant P abort is not an option (since already voted to COM MIT and so coordinator might eventually send GLOBAL_COMMIT). Can contac t another participant Q and choose an action based on its state. State of Q COMMIT ABORT INIT READY Action by P Transition to COMMIT Transition to ABORT Both P and Q transition to ABORT (Q sends VOTE_ABORT) Contact more participants. If all participants are READY, must wait for coordinator to recover
26 Two Phase Commit Protocol - 7 Recovery To ensure that a process can actually recover, it must save its state to persistent storage. If a participant was in INIT (before crash), it can safely decide to locally abort when it recovers and inform the coordinator. If it was COMMIT and ABORT, retransmit its decision to the coordinator. If it was READY, contact other participant Q (Send DECISION_REQUEST), similar to the timeout situation.
27 Two-Phase Commit protocol actions for handling decision requests: /* executed by separate thread */ while true { wait until any incoming DECISION_REQUEST is received; /* rem ain blocked */ read most recently recorded STATE from the local log; if STATE == GLOBAL_COMMIT send GLOBAL_COMMIT to requesting participant; else if STATE == INIT or STATE == GLOBAL_ABORT send GLOBAL_ABORT to requesting participant; else skip; /* participant remains blocked */
28 Three Phase Commit protocol Problem with 2PC If coordinator crashes, participants cannot reach a decision, stay blocked unt il coordinator recovers Three Phase Commit (3PC): proof in [SS 1983] There is no single state from which it is possible to make a transition directly to either COMMIT or ABORT states There is no state in which it is not possible to make a final decision, and from which a transition to COMMIT can be made
29 Three-Phase Commit protocol a) Finite state machine for the coordinator in 3PC b) Finite state machine for a participant
30 Three Phase Commit Protocol Recovery Wait in Coordinator same Init in Participant same PreCommit in Coordinator Some participant has crashed but we know it wanted to commit. GLOBAL_COMMIT the application knowing that once the participant recovers, it will commit. Ready or PreCommit in Participant P (i.e. P has voted to COMMIT) State of Q PRECOMMIT ABORT INIT READY Action by P Transition to PRECOMMIT. If all participants in PRECOMMIT and form a majority, then COMMIT the transaction Transition to ABORT Both P (in READY) and Q transition to ABORT (Q sends VOTE_ABORT). It can be shown that no other participants can be in PRECOMMIT Contact more participants. If can contact a majority and they are in Ready, then ABORT the transaction. If the participants contacted in PreCommit it is safe to COMMIT the transaction Note: if any participant is in state PRECOMMIT, it is impossible for any other participant to be in any state other than READY or PRECOMMIT.
31 Things we have learned so far ACID Concurrency control Distributed atomic commit
32 Two Views of Distributed Systems 32 Optimist: A distributed system is a collection of independent computer s that appears to its users as a single coherent system Pessimist: You know you have one when the crash of a computer you ve never heard of stops you from getting any work done. (Lamport)
33 Recurring Theme 33 Academics like: Clean abstractions Strong semantics Things that prove they are smart Users like: Systems that work (most of the time) Systems that scale Consistency per se isn t important Eric Brewer had the following observations
34 A Clash of Cultures 34 Classic distributed systems: focused on ACID semantics (transaction seman tics) Atomicity: either the operation (e.g., write) is performed on all replicas or is no t performed on any of them Consistency: after each operation all replicas reach the same state Isolation: no operation (e.g., read) can see the data from another operation (e. g., write) in an intermediate state Durability: once a write has been successful, that write will persist indefinitely Modern Internet systems: focused on BASE Basically Available Soft-state (or scalable) Eventually consistent
35 ACID vs BASE ACID BASE Strong consistency for transacti ons highest priority Availability less important Pessimistic Rigorous analysis Complex mechanisms Availability and scaling highest priorities Weak consistency Optimistic Best effort Simple and fast 35
36 Why Not ACID+BASE? 36 What goals might you want from a system? C, A, P Strong Consistency: all clients see the same view, even in the presence of u pdates High Availability: all clients can find some replica of the data, even in the presence of failures Partition-tolerance: the system properties hold even when the system is part itioned
37 CAP Theorem [Brewer] 37 You can only have two out of these three properties The choice of which feature to discard determines the nature of your s ystem
38 Consistency and Availability 38 Comment: Providing transactional semantics requires all functioning nodes to be in contact with each other (no partition) Examples: Single-site and clustered databases Other cluster-based designs Typical Features: Two-phase commit Cache invalidation protocols Classic DS style
39 Partition-Tolerance and Availability 39 Comment: Once consistency is sacrificed, life is easy. Examples: DNS Web caches Practical distributed systems for mobile environments: Coda, Bayou Typical Features: Optimistic updating with conflict resolution This is the Internet design style TTLs and lease cache management
40 Voting with their Clicks 40 In terms of large-scale systems, the world has voted with their clicks: Consistency less important than availability and partition-tolerance
(Pessimistic) Timestamp Ordering. Rules for read and write Operations. Pessimistic Timestamp Ordering. Write Operations and Timestamps
(Pessimistic) stamp Ordering Another approach to concurrency control: Assign a timestamp ts(t) to transaction T at the moment it starts Using Lamport's timestamps: total order is given. In distributed
More informationDr Markus Hagenbuchner markus@uow.edu.au CSCI319. Distributed Systems
Dr Markus Hagenbuchner markus@uow.edu.au CSCI319 Distributed Systems CSCI319 Chapter 8 Page: 1 of 61 Fault Tolerance Study objectives: Understand the role of fault tolerance in Distributed Systems. Know
More informationPage 1. Agenda. CS 268: Lecture 19. A Quick Survey of Distributed Systems. To Paraphrase Lincoln... Why Distributed Systems in 268?
Agenda CS 268: Lecture 19 A Quick Survey of Distributed Systems 80 slides in 80 minutes! Introduction and overview Data replication and eventual consistency Bayou: beyond eventual consistency ractical
More informationCrashes and Recovery. Write-ahead logging
Crashes and Recovery Write-ahead logging Announcements Exams back at the end of class Project 2, part 1 grades tags/part1/grades.txt Last time Transactions and distributed transactions The ACID properties
More informationTransactions and the Internet
Transactions and the Internet Week 12-13 Week 12-13 MIE253-Consens 1 Schedule Week Date Lecture Topic 1 Jan 9 Introduction to Data Management 2 Jan 16 The Relational Model 3 Jan. 23 Constraints and SQL
More informationCentralized Systems. A Centralized Computer System. Chapter 18: Database System Architectures
Chapter 18: Database System Architectures Centralized Systems! Centralized Systems! Client--Server Systems! Parallel Systems! Distributed Systems! Network Types! Run on a single computer system and do
More informationCourse Content. Transactions and Concurrency Control. Objectives of Lecture 4 Transactions and Concurrency Control
Database Management Systems Fall 2001 CMPUT 391: Transactions & Concurrency Control Dr. Osmar R. Zaïane University of Alberta Chapters 18 and 19 of Textbook Course Content Introduction Database Design
More informationDatabase Concurrency Control and Recovery. Simple database model
Database Concurrency Control and Recovery Pessimistic concurrency control Two-phase locking (2PL) and Strict 2PL Timestamp ordering (TSO) and Strict TSO Optimistic concurrency control (OCC) definition
More informationDistributed Transactions
Distributed Transactions 1 Transactions Concept of transactions is strongly related to Mutual Exclusion: Mutual exclusion Shared resources (data, servers,...) are controlled in a way, that not more than
More informationDistributed Database Systems
Distributed Database Systems Vera Goebel Department of Informatics University of Oslo 2011 1 Contents Review: Layered DBMS Architecture Distributed DBMS Architectures DDBMS Taxonomy Client/Server Models
More informationBrewer s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services
Brewer s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web Services Seth Gilbert Nancy Lynch Abstract When designing distributed web services, there are three properties that
More informationDistributed Data Management
Introduction Distributed Data Management Involves the distribution of data and work among more than one machine in the network. Distributed computing is more broad than canonical client/server, in that
More informationDistributed Databases
C H A P T E R19 Distributed Databases Practice Exercises 19.1 How might a distributed database designed for a local-area network differ from one designed for a wide-area network? Data transfer on a local-area
More informationData Management in the Cloud
Data Management in the Cloud Ryan Stern stern@cs.colostate.edu : Advanced Topics in Distributed Systems Department of Computer Science Colorado State University Outline Today Microsoft Cloud SQL Server
More informationConcurrency Control. Module 6, Lectures 1 and 2
Concurrency Control Module 6, Lectures 1 and 2 The controlling intelligence understands its own nature, and what it does, and whereon it works. -- Marcus Aurelius Antoninus, 121-180 A. D. Database Management
More informationProcessing of Hadoop using Highly Available NameNode
Processing of Hadoop using Highly Available NameNode 1 Akash Deshpande, 2 Shrikant Badwaik, 3 Sailee Nalawade, 4 Anjali Bote, 5 Prof. S. P. Kosbatwar Department of computer Engineering Smt. Kashibai Navale
More informationHighly Available Hadoop Name Node Architecture-Using Replicas of Name Node with Time Synchronization among Replicas
IOSR Journal of Computer Engineering (IOSR-JCE) e-issn: 2278-0661, p- ISSN: 2278-8727Volume 16, Issue 3, Ver. II (May-Jun. 2014), PP 58-62 Highly Available Hadoop Name Node Architecture-Using Replicas
More informationDISTRIBUTED AND PARALLELL DATABASE
DISTRIBUTED AND PARALLELL DATABASE SYSTEMS Tore Risch Uppsala Database Laboratory Department of Information Technology Uppsala University Sweden http://user.it.uu.se/~torer PAGE 1 What is a Distributed
More informationDistributed Software Systems
Consistency and Replication Distributed Software Systems Outline Consistency Models Approaches for implementing Sequential Consistency primary-backup approaches active replication using multicast communication
More informationDatabase Tuning and Physical Design: Execution of Transactions
Database Tuning and Physical Design: Execution of Transactions David Toman School of Computer Science University of Waterloo Introduction to Databases CS348 David Toman (University of Waterloo) Transaction
More informationAtomic Commitment in Grid Database Systems
Atomic Commitment in Grid Database Systems Sushant Goel 1 Hema Sharda 2 David Taniar 3 1,2 School of Electrical and Computer Systems Engineering, Royal Melbourne Institute of Technology, Australia 1 s2013070@student.rmit.edu.au
More informationThe CAP theorem and the design of large scale distributed systems: Part I
The CAP theorem and the design of large scale distributed systems: Part I Silvia Bonomi University of Rome La Sapienza www.dis.uniroma1.it/~bonomi Great Ideas in Computer Science & Engineering A.A. 2012/2013
More informationTransaction Management in Distributed Database Systems: the Case of Oracle s Two-Phase Commit
Transaction Management in Distributed Database Systems: the Case of Oracle s Two-Phase Commit Ghazi Alkhatib Senior Lecturer of MIS Qatar College of Technology Doha, Qatar Alkhatib@qu.edu.sa and Ronny
More informationChapter 18: Database System Architectures. Centralized Systems
Chapter 18: Database System Architectures! Centralized Systems! Client--Server Systems! Parallel Systems! Distributed Systems! Network Types 18.1 Centralized Systems! Run on a single computer system and
More informationCAP Theorem and Distributed Database Consistency. Syed Akbar Mehdi Lara Schmidt
CAP Theorem and Distributed Database Consistency Syed Akbar Mehdi Lara Schmidt 1 Classical Database Model T2 T3 T1 Database 2 Databases these days 3 Problems due to replicating data Having multiple copies
More informationBig Data Management and NoSQL Databases
NDBI040 Big Data Management and NoSQL Databases Lecture 4. Basic Principles Doc. RNDr. Irena Holubova, Ph.D. holubova@ksi.mff.cuni.cz http://www.ksi.mff.cuni.cz/~holubova/ndbi040/ NoSQL Overview Main objective:
More informationCSE 544 Principles of Database Management Systems. Magdalena Balazinska Fall 2007 Lecture 5 - DBMS Architecture
CSE 544 Principles of Database Management Systems Magdalena Balazinska Fall 2007 Lecture 5 - DBMS Architecture References Anatomy of a database system. J. Hellerstein and M. Stonebraker. In Red Book (4th
More informationDistributed Data Stores
Distributed Data Stores 1 Distributed Persistent State MapReduce addresses distributed processing of aggregation-based queries Persistent state across a large number of machines? Distributed DBMS High
More informationTopics. Distributed Databases. Desirable Properties. Introduction. Distributed DBMS Architectures. Types of Distributed Databases
Topics Distributed Databases Chapter 21, Part B Distributed DBMS architectures Data storage in a distributed DBMS Distributed catalog management Distributed query processing Updates in a distributed DBMS
More informationChapter 10. Backup and Recovery
Chapter 10. Backup and Recovery Table of Contents Objectives... 1 Relationship to Other Units... 2 Introduction... 2 Context... 2 A Typical Recovery Problem... 3 Transaction Loggoing... 4 System Log...
More informationGeo-Replication in Large-Scale Cloud Computing Applications
Geo-Replication in Large-Scale Cloud Computing Applications Sérgio Garrau Almeida sergio.garrau@ist.utl.pt Instituto Superior Técnico (Advisor: Professor Luís Rodrigues) Abstract. Cloud computing applications
More informationEventually Consistent
Historical Perspective In an ideal world there would be only one consistency model: when an update is made all observers would see that update. The first time this surfaced as difficult to achieve was
More informationCloud Computing at Google. Architecture
Cloud Computing at Google Google File System Web Systems and Algorithms Google Chris Brooks Department of Computer Science University of San Francisco Google has developed a layered system to handle webscale
More informationDatabase Replication Techniques: a Three Parameter Classification
Database Replication Techniques: a Three Parameter Classification Matthias Wiesmann Fernando Pedone André Schiper Bettina Kemme Gustavo Alonso Département de Systèmes de Communication Swiss Federal Institute
More informationCHAPTER 6: DISTRIBUTED FILE SYSTEMS
CHAPTER 6: DISTRIBUTED FILE SYSTEMS Chapter outline DFS design and implementation issues: system structure, access, and sharing semantics Transaction and concurrency control: serializability and concurrency
More informationAvoid a single point of failure by replicating the server Increase scalability by sharing the load among replicas
3. Replication Replication Goal: Avoid a single point of failure by replicating the server Increase scalability by sharing the load among replicas Problems: Partial failures of replicas and messages No
More informationINTRODUCTION TO DATABASE SYSTEMS
1 INTRODUCTION TO DATABASE SYSTEMS Exercise 1.1 Why would you choose a database system instead of simply storing data in operating system files? When would it make sense not to use a database system? Answer
More informationMicrokernels & Database OSs. Recovery Management in QuickSilver. DB folks: Stonebraker81. Very different philosophies
Microkernels & Database OSs Recovery Management in QuickSilver. Haskin88: Roger Haskin, Yoni Malachi, Wayne Sawdon, Gregory Chan, ACM Trans. On Computer Systems, vol 6, no 1, Feb 1988. Stonebraker81 OS/FS
More informationInternet Control Protocols Reading: Chapter 3
Internet Control Protocols Reading: Chapter 3 ARP - RFC 826, STD 37 DHCP - RFC 2131 ICMP - RFC 0792, STD 05 1 Goals of Today s Lecture Bootstrapping an end host Learning its own configuration parameters
More informationName: 1. CS372H: Spring 2009 Final Exam
Name: 1 Instructions CS372H: Spring 2009 Final Exam This exam is closed book and notes with one exception: you may bring and refer to a 1-sided 8.5x11- inch piece of paper printed with a 10-point or larger
More informationDesign Patterns for Distributed Non-Relational Databases
Design Patterns for Distributed Non-Relational Databases aka Just Enough Distributed Systems To Be Dangerous (in 40 minutes) Todd Lipcon (@tlipcon) Cloudera June 11, 2009 Introduction Common Underlying
More informationLecture 7: Concurrency control. Rasmus Pagh
Lecture 7: Concurrency control Rasmus Pagh 1 Today s lecture Concurrency control basics Conflicts and serializability Locking Isolation levels in SQL Optimistic concurrency control Transaction tuning Transaction
More informationThis paper defines as "Classical"
Principles of Transactional Approach in the Classical Web-based Systems and the Cloud Computing Systems - Comparative Analysis Vanya Lazarova * Summary: This article presents a comparative analysis of
More information1.264 Lecture 15. SQL transactions, security, indexes
1.264 Lecture 15 SQL transactions, security, indexes Download BeefData.csv and Lecture15Download.sql Next class: Read Beginning ASP.NET chapter 1. Exercise due after class (5:00) 1 SQL Server diagrams
More informationThis talk is mostly about Data Center Replication, but along the way we'll have to talk about why you'd want transactionality arnd the Low-Level API.
This talk is mostly about Data Center Replication, but along the way we'll have to talk about why you'd want transactionality arnd the Low-Level API. Roughly speaking, the yellow boxes here represenet
More informationScalability. We can measure growth in almost any terms. But there are three particularly interesting things to look at:
Scalability The ability of a system, network, or process, to handle a growing amount of work in a capable manner or its ability to be enlarged to accommodate that growth. We can measure growth in almost
More informationNoSQL in der Cloud Why? Andreas Hartmann
NoSQL in der Cloud Why? Andreas Hartmann 17.04.2013 17.04.2013 2 NoSQL in der Cloud Why? Quelle: http://res.sys-con.com/story/mar12/2188748/cloudbigdata_0_0.jpg Why Cloud??? 17.04.2013 3 NoSQL in der Cloud
More informationThe ConTract Model. Helmut Wächter, Andreas Reuter. November 9, 1999
The ConTract Model Helmut Wächter, Andreas Reuter November 9, 1999 Overview In Ahmed K. Elmagarmid: Database Transaction Models for Advanced Applications First in Andreas Reuter: ConTracts: A Means for
More informationRedis Cluster. a pragmatic approach to distribution
Redis Cluster a pragmatic approach to distribution All nodes are directly connected with a service channel. TCP baseport+4000, example 6379 -> 10379. Node to Node protocol is binary, optimized for bandwidth
More informationTransactions and ACID in MongoDB
Transactions and ACID in MongoDB Kevin Swingler Contents Recap of ACID transactions in RDBMSs Transactions and ACID in MongoDB 1 Concurrency Databases are almost always accessed by multiple users concurrently
More informationDistributed Architectures. Distributed Databases. Distributed Databases. Distributed Databases
Distributed Architectures Distributed Databases Simplest: client-server Distributed databases: two or more database servers connected to a network that can perform transactions independently and together
More informationGoals. Managing Multi-User Databases. Database Administration. DBA Tasks. (Kroenke, Chapter 9) Database Administration. Concurrency Control
Goals Managing Multi-User Databases Database Administration Concurrency Control (Kroenke, Chapter 9) 1 Kroenke, Database Processing 2 Database Administration All large and small databases need database
More informationTransactions and Recovery. Database Systems Lecture 15 Natasha Alechina
Database Systems Lecture 15 Natasha Alechina In This Lecture Transactions Recovery System and Media Failures Concurrency Concurrency problems For more information Connolly and Begg chapter 20 Ullmanand
More informationData Consistency on Private Cloud Storage System
Volume, Issue, May-June 202 ISS 2278-6856 Data Consistency on Private Cloud Storage System Yin yein Aye University of Computer Studies,Yangon yinnyeinaye.ptn@email.com Abstract: Cloud computing paradigm
More informationLast class: Distributed File Systems. Today: NFS, Coda
Last class: Distributed File Systems Issues in distributed file systems Sun s Network File System case study Lecture 19, page 1 Today: NFS, Coda Case Study: NFS (continued) Case Study: Coda File System
More informationTransaction Management Overview
Transaction Management Overview Chapter 16 Database Management Systems 3ed, R. Ramakrishnan and J. Gehrke 1 Transactions Concurrent execution of user programs is essential for good DBMS performance. Because
More informationDistributed systems Lecture 6: Elec3ons, consensus, and distributed transac3ons. Dr Robert N. M. Watson
Distributed systems Lecture 6: Elec3ons, consensus, and distributed transac3ons Dr Robert N. M. Watson 1 Last 3me Saw how we can build ordered mul3cast Messages between processes in a group Need to dis3nguish
More informationChapter 10: Distributed DBMS Reliability
Chapter 10: Distributed DBMS Reliability Definitions and Basic Concepts Local Recovery Management In-place update, out-of-place update Distributed Reliability Protocols Two phase commit protocol Three
More informationTransactions and Concurrency Control. Goals. Database Administration. (Manga Guide to DB, Chapter 5, pg 125-137, 153-160) Database Administration
Transactions and Concurrency Control (Manga Guide to DB, Chapter 5, pg 125-137, 153-160) 1 Goals Database Administration Concurrency Control 2 Database Administration All large and small databases need
More informationDistribution transparency. Degree of transparency. Openness of distributed systems
Distributed Systems Principles and Paradigms Maarten van Steen VU Amsterdam, Dept. Computer Science steen@cs.vu.nl Chapter 01: Version: August 27, 2012 1 / 28 Distributed System: Definition A distributed
More informationThe Cloud Trade Off IBM Haifa Research Storage Systems
The Cloud Trade Off IBM Haifa Research Storage Systems 1 Fundamental Requirements form Cloud Storage Systems The Google File System first design consideration: component failures are the norm rather than
More informationTextbook and References
Transactions Qin Xu 4-323A Life Science Building, Shanghai Jiao Tong University Email: xuqin523@sjtu.edu.cn Tel: 34204573(O) Webpage: http://cbb.sjtu.edu.cn/~qinxu/ Webpage for DBMS Textbook and References
More information2. Analysis. 2.1 Resource Planning. Resource Planning. 1st Question. Example. BPM & WfM. Lecture 9 III. Workflow Theory & Analysis
2. Analysis BPM & WfM Lecture 9 III. Workflow Theory & Analysis IV. WfM & Transactions Consistency and plausibility Structural analysis: Awkward nets Unused / redundant data or resources Unnecessary orderings
More informationWeb Email DNS Peer-to-peer systems (file sharing, CDNs, cycle sharing)
1 1 Distributed Systems What are distributed systems? How would you characterize them? Components of the system are located at networked computers Cooperate to provide some service No shared memory Communication
More informationPrinciples of Distributed Database Systems
M. Tamer Özsu Patrick Valduriez Principles of Distributed Database Systems Third Edition
More informationDatabases : Lecture 11 : Beyond ACID/Relational databases Timothy G. Griffin Lent Term 2014. Apologies to Martin Fowler ( NoSQL Distilled )
Databases : Lecture 11 : Beyond ACID/Relational databases Timothy G. Griffin Lent Term 2014 Rise of Web and cluster-based computing NoSQL Movement Relationships vs. Aggregates Key-value store XML or JSON
More informationNaming vs. Locating Entities
Naming vs. Locating Entities Till now: resources with fixed locations (hierarchical, caching,...) Problem: some entity may change its location frequently Simple solution: record aliases for the new address
More informationINFO5011 Advanced Topics in IT: Cloud Computing
INFO5011 Advanced Topics in IT: Cloud Computing Week 5: Distributed Data Management: From 2PC to Dynamo Dr. Uwe Röhm School of Information Technologies Outline Distributed Data Processing Data Partitioning
More informationCOS 318: Operating Systems
COS 318: Operating Systems File Performance and Reliability Andy Bavier Computer Science Department Princeton University http://www.cs.princeton.edu/courses/archive/fall10/cos318/ Topics File buffer cache
More informationDistributed and Parallel Database Systems
Distributed and Parallel Database Systems M. Tamer Özsu Department of Computing Science University of Alberta Edmonton, Canada T6G 2H1 Patrick Valduriez INRIA, Rocquencourt 78153 LE Chesnay Cedex France
More informationAn Evaluation of the Advantages and Disadvantages of Deterministic Database Systems
An Evaluation of the Advantages and Disadvantages of Deterministic Database Systems Kun Ren Alexander Thomson Northwestern Polytechnical Google University, China agt@google.com renkun nwpu@mail.nwpu.edu.cn
More informationDistributed Systems. Tutorial 12 Cassandra
Distributed Systems Tutorial 12 Cassandra written by Alex Libov Based on FOSDEM 2010 presentation winter semester, 2013-2014 Cassandra In Greek mythology, Cassandra had the power of prophecy and the curse
More informationConcurrency Control. Chapter 17. Comp 521 Files and Databases Fall 2010 1
Concurrency Control Chapter 17 Comp 521 Files and Databases Fall 2010 1 Conflict Serializable Schedules Recall conflicts (WR, RW, WW) were the cause of sequential inconsistency Two schedules are conflict
More informationCOSC 6374 Parallel Computation. Parallel I/O (I) I/O basics. Concept of a clusters
COSC 6374 Parallel Computation Parallel I/O (I) I/O basics Spring 2008 Concept of a clusters Processor 1 local disks Compute node message passing network administrative network Memory Processor 2 Network
More informationConsistency Trade-offs for SDN Controllers. Colin Dixon, IBM February 5, 2014
Consistency Trade-offs for SDN Controllers Colin Dixon, IBM February 5, 2014 The promises of SDN Separa&on of control plane from data plane Logical centraliza&on of control plane Common abstrac&ons for
More informationCluster Computing. ! Fault tolerance. ! Stateless. ! Throughput. ! Stateful. ! Response time. Architectures. Stateless vs. Stateful.
Architectures Cluster Computing Job Parallelism Request Parallelism 2 2010 VMware Inc. All rights reserved Replication Stateless vs. Stateful! Fault tolerance High availability despite failures If one
More informationIntroduction to NOSQL
Introduction to NOSQL Université Paris-Est Marne la Vallée, LIGM UMR CNRS 8049, France January 31, 2014 Motivations NOSQL stands for Not Only SQL Motivations Exponential growth of data set size (161Eo
More informationSQL VS. NO-SQL. Adapted Slides from Dr. Jennifer Widom from Stanford
SQL VS. NO-SQL Adapted Slides from Dr. Jennifer Widom from Stanford 55 Traditional Databases SQL = Traditional relational DBMS Hugely popular among data analysts Widely adopted for transaction systems
More informationOn the Ubiquity of Logging in Distributed File Systems
On the Ubiquity of Logging in Distributed File Systems M. Satyanarayanan James J. Kistler Puneet Kumar Hank Mashburn School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213 Logging is
More informationCloud Computing with Microsoft Azure
Cloud Computing with Microsoft Azure Michael Stiefel www.reliablesoftware.com development@reliablesoftware.com http://www.reliablesoftware.com/dasblog/default.aspx Azure's Three Flavors Azure Operating
More informationCloud DBMS: An Overview. Shan-Hung Wu, NetDB CS, NTHU Spring, 2015
Cloud DBMS: An Overview Shan-Hung Wu, NetDB CS, NTHU Spring, 2015 Outline Definition and requirements S through partitioning A through replication Problems of traditional DDBMS Usage analysis: operational
More informationCity of De Pere. Halogen How To Guide
City of De Pere Halogen How To Guide Page1 (revised 12/14/2015) Halogen Performance Management website address: https://global.hgncloud.com/cityofdepere/welcome.jsp The following steps take place to complete
More informationInformation sharing in mobile networks: a survey on replication strategies
Technical Report RT/015/03 Information sharing in mobile networks: a survey on replication strategies João Pedro Barreto Instituto Superior Técnico/Distributed Systems Group, Inesc-ID Lisboa joao.barreto@inesc-id.pt
More informationClient/Server and Distributed Computing
Adapted from:operating Systems: Internals and Design Principles, 6/E William Stallings CS571 Fall 2010 Client/Server and Distributed Computing Dave Bremer Otago Polytechnic, N.Z. 2008, Prentice Hall Traditional
More informationPerformance Monitoring AlwaysOn Availability Groups. Anthony E. Nocentino aen@centinosystems.com
Performance Monitoring AlwaysOn Availability Groups Anthony E. Nocentino aen@centinosystems.com Anthony E. Nocentino Consultant and Trainer Founder and President of Centino Systems Specialize in system
More informationFile System Reliability (part 2)
File System Reliability (part 2) Main Points Approaches to reliability Careful sequencing of file system opera@ons Copy- on- write (WAFL, ZFS) Journalling (NTFS, linux ext4) Log structure (flash storage)
More informationHomework 1 (Time, Synchronization and Global State) - 100 Points
Homework 1 (Time, Synchronization and Global State) - 100 Points CS25 Distributed Systems, Fall 2009, Instructor: Klara Nahrstedt Out: Thursday, September 3, Due Date: Thursday, September 17 Instructions:
More informationHow To Manage A Multi-Tenant Database In A Cloud Platform
UCSB Computer Science Technical Report 21-9. Live Database Migration for Elasticity in a Multitenant Database for Cloud Platforms Sudipto Das Shoji Nishimura Divyakant Agrawal Amr El Abbadi Department
More informationUnification of Transactions and Replication in Three-Tier Architectures Based on CORBA
Unification of Transactions and Replication in Three-Tier Architectures Based on CORBA Wenbing Zhao, L. E. Moser and P. M. Melliar-Smith Index Terms: Fault tolerance, transaction processing, replication,
More informationChapter Outline. Chapter 2 Distributed Information Systems Architecture. Middleware for Heterogeneous and Distributed Information Systems
Prof. Dr.-Ing. Stefan Deßloch AG Heterogene Informationssysteme Geb. 36, Raum 329 Tel. 0631/205 3275 dessloch@informatik.uni-kl.de Chapter 2 Architecture Chapter Outline Distributed transactions (quick
More informationTransactional properties of DBS
Transactional properties of DBS Transaction Concepts Concurrency control Recovery Transactions: Definition Transaction (TA) Unit of work consisting of a sequence of operations Transaction principles (ACID):
More informationDatabase Management. Chapter Objectives
3 Database Management Chapter Objectives When actually using a database, administrative processes maintaining data integrity and security, recovery from failures, etc. are required. A database management
More informationThe first time through running an Ad Hoc query or Stored Procedure, SQL Server will go through each of the following steps.
SQL Query Processing The first time through running an Ad Hoc query or Stored Procedure, SQL Server will go through each of the following steps. 1. The first step is to Parse the statement into keywords,
More informationMidterm Exam CMPSCI 453: Computer Networks Fall 2011 Prof. Jim Kurose
Midterm Exam CMPSCI 453: Computer Networks Fall 2011 Prof. Jim Kurose Instructions: There are 4 questions on this exam. Please use two exam blue books answer questions 1, 2 in one book, and the remaining
More informationHow To Build Cloud Storage On Google.Com
Building Scalable Cloud Storage Alex Kesselman alx@google.com Agenda Desired System Characteristics Scalability Challenges Google Cloud Storage What does a customer want from a cloud service? Reliability
More informationDistributed Systems [Fall 2012]
Distributed Systems [Fall 2012] [W4995-2] Lec 6: YFS Lab Introduction and Local Synchronization Primitives Slide acks: Jinyang Li, Dave Andersen, Randy Bryant (http://www.news.cs.nyu.edu/~jinyang/fa10/notes/ds-lec2.ppt,
More informationLecture 18: Reliable Storage
CS 422/522 Design & Implementation of Operating Systems Lecture 18: Reliable Storage Zhong Shao Dept. of Computer Science Yale University Acknowledgement: some slides are taken from previous versions of
More informationDefinition of SOA. Capgemini University Technology Services School. 2006 Capgemini - All rights reserved November 2006 SOA for Software Architects/ 2
Gastcollege BPM Definition of SOA Services architecture is a specific approach of organizing the business and its IT support to reduce cost, deliver faster & better and leverage the value of IT. November
More informationCPS122 Lecture: State and Activity Diagrams in UML
CPS122 Lecture: State and Activity Diagrams in UML Objectives: last revised February 14, 2012 1. To show how to create and read State Diagrams 2. To introduce UML Activity Diagrams Materials: 1. Demonstration
More information138 Configuration Wizards
9 Configuration Wizards 9.1 Introduction to Wizards ACP ThinManager uses wizards for configuration. Wizards take two forms. List Wizards associate Terminal Servers and ThinManager Servers with their IP
More information