• Save
Dropping ACID - Building Scalable Systems That Work
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Dropping ACID - Building Scalable Systems That Work

on

  • 1,132 views

Presentation given at DevLink 2010

Presentation given at DevLink 2010

Statistics

Views

Total Views
1,132
Views on SlideShare
1,131
Embed Views
1

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • Atomic - All or Nothing <br /> Consistent - from one consistent state to another with each transaction <br /> Isolation - data in a transaction in inaccessible until the transaction is complete <br /> Durable - recoverable in case of a system failure <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

Dropping ACID - Building Scalable Systems That Work Presentation Transcript

  • 1. Dropping Building Scalable Systems That Work Chris Patterson
  • 2. Chris Patterson @P h atB o yG
  • 3. Agenda Scalability 2010 Availability 2010 Consistency (circa 1983) Consistency (eventually 2010)
  • 4. Scalable
  • 5. Scalable A system that Can handle growth without failure Can be expanded to handle even greater growth
  • 6. Scale Up
  • 7. Scale Up Replace existing system with larger, faster system At some point, growth exceeds capacity Leads to vendor lock-in
  • 8. Scale Out
  • 9. Scale Out Functional Partition Increase overall capacity by separating bounded contexts Data Partitioning Increase capacity within a functional partition
  • 10. Scale Out, Industry Trends Cloud Elastic Expansion Rich Internet Applications HTML5/JS, as well as Flex/Silverlight So-ware as a Service
  • 11. That Work
  • 12. Available A system that Is in an operable state Can provide expected functionality when needed
  • 13. Living in the Clouds Available 24/7, online, anywhere Response time is a dimension of availability 95th percentile is key latency metric
  • 14. Partial Availability Data Partitioning A single database failure only impacts data on that server System can be partially available for a subset of customers
  • 15. 2 PICK
  • 16. Project Triangle Cost Scope Schedule
  • 17. Dating Triangle Intelligent Attractive Emotionally Stable
  • 18. Brewer’s Theorem Consistency Availability Partition Tolerance Credited to Professor Eric A. Brewer
  • 19. Scalable Systems That A system that is Available Scalable Partition Tolerant
  • 20. Consistency Changes to values are consistent in a system An updated address A changed telephone number An additional family member The inventory level of an item
  • 21. Atomic ACID
  • 22. Atomic
  • 23. m ic A to
  • 24. Atomic
  • 25. Atomic All or Nothing
  • 26. Atomic Maintain referential integrity Rollback incomplete transactions Ensure consistent state
  • 27. Atomic Modifications are not accessible to concurrent transactions Lack of isolation can lead to inconsistent state
  • 28. Atomic Completed transactions survive system failures
  • 29. ACID Defined, circa 1983 State of the art system Single machine Vertically scaled up DB/2 (or even ISAM)
  • 30. Distributed Transactional 2PC Two-phase commit protocol Averages availability of involved systems System A (99.9%, 43m) x System B (99.9%, 43m) Results in combined availability of 99.8% (86m)
  • 31. Temporal Inconsistency If I pick up a book at the bookstore, and walk around with it for an hour, another customer is unable to purchase that book. Once I decide to buy in on Amazon instead, a bookstore employee will gladly replace the book on the shelf I go on enjoying my coffee knowing I saved $4.20
  • 32. Eventual Consistency Relax temporal consistency We already do this IsolationLevel.ReadUncommited memcached CDN
  • 33. Eventual Consistency Make temporal consistency windows explicit Command-Query Responsibility Segregation (it’s just command query separation) www.msteched.com/2010/NorthAmerica/ARC302 Persistent View Model
  • 34. Keep Transactions Internal Transactions should not cross service boundaries Avoid adding remote resources to the DTC Avoid cross-database transactions
  • 35. Protocols Create protocols for cross-functional transactions Maintain the state of each exchange in each participating functional partition Example in action Magnum.StateMachine Magnum.Channels
  • 36. Simple Transaction Created Completed
  • 37. Created Do Work Completed
  • 38. Created Do Work Completed FAIL! Failed
  • 39. Pick Up Book Buy Book Sale Replace Book No Sale
  • 40. Pick Up Book Buy Book Sale Replace Book No Sale Damage Book Loss
  • 41. Protocols Long-lived transaction (saga, workflow) Orchestration of correlated Commands Events Handling of compensations Some things can’t be compensated
  • 42. Sagas When(RequestReceived) .Then((saga, request) => { saga.OrderId = request.OrderId; saga.CustomerId = request.CustomerId; }) .Publish(saga => new SendOrderDetailsRequest { RequestId = saga.CorrelationId, CustomerId = saga.CustomerId, OrderId = saga.OrderId, }) .TransitionTo(WaitingForResponse));
  • 43. Sagas During(WaitingForResponse, When(ResponseReceived) .Then((saga, response) => { saga.OrderCreated = response.Created; saga.OrderStatus = response.Status; }) .Publish(saga => new OrderDetails { CustomerId = saga.CustomerId, OrderId = saga.OrderId, Created = saga.OrderCreated.Value, Status = saga.OrderStatus, }) .TransitionTo(Completed));
  • 44. Sagas State Initial { get; set; } State WaitingForResponse { get; set; } State Completed { get; set; }
  • 45. Sagas Event<RetrieveOrderDetails> RequestReceived { get; set; } Event<OrderDetailsResponse> ResponseReceived { get; set; } Event<OrderDetailsRequestFailed> RequestFailed { get; set; }
  • 46. Sagas public virtual string CustomerId { get; set; } public virtual string OrderId { get; set; } public virtual OrderStatus OrderStatus { get; set; } public virtual DateTime? OrderCreated { get; set; }
  • 47. Durable Messaging Asynchronous Temporal decoupling increases availability Supports eventual consistency Given no further changes in state, the system will become consistent
  • 48. Idempotent Uniquely identify every command Allows once-and-only-once completion
  • 49. Search Keyword: BASE Basically Available So--state Eventually Consistent
  • 50. Questions?
  • 51. Contact chris [@phatboyg] .com http://blog.phatboyg.com http://phatboyg.lostechies.com