Designing a Distributed Cloud Database for Dummies

Join Designing a Distributed Cloud Database for Dummies—the webinar. The webinar “stars” industry vet Patrick McFadin, best known among developers for his seven years at Apache Cassandra, where he held pivotal community roles. Register for the webinar today to learn: why you need distributed cloud databases, the technology you need to create the best used experience, the benefits of data autonomy and much more.

1. The Webinar! Patrick McFadin VP Developer Relations, DataStax @PatrickMcFadin 1

2. What is a Distributed Cloud Database? 2

3. What is a Distributed Cloud Database? Private Cloud 3

4.What Makes a Distributed Cloud Database? 4

5. Masterless No Single Point of Failure Node 1 Node 4 Node 2 Node 3 Hard to Bring Down 5

6. Scale for size Data Volume Node Count 6

7. Highly Performant Source: 7

8.Why a Distributed Cloud Database??? 8


10. 133 ms Looks like you want to go faster than light. Can I help? Yes No 10

11. Highly Performant Source: 11

12. Angry Users Don’t Give You Money 12

13. Happy Users Give You Money 13

14. Resilience 14

15. Ready for Reality? Data Center 1 Data Center 2 Node 1 Node 1 Node 4 Node 2 Node 4 Node 2 Node 3 Node 3 15

16. Remember AWS:Reboot? 16

17. Break it on Purpose! 17

18. A Way of Life 18

19. Angry Users Don’t Give You Money 19

20. Happy Users Give You Money 20

21. Choice in Cloud Services 21

22. Not All Clouds are the Same Elastic Transcoder Deep Learning 22

23. Why Won’t Existing Technology Work? 23

24.Primary-Replica Read and Write Primary • One server designated as Primary • All changes must go through Primary • Reads can be from the Replica Client Copy • Failure requires stopping applications and moving Primary to one of the Replicas • Scaling writes requires sharding Read Replica

25.Sharding shard 1 shard 2 shard 3 shard 4 Primary Primary Primary Primary App Server client 25

26. Scaling Does Not Have to be Shard 26

27.Master-Master Primary Read and Write • Multiple servers designated at Primary • Clients read and write to a specific Primary • Primaries resolve change conflicts Conflict between each other Client Resolution • Each node has 100% of data • On failure, clients need to fail to another primary • Conflict management prohibits multi- Read and Write datacenter Primary

28. Distributed Architectures Added to an Existing Database* *Watch out for fine print 28

29.Masterless • Also known as Peer-to-Peer or Shared Nothing • Each node stores part of the total data with overlap Client • Clients can write to any node • Optimized for working across multiple geographic locations • On node failure, client continues to talk to online nodes