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.

Betfair + Couchbase


Published on

Martin Anderson presents the

Published in: Technology
  • Be the first to comment

Betfair + Couchbase

  1. 1. BETFAIR + COUCHBASEMartin Anderson
  2. 2. AGENDA• Who Betfair are• Why Couchbase was chosen at Betfair• What it is being used for• Some thoughts on adopting NoSQL in Enterprises• Q&A session later on today2
  3. 3. BETFAIR3
  4. 4. 4
  6. 6. IN NUMBERS 4.0m+ 30,000 Funded 140 bets placed Accounts locations one minute 120,000+ £288m requests per funds on £2.2bn second deposit Mobile FY126
  8. 8. DATA AT BETFAIR• >30,000 markets that can change every 100ms• Jurisdictionally sensitive navigation• Multiple web applications for multiple channels• Large volumes of data from other products• Transactional data• Operational monitoring too - large amount of logging data8
  9. 9. TECHNOLOGY AT BETFAIRApplication Stack• JVM heavy• Linux on commodity hardware• Heavy use of Virtualisation/Private CloudData Storage Stack• Oracle• Some Informix & MySQL• NoSQL9
  10. 10. RELATIONAL DATABASES We love Oracle! The lifeblood of our transaction system Highly performant Well understood Resilient Other databases but they are effectively integrated products10
  11. 11. BUT… Impedance mismatch with object orientated languages Object models possible in RDBMS but at what cost? Must have serious skills at this scale Scaling not easy Often very heavyweight solution Integration with Continuous Delivery? So what about NoSQL?11
  12. 12. NOSQL AT BETFAIR12
  13. 13. NOSQL Matches well to object orientated languages Inherently scalable Very fast look ups Integrates very well with Continuous Delivery Combines to give a lower time to delivery13
  14. 14. NOSQL AT BETFAIR14
  15. 15. WHY SO MANY? Different categories of NoSQL, therefore different usage: K/V, Document, Columnar Some are wrapped by other products • CouchDB & Chef • HBase & OpenTSDB But what about cases where we have direct usage? What was the selection criteria for these solutions?15
  16. 16. THE PRESSURE OF DELIVERY Just finished a cycle of high product delivery focus Time to step back and reassess the selections But without negatively affecting current product delivery!16
  17. 17. STRATEGIC REVIEW Good News We had a fair amount of experience with different NoSQL solutions Bad News Fairly certain that some of the uses were less than optimal17
  18. 18. ADOPTION AND ASSESSMENT PROCESS • What were our use cases? • What would be the optimum solutions?18
  19. 19. NOSQL ASSESSMENT PROCESS • Background/Maturity of the technology • Data Model Category • Consistency Model Requirements • Performance • Replication strategy (inc. Concurrency Control) • Caching Model • Query Model • Integration with Continuous Delivery19
  20. 20. NOSQL ASSESSMENT PROCESS • Operational Maintenance (inc. Backup) • Operational Monitoring • Support • Scalability • Reliability • Security • Cost20
  21. 21. INITIAL USE CASES FOR NOSQL Web Tier Persistence • Session and Cross session storage – e.g. Betslip • Memcached • Strong consistency • Cookie abuse • Cassandra as current solution21
  22. 22. INITIAL USE CASES FOR NOSQL User Preferences • Historically tied to customer account • Map of keys and values • Multiple channels with multiple applications • RDBMS as current solution22
  23. 23. CURRENT ARCHITECTURE Server side rendered content SOA Data Services exposed Supports >200,000 concurrent users23
  25. 25. OUR SELECTION CRITERIA • Performance - especially deterministic performance on VMs • Strong consistency • Scaling • Schema flexibility • Multi-tenancy when required • Simplicity • Enterprise support • Consider the future uses25
  26. 26. COUCHBASE26
  27. 27. COUCHBASE PERFORMANCE • Seriously fast • Highly deterministic • Cache ejection/eviction • Avoids Cold Cache on offlined instances • Ideal for our architecture – virtualisation/private cloud • Far better option than our current solution27
  28. 28. COUCHBASE SCALING • Inherently scalable • Impressive ability to add nodes under load • Manual rebalance gives control for highly loaded applications • Replica promotion avoids failure cascades under load28
  29. 29. COUCHBASE SCHEMA FLEXIBILITY • Giving the developers ownership of the data storage • Decouples data migration from application deployment • Important requirement for Feature Throttles • Removes many of the requirements for having DB devs/DBAs • Allows preferences to deal with A/B tests29
  30. 30. OTHER COUCHBASE FEATURES • Multi-tenancy when required • Stable and Resilient • Great ease of use for both Devs and Ops • Enterprise support • Elastic Search integration • Secured with a Service Layer30
  32. 32. COUCHBASE DEPLOYMENTS • Version 1.8 in production, some 2.0 in pre-prod • 3 instance clusters for individual web applications • Larger (4-6) instance clusters for service storage • We are about 6 months in with our production instances32
  36. 36. COUCHBASE AT BETFAIR Couchbase is now our strategic document NoSQL solution • Session state • Cross session state • Service Persistence for key-based Entities • Familiarity will likely see this extend out into other areas36
  37. 37. INTRODUCING NOSQL IN ENTERPRISE AKA CULTURE HACKING WITH NOSQL • Remember its an umbrella term - non-experts will ask why we need so many different types of NoSQL • Remember the business benefits • Present the business with both the use cases you want to adopt NoSQL for and the assessment of the candidates • When you can use it, get it out there ASAP in a low risk way • It’s not about choosing what’s cool, it’s about choosing what’s best for the business37
  38. 38. THANK YOU! Martin Anderson @mdjanderson http://betfair.jobs38