Why your RDBMS’s fails at scale

展开查看详情

1.Why your RDBMS’s fails at scale And one built for it…..

2. DataStax: from validation to momentum. 400+ $190M 500+ Employees Funding Customers Founded in April 2010 Santa Clara • San Francisco • Austin • London • Paris • Berlin • Tokyo • Sydney (Series E – Sept. 2014) 30% + 2016, 2017 World’s Best Ranked #1 in multiple operational 100 Cloud Companies database categories © 2017 DataStax, All Rights Reserved. Company Confidential

6. Microsoft remains a leader in collaboration with a cloud application 60 Million #1 5 Million Monthly Active Users Deployed App Events Per in Enterprises Organization a Month 6

8. Potted history of the Database 1995 First internet based applications arrive Database and the Internet 1993 WWW finally available 1986 SQL becomes 1983 official birth of international 1970 Invented by internet or TCP/IP standard E.F. Codd at IBM 1979 First commercial RDBMS available (Oracle V2)

9.Explosion of Cloud Applications

10.Some of the issues faced • How do you scale the database? • Add more RAM • Add more CPU • Add faster and more disks • How do you do this? • Bring the database OFFLINE • Vertical scaling has a finite limit

11.Some of the issues faced Connection Pool • How do you scale client connections? Listener • Add a connection pool • But this has a finite limit • Adds complexity

12.Single Points of Failure • With a single database we have a SPOF • Use replication • Problem solved • But now • Single Master • Scales for Reads not Writes • Action needed if Master goes down • Only suitable for LAN deployments Read Only Master Subscriber

13.But How to Horizontally Scale L A-M o a d • Shard your data across databases b D a l • Each shard needs a replica a n • Need a load balancer N-Z c e • Just showing 2 shards r • Things get more complicated • Could have multiple read only subscribers Read Only Master Subscriber

14.What about multiple Data Centres? • Extremely complicated • Difficult to support Active Active • Need to consider conflicts • More Disaster Recovery than Disaster Avoidance

15.Traditional Data Models don’t help • Normalised Data Model 1:M • Random seeks result in high volume of I/O operations M:N • Joins extremely expensive • Won’t scale horizontally • De-Normalised Data Model • Sequential seek to return results • Joins eliminated • Scales indefinitely

16.Summary • Traditional Databases developed before the web and cloud based applications • Scaling up results in downtime • Single node is a single point of failure • Number of client connections finite • Add a read only replica for high availability • Shard to horizontally scale • Data Center support extremely difficult • Data model not built for horizontal scale

19. So What’s the answer? • Distributed masterless NoSQL Database • Continuous Availability • Disaster Avoidance • Linear Scale Performance San London Francisco • Add nodes to scale • Runs on Commodity Hardware • Cloud or on Premise or Hybrid New York

20. Linear Scalability • Have More Data? Add more nodes. • Need More Throughput? Add more nodes. 9000 Nodes 700 Nodes 400 Nodes http://techblog.netflix.com/2011/11/benchmarking-cassandra-scalability-on.html

21.Continuous Availability • Nodes Down != Database Down • Datacenter Down != Database Down • Upgrade != Database Down

22. Platform for Cloud Applications DataStax is a registered trademark of DataStax, Inc. and its subsidiaries in the United States and/or

24. Key takeaways DataStax: The power behind the moment • Why your RDBMS fails at scale • Fundamentally not built for cloud based applications • World’s leading brands rely on DataStax for globally distributed data management • Next steps: Download today at www.datastax.com and register for your DataStax Academy account for free online training 24

25. Backup Slides 25

26. ACID is a lie with data replication When applying RDBMS to Big Data replication, ACID collapses Scenario: client with read-heavy workload decides to add asynchronous replication, so there is lag for propagating data from master to the slave. • Consistency: If a client decides to do a read to the slave before the data is replicated, it’s going to get the old data back, which means loss of consistency • Atomicity: not having the correct data results in the failure of entire transaction • Isolation: receiving the old data means loss of isolation • Durability: client will receive the old data and not the data it had written to the master node 26

27. CAP tradeoffs Can’t be both consistent and highly available during a network partition • Relational databases choose strong consistency over high availability • Latency between data centers makes consistency impractical • NoSQL databases like Cassandra choose high availability and partition tolerance over consistency. • Data is replicated asynchronously across multiple data centers. We are LIMITED by the speed of light making consistency impossible. • Lets you specify consistency level (one replica vs majority of replicas) suitable for your application 27