Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Database scalability




    Jonathan Ellis
Classic RDBMS persistence

                   Index




                    Data
Disk is the new tape*
• ~8ms to seek
    – ~4ms on expensive 15k rpm disks
performance   What scaling means




                    money
Performance
• Latency

• Throughput
Two kinds of operations
• Reads

• Writes
Caching
• Memcached

• Ehcache

• etc                   cache




                         DB
Cache invalidation
• Implicit

• Explicit
Cache set invalidation
get_cached_cart(cart=13, offset=10,
 limit=10)

get('cart:13:10:10')

?
Set invalidation 2
prefix = get('cart_prefix:13')

get(prefix + ':10:10')

del('cart_prefix:13')



http://www.aminus.org/...
Replication
Types of replication
• Master → slave
    – Master → slave → other slaves

• Master ↔ master
    – multi-master
Types of replication 2
• Synchronous

• Asynchronous
Synchronous
• Synchronous = slow(er)

• Complexity (e.g. 2pc)

• PGCluster

• Oracle
Asynchronous master/slave
• Easiest

• Failover

• MySQL replication

• Slony, Londiste, WAL shipping

• Tungsten
Asynchronous multi-master
• Conflict resolution
    – O(N3) or O(N2) as you add nodes
    – http://research.microsoft.com/...
Achtung!
• Asynchronous replication can lose data if
   the master fails
“Architecture”
• Primarily about how you cope with failure
    scenarios
Replication does not scale writes
Scaling writes
• Partitioning aka sharding
    – Key / horizontal
    – Vertical
    – Directed
Partitioning
Key based partitioning
• PK of “root” table controls destination
    – e.g. user id

• Retains referential integrity
Example: blogger.com

Users

Blogs

Comments
Example: blogger.com

Users

Blogs      Comments'


Comments
Vertical partitioning
• Tables on separate nodes

• Often a table that is too big to keep with
   the other tables, gets t...
Growing is hard
Directed partitioning
• Central db that knows what server owns a
   key

• Makes adding machines easier

• Single point of...
Partitioning
Partitioning with replication
What these have in common
• Ad hoc

• Error-prone

• Manpower-intensive
To summarize
• Scaling reads sucks

• Scaling writes sucks more
*
      Distributed databases
• Data is automatically partitioned

• Transparent to application

• Add capacity without do...
Two famous papers
• Bigtable: A distributed storage system for
    structured data, 2006

• Dynamo: amazon's highly availa...
The world doesn't need another
  half-assed key/value store

(See also Olin Shivers' 100% and 80%
  solutions)
Two approaches
• Bigtable: “How can we build a distributed
    database on top of GFS?”

• Dynamo: “How can we build a dis...
Bigtable architecture
Lookup in Bigtable
Dynamo
Eventually consistent
• Amazon:
   http://www.allthingsdistributed.com/2008/12

• eBay:
   http://queue.acm.org/detail.cfm...
Consistency in a BASE world
• If W + R > N, you are 100% consistent

• W=1, R=N

• W=N, R=1

• W=Q, R=Q where Q = N / 2 + 1
Cassandra
Memtable / SSTable




Disk

  Commit log
ColumnFamilies

keyA           column1   column2   column3
keyC           column1   column7   column11


Column
Byte[] Nam...
LSM write properties
• No reads

• No seeks

• Fast

• Atomic within ColumnFamily
vs MySQL with 50GB of data
• MySQL
    – ~300ms write
    – ~350ms read

• Cassandra
    – ~0.12ms write
    – ~15ms read
...
Classic RDBMS persistence

                   Index




                    Data
Questions
What Every Developer Should Know About Database Scalability
What Every Developer Should Know About Database Scalability
Upcoming SlideShare
Loading in …5
×

of

What Every Developer Should Know About Database Scalability Slide 1 What Every Developer Should Know About Database Scalability Slide 2 What Every Developer Should Know About Database Scalability Slide 3 What Every Developer Should Know About Database Scalability Slide 4 What Every Developer Should Know About Database Scalability Slide 5 What Every Developer Should Know About Database Scalability Slide 6 What Every Developer Should Know About Database Scalability Slide 7 What Every Developer Should Know About Database Scalability Slide 8 What Every Developer Should Know About Database Scalability Slide 9 What Every Developer Should Know About Database Scalability Slide 10 What Every Developer Should Know About Database Scalability Slide 11 What Every Developer Should Know About Database Scalability Slide 12 What Every Developer Should Know About Database Scalability Slide 13 What Every Developer Should Know About Database Scalability Slide 14 What Every Developer Should Know About Database Scalability Slide 15 What Every Developer Should Know About Database Scalability Slide 16 What Every Developer Should Know About Database Scalability Slide 17 What Every Developer Should Know About Database Scalability Slide 18 What Every Developer Should Know About Database Scalability Slide 19 What Every Developer Should Know About Database Scalability Slide 20 What Every Developer Should Know About Database Scalability Slide 21 What Every Developer Should Know About Database Scalability Slide 22 What Every Developer Should Know About Database Scalability Slide 23 What Every Developer Should Know About Database Scalability Slide 24 What Every Developer Should Know About Database Scalability Slide 25 What Every Developer Should Know About Database Scalability Slide 26 What Every Developer Should Know About Database Scalability Slide 27 What Every Developer Should Know About Database Scalability Slide 28 What Every Developer Should Know About Database Scalability Slide 29 What Every Developer Should Know About Database Scalability Slide 30 What Every Developer Should Know About Database Scalability Slide 31 What Every Developer Should Know About Database Scalability Slide 32 What Every Developer Should Know About Database Scalability Slide 33 What Every Developer Should Know About Database Scalability Slide 34 What Every Developer Should Know About Database Scalability Slide 35 What Every Developer Should Know About Database Scalability Slide 36 What Every Developer Should Know About Database Scalability Slide 37 What Every Developer Should Know About Database Scalability Slide 38 What Every Developer Should Know About Database Scalability Slide 39 What Every Developer Should Know About Database Scalability Slide 40 What Every Developer Should Know About Database Scalability Slide 41 What Every Developer Should Know About Database Scalability Slide 42 What Every Developer Should Know About Database Scalability Slide 43 What Every Developer Should Know About Database Scalability Slide 44 What Every Developer Should Know About Database Scalability Slide 45 What Every Developer Should Know About Database Scalability Slide 46 What Every Developer Should Know About Database Scalability Slide 47 What Every Developer Should Know About Database Scalability Slide 48 What Every Developer Should Know About Database Scalability Slide 49
Upcoming SlideShare
Banco de Dados Não Relacionais vs Banco de Dados Relacionais
Next
Download to read offline and view in fullscreen.

87 Likes

Share

Download to read offline

What Every Developer Should Know About Database Scalability

Download to read offline

Replication. Partitioning. Relational databases. Bigtable. Dynamo. There is no one-size-fits-all approach to scaling your database, and the CAP theorem proved that there never will be. This talk will explain the advantages and limits of the approaches to scaling traditional relational databases, as well as the tradeoffs made by the designers of newer distributed systems like Cassandra. These slides are from Jonathan Ellis's OSCON 09 talk: http://en.oreilly.com/oscon2009/public/schedule/detail/7955

Related Books

Free with a 30 day trial from Scribd

See all

What Every Developer Should Know About Database Scalability

  1. Database scalability Jonathan Ellis
  2. Classic RDBMS persistence Index Data
  3. Disk is the new tape* • ~8ms to seek – ~4ms on expensive 15k rpm disks
  4. performance What scaling means money
  5. Performance • Latency • Throughput
  6. Two kinds of operations • Reads • Writes
  7. Caching • Memcached • Ehcache • etc cache DB
  8. Cache invalidation • Implicit • Explicit
  9. Cache set invalidation get_cached_cart(cart=13, offset=10, limit=10) get('cart:13:10:10') ?
  10. Set invalidation 2 prefix = get('cart_prefix:13') get(prefix + ':10:10') del('cart_prefix:13') http://www.aminus.org/blogs/index.php/2007/1
  11. Replication
  12. Types of replication • Master → slave – Master → slave → other slaves • Master ↔ master – multi-master
  13. Types of replication 2 • Synchronous • Asynchronous
  14. Synchronous • Synchronous = slow(er) • Complexity (e.g. 2pc) • PGCluster • Oracle
  15. Asynchronous master/slave • Easiest • Failover • MySQL replication • Slony, Londiste, WAL shipping • Tungsten
  16. Asynchronous multi-master • Conflict resolution – O(N3) or O(N2) as you add nodes – http://research.microsoft.com/~gray/replicas.ps • Bucardo • MySQL Cluster
  17. Achtung! • Asynchronous replication can lose data if the master fails
  18. “Architecture” • Primarily about how you cope with failure scenarios
  19. Replication does not scale writes
  20. Scaling writes • Partitioning aka sharding – Key / horizontal – Vertical – Directed
  21. Partitioning
  22. Key based partitioning • PK of “root” table controls destination – e.g. user id • Retains referential integrity
  23. Example: blogger.com Users Blogs Comments
  24. Example: blogger.com Users Blogs Comments' Comments
  25. Vertical partitioning • Tables on separate nodes • Often a table that is too big to keep with the other tables, gets too big for a single node
  26. Growing is hard
  27. Directed partitioning • Central db that knows what server owns a key • Makes adding machines easier • Single point of failure
  28. Partitioning
  29. Partitioning with replication
  30. What these have in common • Ad hoc • Error-prone • Manpower-intensive
  31. To summarize • Scaling reads sucks • Scaling writes sucks more
  32. * Distributed databases • Data is automatically partitioned • Transparent to application • Add capacity without downtime • Failure tolerant *Like Bigtable, not Lotus Notes
  33. Two famous papers • Bigtable: A distributed storage system for structured data, 2006 • Dynamo: amazon's highly available key- value store, 2007
  34. The world doesn't need another half-assed key/value store (See also Olin Shivers' 100% and 80% solutions)
  35. Two approaches • Bigtable: “How can we build a distributed database on top of GFS?” • Dynamo: “How can we build a distributed hash table appropriate for the data center?”
  36. Bigtable architecture
  37. Lookup in Bigtable
  38. Dynamo
  39. Eventually consistent • Amazon: http://www.allthingsdistributed.com/2008/12 • eBay: http://queue.acm.org/detail.cfm?id=139412
  40. Consistency in a BASE world • If W + R > N, you are 100% consistent • W=1, R=N • W=N, R=1 • W=Q, R=Q where Q = N / 2 + 1
  41. Cassandra
  42. Memtable / SSTable Disk Commit log
  43. ColumnFamilies keyA column1 column2 column3 keyC column1 column7 column11 Column Byte[] Name Byte[] Value I64 timestamp
  44. LSM write properties • No reads • No seeks • Fast • Atomic within ColumnFamily
  45. vs MySQL with 50GB of data • MySQL – ~300ms write – ~350ms read • Cassandra – ~0.12ms write – ~15ms read • Achtung!
  46. Classic RDBMS persistence Index Data
  47. Questions
  • CarmenCorum

    Nov. 27, 2021
  • SanjayJain53

    Dec. 13, 2018
  • ssusera4957e

    Sep. 6, 2018
  • zhangwei37017

    Oct. 3, 2017
  • aploetz

    Sep. 8, 2017
  • hemant0106

    Dec. 7, 2016
  • marceloancelmo

    Jun. 30, 2016
  • JaiprakashS1

    May. 14, 2016
  • hczcolin

    Apr. 17, 2016
  • alexlarikov

    Feb. 4, 2016
  • NasTra1

    Sep. 17, 2015
  • olavovitor

    Jan. 21, 2015
  • Imory2010

    Sep. 1, 2014
  • j3ffyang

    Jul. 31, 2014
  • dannyzamo

    Jun. 27, 2014
  • roxinphoenix

    May. 8, 2014
  • tandaica0612

    Sep. 2, 2013
  • anggriawan

    Aug. 13, 2013
  • vasujain

    Aug. 8, 2013
  • kamal.gs

    Aug. 2, 2013

Replication. Partitioning. Relational databases. Bigtable. Dynamo. There is no one-size-fits-all approach to scaling your database, and the CAP theorem proved that there never will be. This talk will explain the advantages and limits of the approaches to scaling traditional relational databases, as well as the tradeoffs made by the designers of newer distributed systems like Cassandra. These slides are from Jonathan Ellis's OSCON 09 talk: http://en.oreilly.com/oscon2009/public/schedule/detail/7955

Views

Total views

55,465

On Slideshare

0

From embeds

0

Number of embeds

2,505

Actions

Downloads

1,124

Shares

0

Comments

0

Likes

87

×