5

I'm evaluating some database possibilities for a large-scale (many billions of entries, many terabytes of data) storage solution where we will do random primary key-lookups almost exclusively.

Given it's capabilities, Membase (Couchbase 1.8) looks almost like a perfect fit, and some previous tests makes us believe it is highly performant for our usecase. Our main concern with using this though, is that since Couchbase 2.0 looks like a whole new direction from 1.8, the characteristics of the product might change. We like Couchbase 1.8 because it does exactly what we need very well.

We don't need views or map/reduce capabilities. While these are nice features to have, they are not something we need and not something we want if they are at all detrimental to performance. We've ruled out CouchDB mostly due to the complexity in scaling (adding/removing nodes) which is of course much better in Couchbase, but also because we had some concerns about it's disk usage.

Is anyone aware of any performance measurements made for 1.8 vs 2.0, disregarding all view and M/R capabilities?

Will the 1.8 fork continue to be maintained? Or is 1.8 dead, and we should just move on?

Joel Westberg
  • 2,656
  • 1
  • 21
  • 27

1 Answers1

8

There will be no major differences in performance between Couchbase 1.8 and 2.0. I am a Couchbase employee and one of the most important things to us was that existing customers are able to upgrade from Couchbase 1.8 to Couchbase 2.0 whether or not views were important to them and have their applications continue to perform at the same levels.

I recommend starting with Couchbase 1.8 since our 2.0 product will not be released until the end of October 2012, but when the time comes to upgrade to 2.0 you shouldn't have any issues.

NOTE: As December 2012, Couchbase 2.0 is already available

OnaBai
  • 40,767
  • 6
  • 96
  • 125
mikewied
  • 5,273
  • 1
  • 20
  • 32
  • 1
    To add to this comment, I would say that the largest difference between 1.8 and 2.0 from Joel's perspective is that the application is moving from a sqlite back end to couchdb back end. This is an extremely good thing as it resolves issues with db fragmentation you can run into on 1.8 when you have a large cache with longer expiration timeframes after it has been running on a high bandwidth site for an extended period of time. – Drahkar Aug 26 '12 at 12:25
  • I'm very glad to hear that. As someone relatively new to CouchBase, it's very good to find this out! We will not run into the on-disk bloating we've seen reported by some CouchDB-users, compared to the old SQLite backend? – Joel Westberg Aug 27 '12 at 09:33
  • I would make a comparison in that fashion. CouchDB and Sqlite as standalone applications are locked within the limitations of the application that use them. Couchbase does the managing and cleaning of these back ends to keep those issues from developing for the most part as the data is generally perishable and not stored long term. Anything that expires is first persisted to disk and eventually removed from the cache. – Drahkar Sep 01 '12 at 17:33