Couchbase Overview Nov 2013

1

Jeff Harris Business Development

NoSQL Document Database

Data Management for Interac6ve Applica6ons

2

Agenda

•  Company Overview

•  Kinds of Database Management System

•  Common Use cases, When is NoSQL a good fit?

•  NoSQL for Mobile Devices, JSON Anywhere

•  Rela6onal vs Non-‐Rela6onal/NoSQL •  Live Demo

•  Couchbase Technical Overview (under the hood and features)

3

Couchbase NoSQL Leadership

Leading NoSQL database company Open Source development & business model

Most mature, reliable and widely deployed solu6on >7,500 paid producBon deployments worldwide

Headquarters in Silicon Valley (Mountain View, CA) ~120 employees including >70 in engineering/product >80% of commits to Couchbase, memcached, Apache CouchDB

Document-‐oriented NoSQL database Focused on interacBve internet and mobile applicaBons

Provide more flexible, higher performance, more scalable database than rela6onal alterna6ve

4

Market Adop6on – Customers Internet Companies Enterprises

More than 350 customers – 7,500 produc6on deployments worldwide

5

Market Adop6on Internet Companies Enterprises

•  Social Gaming •  Ad Networks •  Social Networks •  Online Business

Services •  E-‐Commerce •  Online Media •  Content Management •  Cloud Services

• CommunicaBons • Retail • Financial Services • Health Care • AutomoBve/Airline • Agriculture • Consumer Electronics • Business Systems

6

Two kinds of Database Management System

OLTP / OLTP like

Opera6onal Stores

Data warehouse or Analy6cs system

7

Adding a few more components

OLTP / OLTP like

Opera6onal Stores

Analy6cs Streaming

Data

ETL

RDBMS Data

warehouse

Other legacy systems RDBMS

Column stores

InteracBve BI & ReporBng

8

NoSQL + Big Data

Map-‐reduce against huge datasets to analyze and find insights and answers

Opera6onal database for web and mobile apps with high performance at scale

9

Common Use Cases Social Gaming

•  Couchbase stores player and game data

•  Examples customers include: Zynga

•  Tapjoy, Ubiso`, Tencent

Mobile Apps

•  Couchbase stores user info and app content

•  Examples customers include: Kobo, PlayBka

Ad Targe6ng

•  Couchbase stores user informaBon for fast access

•  Examples customers include: AOL, Mediamind, Convertro

Session store

•  Couchbase Server as a key-‐value store

•  Examples customers include: Concur, Sabre

User Profile Store

•  Couchbase Server as a key-‐value store

•  Examples customers include: Tunewiki

High availability cache

•  Couchbase Server used as a cache Ber replacement

•  Examples customers include: Orbitz

Content & Metadata Store

•  Couchbase document store with ElasBc Search

•  Examples customers include: McGraw Hill

3rd party data aggrega6on

•  Couchbase stores social media and data feeds

•  Examples customers include: LivePerson

10

Couchbase Lite

The only Na6ve NoSQL Database for Mobile

11

The Complete Mobile Solu6on

12

JSON Anywhere

Couchbase Server

•  JSON on the device   Developers

increasingly prefer NoSQL database

•  JSON on the wire   No need for data

transformaBon

•  JSON in the cloud   Flexible data model   High performance   Easy scalability

ServerSync GatewayLiteJS N

JS N

JS N

13

Rela6onal Vs NoSQL Document databases

14

RDBMS Scales Up Get a bigger, more complex server

Users

Applica6on Scales Out Just add more commodity web servers

Users

System Cost ApplicaBon Performance

Rela6onal Technology Scales Up

Rela6onal Database

Expensive and disrup6ve sharding, doesn’t perform at web scale


Won’t scale beyond this point

Web/App Server Tier

15

Couchbase Server Scales Out Like App Tier

NoSQL Database Scales Out Cost and performance mirrors app 6er

Users

Scaling out flabens the cost and performance curves

Couchbase Distributed Data Store

Web/App Server Tier

Applica6on Scales Out Just add more commodity web servers

Users


ApplicaBon Performance System Cost

16

If Cars Were Stored in an RDBMS…

hhp://iedei.files.wordpress.com/2012/04/mercedes-‐f1-‐car-‐disassembled.jpeg

17

If Cars Were Stored in a Document Database…

hhp://images.conceptcarz.com/imgxra/Mercedes-‐Benz/Mercedes-‐W03-‐F1-‐Spanish-‐GP_012-‐1680.jpg

18

Rela6onal vs Document Data Model

Rela6onal data model Document data model CollecBon of complex documents with arbitrary, nested data formats and

varying “record” format.

Highly-‐structured table organizaBon with rigidly-‐defined data formats and

record structure.

JSON JSON

C1 C2 C3 C4

JSON

{ }

19

RDBMS Example: User Profile

Address Info

1 DEN 30303 CO

2 MV 94040 CA

3 CHI 60609 IL

User Info

KEY First ZIP_id Last

4 NY 10010 NY

1 Frank 2 Weigel

2 Ali 2 Dodson

3 Mark 2 Azad

4 Steve 3 Yen

ZIP_id CITY ZIP STATE

1 Frank 2 Weigel

To get info about specific user, you perform a join across two tables

20

All data in a single document

Document Example: User Profile

{ “ID”: 1, “FIRST”: “Frank”, “LAST”: “Weigel”, “ZIP”: “94040”, “CITY”: “MV”, “STATE”: “CA” }

JSON

= +

Making the Same Change With a Document DB

{ “ID”: 1, “FIRST”: “Frank”, “LAST”: “Weigel”, “ZIP”: “94040”, “CITY”: “MV”, “STATE”: “CA”, “STATUS”: { “TEXT”: “At Conf”

}

}

“GEO_LOC”: “134” }, “COUNTRY”: ”USA”

Just add informa6on to a document

JSON

, }

User ID First Last Zip

1 Frank Wiegel 94040

2 Joe Smith 94040

3 Ali Dodson 94040

4 Sarah Gorin NW1

5 Bob Young 30303

6 Nancy Baker 10010

7 Ray Jones 31311

8 Lee Chen V5V3

•  •  • 

5000 Doug Moore 04252

5001 Mary White 41694

5002 Lisa Clark 12425

User ID

Photo ID Comment

2 d043 NYC

2 b054 Bday

5 c036 Miami

7 d072 Sunset

5002 e086 Spain

User Table Photo Table

User ID

Status ID Text

1 a42 At conf

4 b26 excited

5 c32 hockey

12 d83 Go A’s

5000 e34 sailing

Status Table

User ID

Affilia6ons ID

Affilia6ons Name

2 a42 Cal

4 b96 USC

7 c14 UW

8 e22 Oxford

Affilia6ons Table

Rela6onal vs Document Performance

1 Frank 94040 Weigel

a42 1 At conf

5 Bob 30303 Young

c036 5 Miami

4 Sarah NW1 Gorin

b26 4 hockey

JSON

{ }

JSON

{ }

JSON

{ }

JSON

{ }

JSON

{ }

JSON

{ }

JSON

{ }

JSON

{ }

JSON

{ }

JSON

{ }

8 Lee V5V3 Chen

e22 8 Oxford 5002 Lisa 12425 Clark

e086 5002 Spain

c032 5 excited

Faster response 6mes and higher throughput

23

NoSQL Database Considera6ons

Easy Scalability

Consistent High Performance

Flexible Data Model

Always On 24x7x365

Grow cluster without applicaBon changes, without downBme

when needed

Always awesome experience for your applicaBon users.

The sun never sets on the Internet, your applicaBon needs the database

to always serve data.

Keep developers producBve and allow fast and easy addiBon of

new features

JSONJSONJSON

JSONJSON

PERFORMANCE

24

Couchbase Server Is The Complete Solu6on

One click scalability and no app changes.

Sub millisecond latency with high throughput for reads and writes.

Maintenance, upgrades and cluster resizing all online without applicaBon downBme

JSON document model with no fixed schema.

✔

✔

✔

✔


Flexible Data Model

Easy Scalability

Always On 24x7x365

25

Couchbase Server Overview Clustered NoSQL Document Database for

interacBve applicaBons

•  Easy scalability with efficient auto-‐sharding   ApplicaBon stays unchanged as cluster size changes   Data replicaBon and node auto-‐failover

•  Consistent high performance   Sub millisecond latency with high throughput

•  Always-‐On   Maintenance, upgrades and cluster resizing all online

without applicaBon downBme

26

Couchbase Server Features

•  Easy scalability •  Built-‐in clustering •  All nodes equal •  One click to scale horizontally

•  Consistent High Performance •  Built-‐in managed cache •  High performance for both reads and writes

•  Always on •  Data replication with auto-‐failover •  Cross Datacenter Replication •  Zero-‐downtime maintenance •  Monitoring and administration APIs and GUI

27

New Couchbase Server Features

•  Flexible JSON document model   No fixed schema for higher producBvity and less obstacles for developers

•  Data indexing and querying   Secondary indexes on JSON documents   Simple real-‐Bme analyBcs via incremental map-‐reduce   Connector to full-‐text search indexer

•  Cross datacenter replica6on   Scale your data beyond a single data center

28

Couchbase solu6on “The basics”

29

3 3 2

Single node -‐ Couchbase Write Opera6on

Managed Cache

Disk Que

ue

Disk

ReplicaBon Queue

App Server

Couchbase Server Node

Doc 1 Doc 1

Doc 1

To other node

30

3 3 2

Single node -‐ Couchbase Update Opera6on

Managed Cache

Disk Que

ue

ReplicaBon Queue

App Server


Doc 1’

Doc 1

Doc 1’ Doc 1

Doc 1’

Disk

To other node

31

GET

Doc 1

3 3 2

Single node -‐ Couchbase Read Opera6on

Disk Que

ue

ReplicaBon Queue

App Server


Doc 1

Doc 1 Doc 1

Managed Cache

Disk

To other node

32

COUCHBASE SERVER CLUSTER

Basic Opera6on

•  Docs distributed evenly across servers

•  Each server stores both ac6ve and replica docs   Only one server acBve at a Bme

•  Client library provides app with simple interface to database

•  Cluster map provides map to which server doc is on   App never needs to know

•  App reads, writes, updates docs

•  Mul6ple app servers can access same document at same 6me

User Configured Replica Count = 1

READ/WRITE/UPDATE

ACTIVE

Doc 5

Doc 2

Doc

Doc

Doc

SERVER 1 ACTIVE

Doc 4

Doc 7

Doc

Doc

Doc

SERVER 2

Doc 8

ACTIVE

Doc 1

Doc 3

Doc

Doc

Doc

REPLICA

Doc 4

Doc 1

Doc 8

Doc

Doc

Doc

REPLICA

Doc 6

Doc 3

Doc 2

Doc

Doc

Doc

REPLICA

Doc 7

Doc 9

Doc 5

Doc

Doc

Doc

SERVER 3

Doc 6

APP SERVER 1

COUCHBASE Client Library CLUSTER MAP


APP SERVER 2

Doc 9

33

Add Nodes to Cluster

•  Two servers added with one-‐click opera6on

•  Docs automa6cally rebalance across cluster   Even distribuBon of docs   Minimum doc movement

•  Cluster map updated

•  App database calls now distributed over larger number of servers

REPLICA

ACTIVE

Doc 5

Doc 2

Doc

Doc

Doc 4

Doc 1

Doc

Doc

SERVER 1

REPLICA

ACTIVE

Doc 4

Doc 7

Doc

Doc

Doc 6

Doc 3

Doc

Doc

SERVER 2

REPLICA

ACTIVE

Doc 1

Doc 3

Doc

Doc

Doc 7

Doc 9

Doc

Doc

SERVER 3

SERVER 4

SERVER 5

REPLICA

ACTIVE

REPLICA

ACTIVE

Doc

Doc 8 Doc

Doc 9 Doc

Doc 2 Doc

Doc 8 Doc

Doc 5 Doc

Doc 6

READ/WRITE/UPDATE READ/WRITE/UPDATE

APP SERVER 1



APP SERVER 2



34

Fail Over Node

REPLICA

ACTIVE

Doc 5

Doc 2

Doc

Doc

Doc 4

Doc 1

Doc

Doc

SERVER 1

REPLICA

ACTIVE

Doc 4

Doc 7

Doc

Doc

Doc 6

Doc 3

Doc

Doc

SERVER 2

REPLICA

ACTIVE

Doc 1

Doc 3

Doc

Doc

Doc 7

Doc 9

Doc

Doc

SERVER 3

SERVER 4

SERVER 5

REPLICA

ACTIVE

REPLICA

ACTIVE

Doc 9

Doc 8

Doc Doc 6 Doc

Doc

Doc 5 Doc

Doc 2

Doc 8 Doc

Doc

•  App servers accessing docs

•  Requests to Server 3 fail

•  Cluster detects server failed –  Promotes replicas of docs to

acBve –  Updates cluster map

•  Requests for docs now go to appropriate server

•  Typically rebalance would follow

Doc

Doc 1 Doc 3

APP SERVER 1



APP SERVER 2



35

XDCR: Cross Data Center Replica6on

US DATA CENTER

EUROPE DATA CENTER

ASIA DATA CENTER

hhp://blog.groosy.com/wp-‐content/uploads/2011/10/internet-‐map.jpg

36

Cross Data Center Replica6on (XDCR) COUCHBASE SERVER CLUSTER NYC DATA CENTER

ACTIVE

Doc

Doc 2

SERVER 1

Doc 9

SERVER 2

SERVER 3

RAM

Doc Doc Doc

ACTIVE

Doc

Doc

Doc RAM

ACTIVE

Doc

Doc

Doc RAM

DISK

Doc Doc Doc

DISK

Doc Doc Doc

DISK

COUCHBASE SERVER CLUSTER SF DATA CENTER

ACTIVE

Doc

Doc 2

SERVER 1

Doc 9

SERVER 2

SERVER 3

RAM

Doc Doc Doc

ACTIVE

Doc

Doc

Doc RAM

ACTIVE

Doc

Doc

Doc RAM

DISK

Doc Doc Doc

DISK

Doc Doc Doc

DISK

37

Indexing and Querying Features

•  Index and Query   Distributed indexing and querying   Secondary indexes of JSON document content   Flexible querying of indexes

•  Incremental Map-‐Reduce   Distributed simple real-‐Bme analyBcs   Only considers changes due to updated data

•  Full Text Search   Robust integraBon with ElasBcSearch cluster   Flexible full text search and faceted search

38


Indexing and Querying


ACTIVE

Doc 5

Doc 2

Doc

Doc

Doc

SERVER 1

REPLICA

Doc 4

Doc 1

Doc 8

Doc

Doc

Doc

APP SERVER 1



APP SERVER 2

Doc 9

•  Indexing work is distributed amongst nodes

•  Large data set possible

•  Parallelize the effort

•  Each node has index for data stored on it

•  Queries combine the results from required nodes

ACTIVE

Doc 4

Doc 7

Doc

Doc

Doc

SERVER 2

REPLICA

Doc 6

Doc 3

Doc 2

Doc

Doc

Doc

Doc 8

ACTIVE

Doc 1

Doc 3

Doc

Doc

Doc

SERVER 3

REPLICA

Doc 7

Doc 9

Doc 5

Doc

Doc

Doc

Doc 6

Query

39

Full Text Search

40

Couchbase Demonstra6on

•  Star6ng with 4 database nodes under load

•  Dynamically scaling to 6 database nodes

•  Easy management and monitoring

•  JSON indexing and querying •  Easy configura6on of cross-‐

datacenter replica6on

•  Not possible any other database technology

Couchbase Servers

In the EC2 or Datacenter

Web applicaBon server

ApplicaBon user

XDCR

41

The Couchbase difference

42

Couchbase: The Complete NoSQL Solu6on

Easy Scalability

Flexible Data Model

Always On 24x7x365


when needed





new features

JSONJSONJSON

JSONJSON

PERFORMANCE


43


•  Consistent, predictable sub millisecond latency   Apps need fast, predictable access to data, it’s not good enough to be fast

some of the Bme

•  Consistent, predictable throughput   Throughput capacity of your data layer should be independent of the mix

of reads and writes

•  Linear throughput scalability   Double the number of servers, get twice the maximum throughput and

double the data capacity

44

YCSB Benchmark Details •  Web applica6on simula6on   Simulates changing set of users using the app/accessing data   Document size of 1.5-‐2K with 15 million acBve documents

•  Data doesn’t enBrely fit into RAM   Workload simulaBng realisBc mix of reads and writes (60/40)

•  System details   4 node cluster with seperate node to run client workload   AWS Extra Large instances with striped EBS   1 replica setup (For mongoDB -‐ no write concern, no journaling)   Each test run 3 Bmes with varying throughputs with 95% latency measured

•  YCSB test workload source code   hhps://github.com/Altoros/YCSB

45

Read performance comparison -‐ NoSQL databases

0

2

4

6

8

10

12

14

16

18

0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000 22000

95th Pe

rcen

6le Latency (m

s)

Opera6ons per Second

Read latencies against throughput

MongoDB cannot handle throughput above ~ 8000 ops / sec

Couchbase handles ~3X throughput with significantly lower latency

MongoDB

Cassandra

Couchbase

hhps://github.com/Altoros/YCSB

46

Write performance comparison -‐ NoSQL databases

0

5

10

15

20

25

30

0 2000 4000 6000 8000 10000 12000 14000 16000 18000 20000 22000

95th Pe

rcen

6le Latency (m

s)

Opera6ons per Second

Insert/update latencies against throughput

MongoDB latency shoots up beyond 6000 ops / sec

Couchbase latency stays consistently low even at 20000 ops / sec

MongoDB

Cassandra

Couchbase

47

LinkedIn 4 node cluster

48


Easy Scalability

Flexible Data Model

Always On 24x7x365


when needed





new features

JSONJSONJSON

JSONJSON

PERFORMANCE


49

Couchbase: High throughput that scales linearly

Linear throughput scalability

High throughput with 1.4 GB/sec data transfer rate

using 4 servers

hhp://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-‐708169.pdf

50

Draw Something “Goes Viral” 3 Weeks Azer Launch

Draw Something by OMGPOP Daily Ac)ve Users (millions)

Feb 2012 March 2012

51

As Usage Grew, Game Data Went Non-‐Linear Draw Something by OMGPOP

Daily Ac)ve Users (millions)

Feb 2012 March 2012

52


Easy Scalability

Flexible Data Model

Always On 24x7x365


when needed





new features

JSONJSONJSON

JSONJSON

PERFORMANCE


53

The Sun Never Sets on the Internet

hhp://personal.bgsu.edu/~tede/020522_briBshempire1360.jpg

54

Always-‐On 24x7x365: Proof Point Example

0 20 40 60 80 100

82

57

72

Couchbase

Data Store Availability

55

Couchbase Server Is The Complete Solu6on

One click scalability and no app changes.

Sub millisecond latency with high throughput for reads and writes.

Maintenance, upgrades and cluster resizing all online without applicaBon downBme

JSON document model with no fixed schema.

✔

✔

✔

✔


Flexible Data Model

Easy Scalability

Always On 24x7x365

56

Couchbase Server vs. MongoDB

Easy Scalability

Consistent, High Performance

Flexible Data Model

Always On 24x7x365

Consistent sub millisecond reads/writes; Consistent high throughput

No downBme for so`ware upgrades, hardware maintenance, etc.

Schemaless data model for rapid development

With 1-‐click, horizontally grow cluster, even scale across datacenters

High & Inconsistent latency; Lower throughput


Difficult online upgrade; Not all maintenance is online

Complex mulB-‐step scaling, no write scaling across data centers

✔ ✖

✔

✔

✔

✔

✖

✖

✔

57

Consistent Lower Latencies and Higher Throughput

•  Couchbase   High read and write throughput and consistent low latencies   Write performance advantage due to low granularity of Couchbase

memory locking mechanism and minimal contenBon   Read operaBons happen concurrently with, and independently of writes

•  MongoDB   Severely limited write throughput due to very coarse write locks that limit

concurrency at the node level   Inconsistent latencies and throughput as all reads need to wait for a write

to finish.

•  Cost Considera6ons

58

Couchbase Server vs. Cassandra

Easy Scalability

Consistent, High Performance

Flexible Data Model

Always On 24x7x365

Consistent sub-‐millisecond reads/writes and high throughput

No downBme for so`ware upgrades, hardware maintenance, etc.


With 1-‐click, horizontally grow cluster, even scale across datacenters

High and inconsistent latency; medium throughput

Very complex columnar data model

Online upgrades and online maintenance

Complex mulB-‐step scaling, coarse grain growth recommended

✔

✔

✔

✔ ✖

✖

✖

✔

59

Next steps

60

Enterprise vs. Community Edi6on Enterprise Edi6on Community Edi6on

Cost •  Free for pre-‐producBon •  StarBng at $2,499/node/yr

•  Free

Produc6on Readiness

ProducBon Ready •  Take open source snapshots • Put through rigorous QA process, fix bugs

Unknown ProducBon Readiness • Built with latest open source • Undefined quality

Technical Support

Professional Support • Defined SLAs from the experts •  Immediate hot bug fixes

Community/Forum Support • No SLA, unknown response Bmes • No bugs fixes assured in a Bmely manner

Best Prac6ce Exper6se

Broad Best PracBce ExperBse •  From working with 100s of customers

ExperBse of community members • Based on limited individual experBse

Release Support

Long-‐Tail Release Support •  Including hot bug fixes

No Support for Old Releases • Must support old releases yourself

License Type Commercial License •  Std license terms, SLA, indemnity

Simple “As is” license

Intended Use ProducBon Deployments Non-‐ProducBon Use, Simple Use Cases

61

Next Steps: The Path to Produc6on ü  Couchbase Overview – Done 2.   Technical session

• Who: Architects/Developers and Couchbase SoluBons Architect

• Deployment and development best pracBces • OperaBons deep-‐dive • Tech Q&A

3.   Design review •  Review and feedback on design and feature usage • Verify assumpBons and use of Couchbase APIs

4.   Produc6on deployment

62

Thank you

Couchbase NoSQL Document Database

63

Backup Slides

64

Couchbase Server Features •  Graphical monitoring and admin console with RESTful interface   Single click cluster resizing, powerful monitoring accessible via every node

•  Online upgrades, backups and database maintenance   Database is always online, applicaBons can be available 24x7x365

•  All nodes are iden6cal   Easy provisioning on all supported plaxorms: Linux, Windows, MacOS

•  Supported SDKs for all common languages   Easy adopBon by developers for Java, .NET, PHP, Ruby, C/C++

65

Couchbase performance with varying document sizes

Consistently low latencies sub-‐millisecond for

varying documents sizes with a mixed workload

66

Enterprise Edi6on Subscrip6ons Standard Premium

Price/node $2499

$4499

Licensing Per node

Per node

Support Hours 10 X 5

24 X 7

Hours of Opera6on

7am – 5pm Pacific Standard Time

N/A

Support Channel Phone, Email, Web, Forums

Phone, Email, Web, Forums

P1 Response Time 5 hours 2 hours

P2 Response Time 1 day 5 hours

Update releases Yes Yes

Ho{ixes Yes Yes

Technical Alerts Yes Yes

hhp://www.couchbase.com/couchbase-‐support-‐and-‐subscripBons

67

Replace a Memcached Tier with Couchbase Server

68

Challenges with a Memcached Tier Problem Symptoms Couchbase Solu6on

Cold Cache Slowdown or collapse of the data service layer due to heavily overloaded RDBMS when

memcached nodes go down (on failure or for maintenance)

Data is automaBcally replicated across the Couchbase cluster, providing high availability of data even on failures

Heavy RDBMS Conten6on

MulBple requests for data items that do not exist in the cache results in sudden shi`ing of load to the

relaBonal database causing heavy contenBon

By replicaBng data across the cluster, Couchbase Server provides consistent performance without shi`ing load to

the RDBMS layer

Lack of Scalability Adding or removing memcached nodes is complicated and causes

unpredictable applicaBon performance degradaBon

Auto-‐sharding and online rebalancing in Couchbase Server provides easy non-‐

disrupBve expansion of the cluster

Complex Monitoring

Management of individual memcached nodes increases the

complexity of operaBons and lacks a single consistent view of the caching

layer

Couchbase Server provides an in-‐built admin console for cluster wide

management and monitoring as well as RESTful APIs for easy automaBon and

third-‐party integraBon

69

Before and Azer: Replacing Caching Tier with Couchbase

Server

70

Memcached Tier Replacement: How it Works

•  Fully memcached protocol compa6ble

•  Easy to replace a 6er of individual memcached servers with a Couchbase Server cluster

•  The cluster receives reads and writes, keeps frequently accessed items in memory, persists and shards and replicates the data amongst the cluster

•  Reads and writes are s6ll as low latency and high throughput as memcached

•  User gets all the scalability and high-‐availability advantages of a Couchbase Server cluster

71

[email protected]

Draw Something Success Story

72

How to Prepare Your Social Game for Massive Growth Published February 2, 2012

hhp://mashable.com/2012/02/01/social-‐game-‐prepare-‐growth/

Five days later…

73

Draw Something by OMGPOP

74

Draw Something “Goes Viral” 3 Weeks Azer Launch

Draw Something by OMGPOP Daily Ac)ve Users (millions)

75

As Usage Grew, Game Data Went Non-‐Linear Draw Something by OMGPOP

Daily Ac)ve Users (millions)

76

In Contrast… The Simpson’s: Tapped Out Daily Ac)ve Users (millions)