CouchConf Seattle - Radlibs with Madlibs! - Jasdeep Jaitla

Now you can spend your weekends here... modeling data in CouchbaseSocial Mad Libs with Radlibs! and Ruby on Rails

Spend less time on CRUD• In your mind data is organic, users have this, users created that, users earned this, and bought that• When you hit the code treadmill, SQL forces you to break apart your model into supersets (tables), only to analyze it back into the original subsets (where and joins) on every call• The hardest part of transitioning to NOSQL is getting into the mindset and learning new patterns, and letting go of old habits

Lessons from the Road• Key design and document design is the cornerstone of easy TDD/BDD development and simple, easy to maintain, class methods• Most people expect Couchbase modeling to be as painful as SQL normalization and hard-to-read stored procedures• I spent disproportionally more time on UI and UX than on my model, and "Look daddy I can get and set!" thats a good thing, I spent less time on CRUD, and more time on QUALITY

Objects Can Be Represented Behavior Driven Document Design By Multiple Documents

User Data Sample, using internal UserID u::countCREATE TABLE Users 1 u::1001id, int, identity(1000) PRIMARY KEY { "name": "Jasdeep Jaitla",name, nvarchar(100) "facebook_id": 16172910, "email": "jj@scalabl3.com",facebook_id, bigint "created_at": "5/1/2012 2:30am" } fb::16172910email, nvarchar(255) 1001 em::jj@scalabl3.comcreated_at, datetime 1001

SQL Scales Vertically Couchbase Scales HorizontallyINSERT INTO Users user_data = { "name": "Jasdeep Jaitla",(name, facebook_id, email, created_at) "facebook_id": 16172910,VALUES ("Jasdeep Jaitla", 16172910, "email": "jj@scalabl3.com","jj@scalabl3.com", "5/1/2012 2:30am") "created_at": "5/1/2012 2:30am" } uid = couch.incr("u::count") + 1000Get User By FB couch.add ("u::" + uid, user_data)SELECT * FROM Users couch.set ("em::" + user_email, uid)WHERE facebook_id = 16172910 couch.set ("fb::" + user_fb, uid)Get User by Email Get User By FBSELECT * FROM Users uid = couch.get("fb::16172910")WHERE email = “jj@scalabl3.com” user_data = couch.get ("u::" + uid) Get User By Email As This Grows it gets Slower for Each Request uid = couch.get("em::jj@scalabl3.com") user_data = couch.get ("u::" + uid)

User Data Multiple Social Networks & Emails u::count fb::16172910 1001 1001 u::1001 nﬂx::2939202 { "name": "Jasdeep Jaitla", 1001 "facebook_id": 16172910, twtr::2920283830 "email": "jj@scalabl3.com", 1001 “password”: ab02d#Jf02K em::jj@jasdeep.com "created_at": "5/1/2012 2:30am", 1001“facebook_access_token”: xox0v2dje20, em::jj@scalabl3.com “twitter_access_token”: 20jfﬁeieaaixixj } 1001 uname::scalabl3 1001

Designing Documents Data Isolation to reduce Race Conditions and Mutation Clashes based on Behaviors

Aligning Documents to Behaviorsuser::1 user::1 { name: “Jasdeep” }{ user::1::pointsname: “Jasdeep”, { points: 1000 }points: 1000, user::1::shopping_carts { carts: [ 1000, 1001, 1002 ],shopping_carts: [ 1000, 1001, 1002 ], products_bought: [ 2000, 2001, 2002] }products_bought: [ 2000, 2001, user::1::games_won2002], { game_ids: [ 3000, 3001, 3002, 3004] }games_won: [ 3000, 3001, 3002, user::1::notification_count3004], 57 user::1::notifications::57notifications: [ “Lorem”, “Ipsum”, { message: “Hi Bob” }“docet”, ...] user::1::notifications::56} { message: “Happy Hour?” }

Behavior Driven Design• Reduce the number of User Actions that affect a single document• Instead, separate that user document in a predictable key structure and make it accessible via getters and setters in your class• Like TDD/BDD encourages smaller, simpler methods, that are easier to write and maintain

Taking The Blue PillFrom SQL to Couchbase

The Most Common Mental Adjustments #1• In SQL we tend to want to avoid hitting the database as much as possible • We know, intuitively, that it’s costly when tying up connection pools, and overloading the db servers • Even with caching and indexing tricks, and massive improvements over the years, SQL still gets bogged down by complex joins and huge indexes• In Couchbase, get’s and set’s are so fast they are trivial, and not bottlenecks, this is hard for many people to accept (reptilian SQL mind)

Complex Joins vs Multiple Getsselect * from (((client left join brochure on shopping_cart_id =client.cid = brochure.cid) couch.get(“u::1001::transaction::count”)left join translation on brochure.bid =translation.bid ) cart_items =left join version on translation.tid =version.tid) couch.get(“u::sc::” + shopping_cart_id”)left join language on language.lid =translation.lid foreach item_id in cart_items.itemsorder by client.cid, brochure.bid, cart_details.push(translation.tid, version.vid couch.get(“product::” + item_id) ) end

The Most Common Mental Adjustments #2• The key to ﬁnding data is the Key (I guess that made it easier for the naming committee)• Key design can give you many different ways to access data, being able to predict key values, and use them creatively• Many newcomers see Views as a replacement for key design, because it seems more “SQL”-like

Designing Virtual Goods Documents vg::1 vg::markers::1 { { name: “sharpie”, name: “sharpie”, colors: [“black”, “red”, “blue”] category: “markers”, } vg::markers::2 colors: [“black”, “red”, “blue”] { } name: “markalot”, vg::2 colors: [“blue”, “green”, “black”] { } vg::1 name: “markalot”, { id: “vg::markers::1” } category: “markers”, vg::2 colors: [“blue”, “green”, “black”] { id: “vg::pens::1”} vg::3 } { id: “vg::markers::2” }

Design Documents / Views vs Key Design• Just by their nature, and how they work, Views will nearly always be more expensive than get’s• If you can design your documents to not need views, you’ll get higher performance, use views for situations where that isn’t possible• One person even asked if he could mix Couchbase 2.0 Developer Preview nodes in a cluster of Couchbase 1.8’s and run views on the full data set... but I don’t recommend that

Views Rock!( but they should be used when necessary )

Radlibs! with Purpose• Make it easier and fun to learn common highly performant design patterns with Couchbase 1.8• Clone the code and reuse it, hack it, even improve it• Make silly stories with your friends

CloudScalr.com We are launching our service in the next 4-6 weeks★ We are going to offer managed 3-node replicated Couchbase clusters in the cloud, at 300MB RAM (100MB/server), 600MB RAM and larger sizes★ Automated upgrading/migration to larger sizes★ Entry level pricing around $30-40/month for CB Cluster, and competitive pricing for AppServer cloud hosting

Jasdeep Jaitla -- Contact InfoTwitter@scalabl3@jasdeepjaitlaEmailjasdeep@scalabl3.comjasdeep@cloudscalr.comIRC#libcouchbase#couchbaseNick: scalabl3

CouchConf Seattle - Radlibs with Madlibs! - Jasdeep Jaitla

by Couchbase on May 31, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

CouchConf Seattle - Radlibs with Madlibs! - Jasdeep Jaitla Presentation Transcript