Scalability - Flickr Shimon koifman

Place to share photos One of the earliest web 2.0 applications Online community platform

Place to share photos

One of the earliest web 2.0 applications

Online community platform

470M photos, 4 or 5 sizes of each More than 4 billion queries per day 2 PB raw storage (consumed about ~1.5TB on Sunday) Over 400,000 photos being added every day

470M photos, 4 or 5 sizes of each

More than 4 billion queries per day

2 PB raw storage (consumed about ~1.5TB on Sunday)

Over 400,000 photos being added every day

Services Atom/RSS/RDF Feeds APIs SOAP XML-RPC REST PEAR::XML::Tree

Services

Atom/RSS/RDF Feeds

APIs

SOAP

XML-RPC

REST

PEAR::XML::Tree

Performance High-Availability Technology X Protocol Y

Performance

High-Availability

Technology X

Protocol Y

Traffic growth Dataset growth Maintainability

Traffic growth

Dataset growth

Maintainability

Scale High-Availability Performance The trade off’s between good/fast/cheap

Scale

High-Availability

Performance

The trade off’s between good/fast/cheap

Application servers scale in two ways: Really well Quite badly

Application servers scale in two ways:

Really well

Quite badly

Local session == bad When they move == quite bad Centralized sessions == good No sessions == Great

Local session == bad

When they move == quite bad

Centralized sessions == good

No sessions == Great

Data size is at 12 TB of user metadata (these are not photos) 16GB RAM 6-disk 15K RPM

Data size is at 12 TB of user metadata (these are not photos)

16GB RAM

6-disk 15K RPM

Snapshot of db1.flickr.com SELECT’s 44,220,588 INSERT’s 1,349,234 UPDATE’s 1,755,503 DELETE’s 318,439 13 SELECT’s per I/U/D

Snapshot of db1.flickr.com

SELECT’s 44,220,588

INSERT’s 1,349,234

UPDATE’s 1,755,503

DELETE’s 318,439

13 SELECT’s per I/U/D

Database is the toughest part to scale The best thing is to avoid the issue all together and buy a bigger hardware Dual Opteron/Intel64 systems with 16+GB can get you a long way…

Database is the toughest part to scale

The best thing is to avoid the issue all together and buy a bigger hardware

Dual Opteron/Intel64 systems with 16+GB can get you a long way…

Web applications typically have a read/write ratio of 80/20 If we can scale read capacity, we can solve a lot of situations Replication, Replication , Replication

Web applications typically have a read/write ratio of 80/20

If we can scale read capacity, we can solve a lot of situations

Replication, Replication , Replication

A bunch of slave servers handle all the SELECT’s A single master just handles I/U/D’s Have to ensure consistency in the application logic It can scale horizontally, at least for a while.

A bunch of slave servers handle all the SELECT’s

A single master just handles I/U/D’s

Have to ensure consistency in the application logic

It can scale horizontally, at least for a while.

Slave Farm DB1 Master I/U/D’s SELECT’s Search Slave Farm Search SELECT’s DB3 Main Search slave DB2 Main Slave

[email_address] www.comverse.com