Posted by Kirk Kirkconnell, Senior Solutions Engineer, Couchbase

Kirk Kirkconnell was a Senior Solutions Engineer at Couchbase working with customers in multiple capacities to assist them in architecting, deploying, and managing Couchbase. His expertise is in operations, hosting, and support of large-scale application and database infrastructures.

12 Comments

  1. Very well written Kirk….eagerly waiting for part II of this series.

  2. Hi Kirk, awesome article. I\’m just getting into NoSQL and want to start using Couchbase, and this is great learning material.

    I like how you use the string keys essentially as joins between documents. I am debating what to do in my more complex scenario: Let\’s say I am building an app that allows users to store additional data related to Tweets from Twitter, for example \”save this tweet as a favorite.\” A single user could easily have thousands of these favorites accumulate over time. Essentially this is a many-to-many relationship between Users and Tweets. Following your example, the key for these tiny documents could be: <userid>_<tweetid>

    In my scenario, all these relationships are strictly private to the user who created them. And they all need to be replicated on a user\’s device via Couchbase Lite. For these reasons, would it be better to store them all in a single document for that user, or perhaps in sharded documents based on time, twitter stream, etc?

    Thanks!

    1. That is a tough one as there are pros and cons both ways. If you store them all in one document, at what point would a user get up past that 20MB doc limit or with you having to drag around a large JSON document just to add one tweet to it. On the flip side if every single tweet is in its own, then you could get into a situation where you have billions of objects and storing lots of meta-data as Couchbase stores ~54 bytes per data object. You could eject that too, but you will take a performance hit for seeing is a document exists.

      Anyhow, what I would recommend looking at is three possibilities.

      1) See if storing each tweet as an object, but then the key would be something I describe in my other object modeling blog post would work. http://bit.ly/1Hx3a74

      2) Another option that I have seen used to great effect is to have each tweet in a separate document, but then have a manual index document per user. So to get that user\’s favorites, you grab that document that has their \”index\” and in that document is the list of the object IDs of the tweets that are their favorites. if you need to get them all, now that you have the list of objects to get, you use the bulk operations of the Couchbase SDK and get all or the portion you need. Does that make sense?

      3) A mixture of 1 and 2 depending on your use case and required performance profile.

  3. Great article. Thanks for the info. Does anyone know where I can find a blank \”how to email application \” to fill out?

    1. Hey jeannie, I
      was able \”to email application\” from this link
      http://goo.gl/yoGwr2. It also allowed me to Download, edit, print, save, sign, email or even fax.

  4. Nice article, thanks! Waiting for the second part.

  5. Good article.
    The Data Modeling of User Profile Store only consider using Couchbase Server, If there is a advise on Data Modeling when I use Couchbase Server and Couchbase Mobile will be useful.
    such as when using Couchbase Mobile, we should consider constraint of SG routing/ACL,constraint of query from CouchbaseLite by map/reduce etc.

    1. Couchbase Mobile is not my area of expertise and so I doubt I will do the topic justice. I will pass this on to those that might be able to help though and write something up for you. The other option for you, if you have not already, is to use the Couchbase forums to ask about this.

    2. You can also start here, and we’ll be releasing more Couchbase Mobile training in the next few weeks. http://developer.couchbase.com

  6. Great article Kirk. Very detailed information. Is there any date in mind for part 2 on this article?

    Thanks!

  7. […] examples of how you might use a standardized object ID pattern in your application, please see this and this blog post I wrote. Even if the specific use cases in the blogs are not applicable to […]

Leave a reply