55
Database scalability Jonathan Ellis / @spyced

What every developer should know about database scalability, PyCon 2010

  • View
    11.905

  • Download
    2

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: What every developer should know about database scalability, PyCon 2010

Database scalability

Jonathan Ellis / @spyced

Page 2: What every developer should know about database scalability, PyCon 2010
Page 3: What every developer should know about database scalability, PyCon 2010

What scaling means

money

oper

atio

ns /

s=

thro

ughp

ut

Page 4: What every developer should know about database scalability, PyCon 2010

“It scales, but”• It scales, but we have to keep adding

people to our ops team

• It scales, but when the netapp runs out of capacity we're screwed

• It scales, but it's not fast

Page 5: What every developer should know about database scalability, PyCon 2010

2000 2010

Page 6: What every developer should know about database scalability, PyCon 2010

Problem 1

Data

Index

Page 7: What every developer should know about database scalability, PyCon 2010

Problem 2

Page 8: What every developer should know about database scalability, PyCon 2010

Problem 3

Page 9: What every developer should know about database scalability, PyCon 2010

Two kinds of operations• Reads

• Writes

Page 10: What every developer should know about database scalability, PyCon 2010

Band-aids• (Not actually scaling your database)

Page 11: What every developer should know about database scalability, PyCon 2010

Problem 1: btrees suck• ~100 MB/s sequential writes

• ~1.5 MB/s random writes– ~10ms to seek– ~5ms on expensive 15k rpm disks

Page 12: What every developer should know about database scalability, PyCon 2010

Magic bullets• SSD

– ~100MB/s random writes (of 4KB)– ~$800 for 64GB

• vs ~$200 for 2 TB rotational

• Moore's law– Aka the 37signals approach

Page 13: What every developer should know about database scalability, PyCon 2010

Caching• Memcached

• Ehcache

• etc

DB

cache

Page 14: What every developer should know about database scalability, PyCon 2010

Partitioning a (read) cachei = hash(key) % len(servers)

server = servers[i]

Page 15: What every developer should know about database scalability, PyCon 2010

The cold start problem

Page 16: What every developer should know about database scalability, PyCon 2010

Consistent hashing

Page 17: What every developer should know about database scalability, PyCon 2010

Consistent hashing• libketema for memcached

– Multiple “virtual nodes” per machine for better load balancing

Page 18: What every developer should know about database scalability, PyCon 2010

Cache coherence strategies• Write-through

• Explicit invalidation

• Implicit invalidation

Page 19: What every developer should know about database scalability, PyCon 2010

Cache set invalidationdef get_cached_cart(cart, offset):

key = 'cart:%s:%s' % (cart, offset) return get(key) # cart:13:10

def invalidate_cart(cart): ?

Page 20: What every developer should know about database scalability, PyCon 2010

Set invalidation 2def get_cached_cart(cart, offset):

prefix = get_cart_prefix(cart) key = '%s:%s' % (prefix, offset) return get(key)

def invalidate_cart(cart): del(get_cart_prefix(cart))

http://www.aminus.org/blogs/index.php/2007/12/30/memcached_set_invalidation?blog=2

Page 21: What every developer should know about database scalability, PyCon 2010

Pop quiz• Can caching reduce write load?

Page 22: What every developer should know about database scalability, PyCon 2010

Write-back caching

DB

cache

foo.bar = 1

foo.bar = 2

foo.bar = 4

UPDATE foos SET bar=4 WHERE id=3

Page 23: What every developer should know about database scalability, PyCon 2010

Achtung!• Commercial solutions

– Terracotta

• Roll your own– Memcached– ehcache– Zookeeper?

Page 24: What every developer should know about database scalability, PyCon 2010

Scaling reads

Page 25: What every developer should know about database scalability, PyCon 2010

Replication

Page 26: What every developer should know about database scalability, PyCon 2010

Types of replication• Master → slave

– Master → slave → other slaves

• Master ↔ master– multi-master

Page 27: What every developer should know about database scalability, PyCon 2010

Types of replication 2• Synchronous

• Asynchronous

Page 28: What every developer should know about database scalability, PyCon 2010

Synchronous master/slave• ?

Page 29: What every developer should know about database scalability, PyCon 2010

Synchronous multi-master• Synchronous = slow(er)

• Complexity (e.g. 2pc)

• PGCluster

• Oracle

Page 30: What every developer should know about database scalability, PyCon 2010

Asynchronous master/slave• Easiest

• MySQL replication

• Slony, Londiste, WAL shipping

• Tungsten

• MongoDB

• Redis

Page 31: What every developer should know about database scalability, PyCon 2010

Asynchronous multi-master• Conflict resolution

– O(N3) or O(N2) as you add nodes– http://research.microsoft.com/~gray/replicas.ps

• Bucardo

• MySQL Cluster

• Tokyo Cabinet

Page 32: What every developer should know about database scalability, PyCon 2010

Achtung!• Asynchronous replication can lose data if

the master fails

Page 33: What every developer should know about database scalability, PyCon 2010

“Architecture”• Primarily about how you cope with failure

scenarios

Page 34: What every developer should know about database scalability, PyCon 2010

Replication does not scale writes

Page 35: What every developer should know about database scalability, PyCon 2010

Scaling writes

Page 36: What every developer should know about database scalability, PyCon 2010

Partitioning

Page 37: What every developer should know about database scalability, PyCon 2010

Partitioning• sharding / horizontal / key

• Functional / vertical

Page 38: What every developer should know about database scalability, PyCon 2010

Key based partitioning• PK of “root” table controls destination

– e.g. user id

• Retains referential integrity

Page 39: What every developer should know about database scalability, PyCon 2010

Example: blogger.com

Users

Blogs

Comments

Page 40: What every developer should know about database scalability, PyCon 2010

Example: blogger.com

Users

Blogs

Comments

Comments'

Page 41: What every developer should know about database scalability, PyCon 2010

What server gets each key?• Consistent hashing

• Central db that knows what server owns a key

– Makes adding machines easier (than – Single point of failure & query bottleneck– MongoDB

Page 42: What every developer should know about database scalability, PyCon 2010

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

Page 43: What every developer should know about database scalability, PyCon 2010

BothU

sers

1U

sers

2

Pro

duct

s1

Tran

s1Tr

ans2

Tran

s3

Vertical segments

Shardin g

Page 44: What every developer should know about database scalability, PyCon 2010

Partitioning

Page 45: What every developer should know about database scalability, PyCon 2010

Partitioning with replication

Page 46: What every developer should know about database scalability, PyCon 2010

What these have in common• Not application-transparent

• Ad hoc

• Error-prone

• Manpower-intensive

Page 47: What every developer should know about database scalability, PyCon 2010

To summarize• Scaling reads sucks

• Scaling writes sucks more

Page 48: What every developer should know about database scalability, PyCon 2010

Case in point

Page 49: What every developer should know about database scalability, PyCon 2010

NoSQL• Distributed (partitioned, scalable)

– Cassandra– HBase– Voldemort

• Not distributed– Neo4j– CouchDB– Redis

Page 50: What every developer should know about database scalability, PyCon 2010

Distributed* databases• Data is automatically partitioned

• Transparent to application

• Add capacity without downtime

• Failure tolerant

*Like Bigtable, not like Lotus Notes

Page 51: What every developer should know about database scalability, PyCon 2010

Two famous papers• Bigtable: A distributed storage system for

structured data, 2006

• Dynamo: amazon's highly available key-value store, 2007

Page 52: What every developer should know about database scalability, PyCon 2010

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?”

Page 53: What every developer should know about database scalability, PyCon 2010

Cassandra• Dynamo-style replication

• Bigtable ColumnFamily data model

• High-performance – Digg phasing out memcached

• Open space, Saturday at 17:30

Page 54: What every developer should know about database scalability, PyCon 2010

Questions

Page 55: What every developer should know about database scalability, PyCon 2010