Webinar - Moving from MySQL to Couchbase

3,064 views
2,773 views

Published on

Many organizations are making the shift from relational databases to NoSQL. In this webinar we'll cover the important things you need to keep in mind in moving from MySQL to Couchbase for your application.

Published in: Technology
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,064
On SlideShare
0
From Embeds
0
Number of Embeds
1,385
Actions
Shares
0
Downloads
62
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide
  • These are the market segments
  • Partial listing of companies with paid production deploymentsThousands more using open source
  • Webinar - Moving from MySQL to Couchbase

    1. 1. Moving from MySQLto CouchbaseDon PintoProduct Marketing Manager
    2. 2. Why transition to NoSQL?
    3. 3. You are here because..You want to build an app
    4. 4. and currently have a relationaldatabase
    5. 5. It’s probably gotten a little bit big..http://www.seoclerks.com/imagedb/2005/BIG-CAT-FOUND-Spoh
    6. 6. Or maybe hugehttp://www.2pep.com/extreme-funny-stuff/
    7. 7. And complicated
    8. 8. You’re not aloneTop two big drivers for NoSQLadoptionLack of flexibility/rigid schemasInability toscale out dataPerformancechallengesCost All of these Other49%35%29%16%12%11%Source: Couchbase Survey, December 2011, n = 1351.
    9. 9. NoSQL catalogKey-Valuememcached redisData Structure Document Column GraphmongoDBcouchbase cassandraCache(memoryonly)Database(memory/disk)Neo4j
    10. 10. Distributed DOCUMENT DATABASES
    11. 11. Document Databases• Each record in the database is a self-describing document• Each document has an independentstructure• Documents can be complex• All databases require a unique key• Documents are stored using JSON orXML or their derivatives• Content can be indexed and queried• Offer auto-sharding for scaling andreplication for high-availability{“UUID”: “21f7f8de-8051-5b89-86“Time”: “2011-04-01T13:01:02.42“Server”: “A2223E”,“Calling Server”: “A2213W”,“Type”: “E100”,“Initiating User”: “dsallings@spy.net”,“Details”:{“IP”: “10.1.1.22”,“API”: “InsertDVDQueueItem”,“Trace”: “cleansed”,“Tags”:[“SERVER”,“US-West”,“API”]}}
    12. 12. Comparison of DATA Models
    13. 13. Relational vs Document data modelRelational data model Document data modelCollection of complex documents witharbitrary, nested data formats andvarying “record” format.Highly-structured table organizationwith rigidly-defined data formats andrecord structure.JSONJSONJSONC1 C2 C3 C4{}
    14. 14. Example: User ProfileAddress Info1 DEN 30303CO2 MV 94040CA3 CHI 60609ILUser InfoKEY First ZIP_idLast4 NY 10010NY1 Dipti 2Borkar2 Joe 2Smith3 Ali 2Dodson4 John 3DoeZIP_id CITY ZIPSTATE1 22 MV 94040CATo get information about specific user, you perform a join across two tables
    15. 15. All data in a single documentDocument Example: User Profile{“ID”: 1,“FIRST”: “Dipti”,“LAST”: “Borkar”,“ZIP”: “94040”,“CITY”: “MV”,“STATE”: “CA”}JSON= +
    16. 16. User ID First Last Zip1 Dipti Borkar 940402 Joe Smith 940403 Ali Dodson 940404 Sarah Gorin NW15 Bob Young 303036 Nancy Baker 100107 Ray Jones 313118 Lee Chen V5V3M•••50000 Doug Moore 0425250001 Mary White SW19550002 Lisa Clark 12425CountryIDTEL3001Country ID Country name001 USA002 UK003 Argentina004 Australia005 Aruba006 Austria007 Brazil008 Canada009 Chile•••130 Portugal131 Romania132 Russia133 Spain134 SwedenUser ID Photo ID Comment2 d043 NYC2 b054 Bday5 c036 Miami7 d072 Sunset5002 e086 SpainPhoto Table001007001133133User ID Status ID Text1 a42 At conf4 b26 excited5 c32 hockey12 d83 Go A’s5000 e34 sailingStatus Table134007008001005Country TableUser ID Affl ID Affl Name2 a42 Cal4 b96 USC7 c14 UW8 e22 OxfordAffiliations TableCountryID001001001002CountryIDCountryID001001002001001001008001002001User Table...Making a Change Using RDBMS
    17. 17. Making the Same Change with a DocumentDatabase{“ID”: 1,“FIRST”: “Don”,“LAST”: “Pinto”,“ZIP”: “94040”,“CITY”: “MV”,“STATE”: “CA”,“STATUS”:{ “TEXT”: “At Conf”}}“GEO_LOC”: “134” },“COUNTRY”: ”USA”Just add information to a documentJSON,}
    18. 18. Where is NoSQL a good fit?
    19. 19. Market AdoptionInternet Companies Enterprises• Social Gaming• Ad Networks• Social Networks• Online BusinessServices• E-Commerce• Online Media• Content Management• Cloud Services• Communications• Retail• Financial Services• Health Care• Automotive/Airline• Agriculture• Consumer Electronics• Business Systems
    20. 20. Market Adoption – CustomersInternet Companies EnterprisesMore than 300 customers -- 5,000 production deployments worldwide
    21. 21. Application Characteristics - Datadriven• 3rd party or user defined structure (Twitter feeds)• Support for unlimited data growth (Viral apps)• Data with non-homogenous structure• Need to quickly and often change data structure• Variable length documents• Sparse data records• Hierarchical dataCouchbase is a good fit
    22. 22. Application Characteristics -Performance driven• Low latency critical (ex. 1millisecond)• High throughput (ex. 200000 ops / sec)• Large number of users• Unknown demand with sudden growth of users/data• Predominantly direct document access• Read / Mixed / Write heavy workloadsCouchbase is a good fit
    23. 23. Common Use CasesSocial Gaming• Couchbase storesplayer and gamedata• Examplescustomers include:Zynga• Tapjoy, Ubisoft, TencentMobile Apps• Couchbase stores userinfo and app content• Examples customersinclude: Kobo, PlaytikaAd Targeting• Couchbase storesuser information forfast access• Examples customersinclude: AOL,Mediamind,ConvertroSession store• Couchbase Server as a key-value store• Examples customers include:Concur, SabreUser Profile Store• Couchbase Server as akey-value store• Examples customersinclude: TunewikiHigh availability cache• Couchbase Server used as a cache tier replacement• Examples customers include: OrbitzContent & MetadataStore• Couchbase document storewith Elastic Search• Examples customersinclude: McGraw Hill3rd party data aggregation• Couchbase stores social media anddata feeds• Examples customers include:Sambacloud
    24. 24. From SQL to NoSQL
    25. 25. Mental Adjustments• In SQL we tend to want to avoid hitting thedatabase as much as possible• In Couchbase, gets and sets on documents are inmemory. This is fast.• The key to finding data is the key of thedocument.• Many newcomers see views as a replacement forkey design, because it seems more “SQL” –like.
    26. 26. Complex Joins vs. Multiple Gets
    27. 27. Document modelingWhen considering how to model data for a given application• Think of a logical container for the data• Think of how data groups together• Start by creating documents from application-levelobjects• Documents that grow continuously or under writecontention should be splitQ• Are these separate objects in the model layer?• Are these objects accessed together?• Do you need updates to these objects to be atomic?• Are multiple people editing these objects concurrently?
    28. 28. Document Design Options• One document that contains all related data- Data is de-normalized- Better performance and scale- Eliminate client-side joins- But if the document grows continuously or has writecontention, it should be split• Separate documents for different object types with cross references- Data duplication is reduced- Objects may not be co-located- Transactions supported only on a document boundary- Most document databases do not support joins
    29. 29. Document ID / Key selection• Similar to primary keys in relational databases• Documents are partitioned based on the document ID• ID based document lookup is extremely fast• Usually an ID can only appear once in a bucketOptions•UUIDs, date-based IDs, numeric IDs•Hand-crafted (human readable)•Matching prefixes (for multiple related objects)•Creative Keying (on next few slides )Q • Do you have a unique way of referencing objects?• Are related objects stored in separate documents?
    30. 30. Example: Entities for a Blog• User profileThe main pointer into the user data• Blog entries• Badge settings, like a twitter badge• Blog postsContains the blogs themselves• Blog comments• Comments from other usersBLOG
    31. 31. {“UUID”: “21f7f8de-8051-5b89-86“Time”: “2011-04-01T13:01:02.42“Server”: “A2223E”,“Calling Server”: “A2213W”,“Type”: “E100”,“Initiating User”: “dsallings@spy.net”,“Details”:{“IP”: “10.1.1.22”,“API”: “InsertDVDQueueItem”,“Trace”: “cleansed”,“Tags”:[“SERVER”,“US-West”,“API”]}}Blog Document – Option 1 – Singledocument{“_id”: “Couchbase_Hello_World”,“author”: “dborkar”,“type”: “post”“title”: “Hello World”,“format”: “markdown”,“body”: “Hello from [Couchbase](http://couchbase.com).”,“html”: “<p>Hello from <a href=“http: …“comments”:[[“format”: “markdown”, “body”:”Awesome post!”],[“format”: “markdown”, “body”:”Like it.” ]]}
    32. 32. Creative KeyingCounter-ID patternUses of this pattern• Creating an index based list• Globally referenced documents with unique key
    33. 33. Creative KeyingLookup patternUses of this pattern• Categorical references• Single document referred by multiple keys (Lookupuser by username, TwitterID, FacebookID)
    34. 34. Blog Document – Option 2 - Split intomultiple docs{“UUID”: “21f7f8de-8051-5b89-86“Time”: “2011-04-01T13:01:02.42“Server”: “A2223E”,“Calling Server”: “A2213W”,“Type”: “E100”,“Initiating User”: “dsallings@spy.net”,“Details”:{“IP”: “10.1.1.22”,“API”: “InsertDVDQueueItem”,“Trace”: “cleansed”,“Tags”:[“SERVER”,“US-West”,“API”]}}{“_id”: “Coucbase_Hello_World”,“author”: “dborkar”,“type”: “post”“title”: “Hello World”,“format”: “markdown”,“body”: “Hello from[Couchbase](http://couchbase.com).”,“html”: “<p>Hello from <a href=“http: …“comments”:[“comment1_Couchbase_Hello_world”]}{“UUID ”: “2 1 f7 f8 de-8 0 5 1 -5 b89 -8 6“Time”: “2 0 1 1 -0 4 -0 1 T1 3 :0 1 :0 2.4 2“Server”: “A2 2 2 3 E”,“Calling Server”: “A2 2 1 3 W”,“Type”: “E1 0 0 ”,“Initiating Us er”: “ds allings @s py.net”,“D etails ”:{“IP”: “1 0 .1 .1 .2 2 ”,“API”: “Ins ertD VD QueueItem”,“Trace”: “cleans ed”,“Tags ”:[“SERVER”,“US-Wes t”,“API”]}}{“_id”: “comment1_Couchbase_Hello_World”,“format”: “markdown”,“body”:”Awesome post!”}BLOG DOCCOMMENT
    35. 35. Threaded Comments• You can imagine how to take this to a threaded listBlogFirstcommentReply tocommentMoreCommentsListListAdvantages• Only fetch the data when you need it• For example, rendering part of a web page• Spread the data and load across the entire cluster
    36. 36. Java PetStore App Example
    37. 37. Pet Store ER Diagram
    38. 38. Documents Modeling in CouchbaseCustomer Document{"id":"customer_marc","type":"customer","login":"marc","password":"marc","firstname":"Marc","lastname":"Fleury","telephone":null,"email":"marc@jboss.org","homeAddress":{"street1":"65 Ritherdon Road","street2":null,"city":"Los Angeles","state":null,"zipcode":"56421","country":"USA"},"dateOfBirth":1363794557891,"age":null}Order Document{"id":"Marc","type":"order","orderDate":null,"customer":{"id":1,"login":"marc","password":"marc","firstname":"Marc",…},},"orderLines":[{"id":null,"quantity":1,"item":{"id":"item_Goldfish_Male Puppy","type":"item","name":"Male Puppy",}},Category Document{"id":"category_Birds","type":"category","name":"Birds","description":"Any of ...","products":[{"id":"product_Amazon Parrot","type":"product","name":"Amazon Parrot","description":"Greatcompanion for up to 75 years","items":[{"id":"item_Male Adult","type":"item","name":"Male Adult","description":"Lorem ...",
    39. 39. Pet store queriesin Couchbase
    40. 40. Define a primary index on the bucket• Lookup the document ID / key by key, range, prefix, suffixIndexdefinition
    41. 41. Define a secondary index on the bucket• Lookup an attribute by value, range, prefix, suffixIndexdefinition
    42. 42. List all the item categories• If a document if of type category, we want to get the doc IDs
    43. 43. Find items by name• Let’s find all the items
    44. 44. Application code changesDerby callsfind : TypedQuery<Category> typedQuery =em.createNamedQuery(Category.FIND_BY_NAME, Category.class);save : em.persist(category);update : em.merge(category);delete : em.remove(em.merge(category));Couchbase callsfind : client.get(categoryName);save :client.set(category.getName(), EXP_TIME, mapper.writeValueAsString(category));update :client.replace(category.getName(), EXP_TIME, mapper.writeValueAsString(category));delete : client.delete(category.getName());
    45. 45. Questions?
    46. 46. Thank youdon@couchbase.com@NoSQLDon

    ×