Couchbase Overview Nov 2013
1 like849 views
The document provides an overview of Couchbase's NoSQL document database capabilities for interactive applications. It discusses Couchbase's leadership in the NoSQL market, common use cases where NoSQL is a good fit like mobile apps and caching, and how Couchbase allows for JSON data everywhere from devices to servers. Relational databases are compared to Couchbase, with Couchbase able to scale out more easily to very large datasets and workloads.
Couchbase Overview Nov 2013
- 1. Data Management for Interac6ve Applica6ons NoSQL Document Database Jeff Harris Business Development 1
- 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) 2
- 3. Couchbase NoSQL Leadership Leading NoSQL database company Open Source development & business model Document-‐oriented NoSQL database Focused on interacBve internet and mobile applicaBons Provide more flexible, higher performance, more scalable database than rela6onal alterna6ve 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 3
- 4. Market Adop6on – Customers Internet Companies Enterprises More than 350 customers – 7,500 produc6on deployments worldwide 4
- 5. Market Adop6on Internet Companies • • • • • • • • Enterprises • CommunicaBons • Retail • Financial Services • Health Care • AutomoBve/Airline • Agriculture • Consumer Electronics • Business Systems Social Gaming Ad Networks Social Networks Online Business Services E-‐Commerce Online Media Content Management Cloud Services 5
- 6. Two kinds of Database Management System OLTP / OLTP like Opera6onal Stores Data warehouse or Analy6cs system 6
- 7. Adding a few more components InteracBve OLTP / OLTP like Opera6onal Stores ETL Streaming Data RDBMS Other legacy systems BI & ReporBng Analy6cs Data warehouse 7 RDBMS Column stores
- 8. NoSQL + Big Data Opera6onal database for web and mobile apps with high performance at scale Map-‐reduce against huge datasets to analyze and find insights and answers 8
- 9. Common Use Cases Social Gaming Ad Targe6ng • Couchbase stores player and game data • Examples customers include: Zynga • Tapjoy, Ubiso`, Tencent • Couchbase stores user informaBon for fast access • Examples customers include: AOL, Mediamind, Convertro Mobile Apps • Couchbase stores user info and app content • Examples customers include: Kobo, PlayBka 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 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 • Couchbase Server used as a cache Ber replacement • Examples customers include: LivePerson • Examples customers include: Orbitz 9
- 10. Couchbase Lite The only Na6ve NoSQL Database for Mobile 10
- 11. The Complete Mobile Solu6on 11
- 12. JSON Anywhere JS N Couchbase Server Sync Gateway Lite Server JS N JS N • JSON on the device • JSON on the wire Developers increasingly prefer NoSQL database No need for data transformaBon 12 • JSON in the cloud Flexible data model High performance Easy scalability
- 13. Rela6onal Vs NoSQL Document databases 13
- 14. Rela6onal Technology Scales Up Applica6on Scales Out Just add more commodity web servers System Cost ApplicaBon Performance Web/App Server Tier Users RDBMS Scales Up Get a bigger, more complex server System Cost ApplicaBon Performance Won’t scale beyond this point Rela6onal Database Users Expensive and disrup6ve sharding, doesn’t perform at web scale 14
- 15. Couchbase Server Scales Out Like App Tier Applica6on Scales Out Just add more commodity web servers System Cost ApplicaBon Performance Web/App Server Tier Users NoSQL Database Scales Out Cost and performance mirrors app 6er System Cost ApplicaBon Performance Couchbase Distributed Data Store Users Scaling out flabens the cost and performance curves 15
- 16. If Cars Were Stored in an RDBMS… hhp://iedei.files.wordpress.com/2012/04/mercedes-‐f1-‐car-‐disassembled.jpeg 16
- 17. If Cars Were Stored in a Document Database… hhp://images.conceptcarz.com/imgxra/Mercedes-‐Benz/Mercedes-‐W03-‐F1-‐Spanish-‐GP_012-‐1680.jpg 17
- 18. Rela6onal vs Document Data Model C1 C2 C3 C4 { } JSON JSON JSON Rela6onal data model Document data model Highly-‐structured table organizaBon with rigidly-‐defined data formats and record structure. CollecBon of complex documents with arbitrary, nested data formats and varying “record” format. 18
- 19. RDBMS Example: User Profile User Info Address Info KEY First Last ZIP_id ZIP_id CITY STATE ZIP 1 Frank Weigel 2 1 DEN CO 30303 2 Ali Dodson 2 2 MV CA 94040 3 Mark Azad 2 3 CHI IL 60609 4 Steve Yen 3 4 NY NY 10010 To get info about specific user, you perform a join across two tables 19
- 20. Document Example: User Profile { “ID”: 1, “FIRST”: “Frank”, “LAST”: “Weigel”, “ZIP”: “94040”, “CITY”: “MV”, “STATE”: “CA” } + = JSON All data in a single document 20
- 21. 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” } JSON Just add informa6on to a document
- 22. Rela6onal vs Document Performance User Table Photo Table User ID First Last Zip 1 Frank Wiegel Weigel 94040 2 Joe Smith 94040 3 Ali Dodson 94040 4 Sarah Gorin Bob Young 30303 6 Nancy Baker 10010 7 Ray Jones 31311 8 Lee Chen V5V3 Photo ID Comment 2 d043 NYC 2 b054 Bday 5 c036 Miami 7 d072 Sunset 5002 e086 Spain NW1 5 User ID Status Table Status ID Text 1 a42 At conf 4 5 b26 c032 excited 5 4 c32 b26 hockey 12 • • • User ID d83 Go A’s 5000 e34 sailing Affilia6ons Table 5000 Doug Moore 04252 5001 Mary White 41694 User ID Affilia6ons Affilia6ons ID Name Lisa Lisa Clark 12425 a42 Cal 4 b96 USC 7 5002 5002 2 c14 UW 8 e22 { { { { { { } } } JSON JSON } } JSON JSON } JSON JSON Oxford Faster response 6mes and higher throughput
- 23. NoSQL Database Considera6ons Easy Scalability PE RF O R M A N C E Grow cluster without applicaBon changes, without downBme when needed Consistent High Performance Always awesome experience for your applicaBon users. Always On 24x7x365 JSON JSON JSO JSON N JSON Flexible Data Model Keep developers producBve and allow fast and easy addiBon of new features The sun never sets on the Internet, your applicaBon needs the database to always serve data. 23
- 24. Couchbase Server Is The Complete Solu6on ✔ Easy Scalability Consistent High ✔ Performance One click scalability and no app changes. Sub millisecond latency with high throughput for reads and writes. Always On ✔ 24x7x365 Maintenance, upgrades and cluster resizing all online without applicaBon downBme ✔ Flexible Data Model JSON document model with no fixed schema. 24
- 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 25
- 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 26
- 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 27
- 28. Couchbase solu6on “The basics” 28
- 29. Single node -‐ Couchbase Write Opera6on App Server Doc 1 3 2 Managed Cache ReplicaBon Queue Doc 1 Disk Queue To other node 3 Disk Couchbase Server Node 29
- 30. Single node -‐ Couchbase Update Opera6on App Server Doc 1’ 3 2 Managed Cache ReplicaBon Queue Doc 1 Doc 1’ Disk Queue To other node 3 Disk Doc 1 Couchbase Server Node 30
- 31. App Server GET Doc 1 Single node -‐ Couchbase Read Opera6on 3 2 Managed Cache ReplicaBon Queue Doc 1 Disk Queue To other node 3 Disk Doc 1 Couchbase Server Node 31
- 32. Basic Opera6on APP SERVER 1 APP SERVER 2 COUCHBASE Client Library CLUSTER MAP COUCHBASE Client Library CLUSTER MAP READ/WRITE/UPDATE SERVER 1 ACTIVE SERVER 2 ACTIVE • Docs distributed evenly across servers SERVER 3 ACTIVE • Each server stores both ac6ve and replica docs Doc 5 Doc Doc 4 Doc Doc 1 Doc Doc 2 Doc Doc 7 Doc Doc 3 Doc Only one server acBve at a Bme Doc 9 Doc Doc 8 Doc Doc 6 Doc • Client library provides app with simple interface to database REPLICA REPLICA REPLICA • Cluster map provides map to which server doc is on Doc 4 Doc Doc 6 Doc Doc 7 Doc Doc 1 Doc Doc 3 Doc Doc 9 Doc • App reads, writes, updates docs Doc 8 Doc Doc 2 Doc Doc 5 Doc • Mul6ple app servers can access same document at same 6me App never needs to know COUCHBASE SERVER CLUSTER User Configured Replica Count = 1 32
- 33. Add Nodes to Cluster APP SERVER 1 APP SERVER 2 COUCHBASE Client Library CLUSTER MAP COUCHBASE Client Library CLUSTER MAP READ/WRITE/UPDATE SERVER 1 ACTIVE SERVER 2 ACTIVE READ/WRITE/UPDATE SERVER 3 ACTIVE Doc 5 Doc Doc 4 Doc Doc 1 Doc Doc 7 Doc Doc 3 Doc Doc 9 Doc Doc 8 Doc Doc 6 SERVER 5 ACTIVE Doc Doc 2 SERVER 4 ACTIVE Doc REPLICA REPLICA REPLICA Doc 4 Doc Doc 6 Doc Doc 7 Doc Doc 3 Doc Doc 9 Doc Doc 2 Doc Doc 5 Even distribuBon of docs Minimum doc movement • Cluster map updated REPLICA Doc Doc 8 • Docs automa6cally rebalance across cluster Doc Doc 1 Doc COUCHBASE SERVER CLUSTER User Configured Replica Count = 1 • Two servers added with one-‐click opera6on 33 REPLICA • App database calls now distributed over larger number of servers
- 34. Fail Over Node APP SERVER 1 APP SERVER 2 COUCHBASE Client Library CLUSTER MAP COUCHBASE Client Library CLUSTER MAP SERVER 1 ACTIVE SERVER 2 ACTIVE SERVER 3 ACTIVE SERVER 4 ACTIVE Doc 5 Doc Doc 4 Doc Doc 1 Doc Doc 9 Doc Doc 2 Doc Doc 7 Doc Doc 3 Doc Doc 8 SERVER 5 ACTIVE Doc Doc 1 Doc 6 Doc Doc Doc 3 REPLICA REPLICA REPLICA REPLICA Doc 4 Doc Doc 6 Doc Doc 7 Doc Doc 5 Doc 1 Doc Doc 3 Doc Doc 9 Doc Doc Doc 2 Doc 8 Doc Doc COUCHBASE SERVER CLUSTER User Configured Replica Count = 1 REPLICA 34 • 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
- 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 35
- 36. Cross Data Center Replica6on (XDCR) SERVER 2 ACTIVE SERVER 1 ACTIVE SERVER 3 ACTIVE Doc Doc Doc Doc 2 RAM Doc Doc COUCHBASE SERVER CLUSTER NYC DATA CENTER Doc Doc 9 Doc RAM Doc DISK Doc Doc Doc RAM Doc Doc Doc DISK Doc Doc DISK SERVER 2 ACTIVE SERVER 1 ACTIVE SERVER 3 ACTIVE Doc COUCHBASE SERVER CLUSTER SF DATA CENTER Doc Doc Doc 2 RAM Doc Doc Doc Doc 9 Doc DISK RAM Doc 36 Doc Doc Doc DISK RAM Doc Doc Doc Doc DISK Doc
- 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 37
- 38. Indexing and Querying APP SERVER 1 APP SERVER 2 COUCHBASE Client Library CLUSTER MAP COUCHBASE Client Library CLUSTER MAP Query SERVER 1 ACTIVE SERVER 2 ACTIVE SERVER 3 ACTIVE • Indexing work is distributed amongst nodes Doc 5 Doc Doc 4 Doc Doc 1 Doc • Large data set possible Doc 2 Doc Doc 7 Doc Doc 3 Doc • Parallelize the effort Doc 9 Doc Doc 8 Doc Doc 6 Doc REPLICA REPLICA REPLICA Doc 4 Doc Doc 6 Doc Doc 7 Doc Doc 1 Doc Doc 3 Doc Doc 9 Doc Doc 8 Doc Doc 2 Doc Doc 5 Doc COUCHBASE SERVER CLUSTER User Configured Replica Count = 1 38 • Each node has index for data stored on it • Queries combine the results from required nodes
- 39. Full Text Search 39
- 40. Couchbase Demonstra6on • Star6ng with 4 database nodes under load • Dynamically scaling to 6 database nodes ApplicaBon user • Easy management and monitoring Web applicaBon server • JSON indexing and querying • Easy configura6on of cross-‐ datacenter replica6on Couchbase Servers In the EC2 or Datacenter • Not possible any other database technology 40 XDCR
- 41. The Couchbase difference 41
- 42. Couchbase: The Complete NoSQL Solu6on Easy Scalability PE Grow cluster without applicaBon changes, without downBme when needed Consistent High Performance RF O R M A N C E Always awesome experience for your applicaBon users. Always On 24x7x365 JSON JSON JSO JSON N JSON Flexible Data Model Keep developers producBve and allow fast and easy addiBon of new features The sun never sets on the Internet, your applicaBon needs the database to always serve data. 42
- 43. Consistent High Performance • 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 43
- 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 44
- 45. Read performance comparison -‐ NoSQL databases Read latencies against throughput 18 95th Percen6le Latency (ms) 16 Cassandra 14 12 10 8 MongoDB cannot handle throughput above ~ 8000 ops / sec 6 Couchbase handles ~3X throughput with significantly lower latency 4 MongoDB Couchbase 2 0 0 2000 4000 6000 hhps://github.com/Altoros/YCSB 8000 10000 12000 14000 Opera6ons per Second 45 16000 18000 20000 22000
- 46. Write performance comparison -‐ NoSQL databases Insert/update latencies against throughput 95th Percen6le Latency (ms) 30 25 MongoDB 20 MongoDB latency shoots up beyond 6000 ops / sec 15 Cassandra 10 Couchbase latency stays consistently low even at 20000 ops / sec 5 Couchbase 0 0 2000 4000 6000 8000 10000 12000 14000 Opera6ons per Second 46 16000 18000 20000 22000
- 47. LinkedIn 4 node cluster 47
- 48. NoSQL Database Considera6ons Easy Scalability PE Grow cluster without applicaBon changes, without downBme when needed Consistent High Performance RF O R M A N C E Always awesome experience for your applicaBon users. Always On 24x7x365 JSON JSON JSO JSON N JSON Flexible Data Model Keep developers producBve and allow fast and easy addiBon of new features The sun never sets on the Internet, your applicaBon needs the database to always serve data. 48
- 49. Couchbase: High throughput that scales linearly High throughput with 1.4 GB/sec data transfer rate using 4 servers Linear throughput scalability hhp://www.cisco.com/en/US/prod/collateral/switches/ps9441/ps9670/white_paper_c11-‐708169.pdf 49
- 50. Draw Something “Goes Viral” 3 Weeks Azer Launch Draw Something by OMGPOP Daily Ac)ve Users (millions) Feb 2012 50 March 2012
- 51. As Usage Grew, Game Data Went Non-‐ Draw Something by OMGPOP Linear Daily Ac)ve Users (millions) Feb 2012 51 March 2012
- 52. NoSQL Database Considera6ons Easy Scalability PE Grow cluster without applicaBon changes, without downBme when needed Consistent High Performance RF O R M A N C E Always awesome experience for your applicaBon users. Always On 24x7x365 JSON JSON JSO JSON N JSON Flexible Data Model Keep developers producBve and allow fast and easy addiBon of new features The sun never sets on the Internet, your applicaBon needs the database to always serve data. 52
- 53. The Sun Never Sets on the Internet hhp://personal.bgsu.edu/~tede/020522_briBshempire1360.jpg 53
- 54. Always-‐On 24x7x365: Proof Point Example Data Store Availability 72 57 Couchbase 82 0 20 40 60 80 54 100
- 55. Couchbase Server Is The Complete Solu6on ✔ Easy Scalability Consistent High ✔ Performance One click scalability and no app changes. Sub millisecond latency with high throughput for reads and writes. Always On ✔ 24x7x365 Maintenance, upgrades and cluster resizing all online without applicaBon downBme ✔ Flexible Data Model JSON document model with no fixed schema. 55
- 56. Couchbase Server vs. MongoDB Easy Scalability Consistent, High Performance Flexible Data Model Always On 24x7x365 With 1-‐click, horizontally ✔ grow cluster, even scale across datacenters Consistent sub millisecond ✔ reads/writes; throughput Consistent high ✔ Schemaless data model for rapid development ✔ No downBme for so`ware upgrades, hardware maintenance, etc. 56 ✖ Complex mulB-‐step scaling, no write scaling across data centers ✖ High & Inconsistent latency; Lower throughput ✔ Schemaless data model for rapid development ✖ ✔ Difficult online upgrade; Not all maintenance is online
- 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 57
- 58. Couchbase Server vs. Cassandra Easy Scalability ✔ With 1-‐click, horizontally grow cluster, even scale across datacenters Consistent, High ✔ Performance Consistent sub-‐millisecond reads/writes and high throughput Flexible Data Model ✔ Schemaless data model for rapid development ✔ No downBme for so`ware upgrades, hardware maintenance, etc. Always On 24x7x365 58 ✖ Complex mulB-‐step scaling, coarse grain growth recommended ✖ High and inconsistent latency; medium throughput ✖ Very complex columnar data model ✔ Online upgrades and online maintenance
- 59. Next steps 59
- 60. Enterprise vs. Community Edi6on Enterprise Edi6on Cost Community Edi6on • Free for pre-‐producBon • StarBng at $2,499/node/yr • Free Produc6on Readiness ProducBon Ready Unknown ProducBon Readiness Technical Support Professional Support Community/Forum Support Best Prac6ce Exper6se Broad Best PracBce ExperBse ExperBse of community members Release Support Long-‐Tail Release Support No Support for Old Releases License Type Commercial License Simple “As is” license Intended Use ProducBon Deployments Non-‐ProducBon Use, Simple Use Cases • Take open source snapshots • Put through rigorous QA process, fix bugs • Defined SLAs from the experts • Immediate hot bug fixes • Built with latest open source • Undefined quality • No SLA, unknown response Bmes • No bugs fixes assured in a Bmely manner • From working with 100s of customers • Including hot bug fixes • Based on limited individual experBse • Must support old releases yourself • Std license terms, SLA, indemnity 60
- 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 61
- 62. Thank you Couchbase NoSQL Document Database 62
- 63. Backup Slides 63
- 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++ 64
- 65. Couchbase performance with varying document sizes Consistently low latencies sub-‐millisecond for varying documents sizes with a mixed workload 65
- 66. Enterprise Edi6on Subscrip6ons Standard Premium $2499 $4499 Per node Per node 10 X 5 24 X 7 7am – 5pm Pacific Standard Time N/A 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 Price/node Licensing Support Hours Hours of Opera6on Support Channel hhp://www.couchbase.com/couchbase-‐support-‐and-‐subscripBons 66
- 67. Replace a Memcached Tier with Couchbase Server 67
- 68. Challenges with a Memcached Tier Problem Cold Cache Heavy RDBMS Conten6on Lack of Scalability Complex Monitoring Symptoms Couchbase Solu6on 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 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 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 Management of individual Couchbase Server provides an in-‐built memcached nodes increases the admin console for cluster wide complexity of operaBons and lacks a management and monitoring as well as single consistent view of the caching RESTful APIs for easy automaBon and layer third-‐party integraBon 68
- 69. Before and Azer: Replacing Caching Tier with Couchbase Server 69
- 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 70
- 71. Draw Something Success Story sales@couchbase.com 71
- 72. How to Prepare Your Social Game for Massive Growth Published February 2, 2012 Five days later… hhp://mashable.com/2012/02/01/social-‐game-‐prepare-‐growth/ 72
- 73. Draw Something by OMGPOP 73
- 74. Draw Something “Goes Viral” 3 Weeks Azer Launch Draw Something by OMGPOP Daily Ac)ve Users (millions) 74
- 75. As Usage Grew, Game Data Went Non-‐ Draw Something by OMGPOP Linear Daily Ac)ve Users (millions) 75
- 76. In Contrast… The Simpson’s: Tapped Out Daily Ac)ve Users (millions) 76