This is not a ASW title, but the name of a skillsmatter evening talk, unlike most skills matter presentations this was only 10 mins long (presented by Ryan Duffield @rduffield ) , which allowed for a good bit of discussion before we piled down to the pub, anyway you can see the presentation HERE.
I took a load of notes during the talk and the discussion afterwards, but have decided not to put them down here in the end, as to me the real differences between the 2 databases were down to their origins and usage cases rather than direct comparisons, yes they are both NoSQL dbs but they are very very different beasts, MongoDb is a noSQL db designed to appeal to relational DB developers, its interfaces are the same, a lot of its behaviours are the same and one of its main roles is to overcome the scaling issues that traditional relational dB’s suffer from in this Internet age, a challenge that it is proving its self more than a match for, where as Couchdb (and its enterprise evolution couchbase) was designed to fulfil approximately the same role as one of its inspirations ‘Lotus Notes’ (though without its limitations), in that is is designed for robustness, security and replication rather than speed, able to survive on large and small devices alike and able to carry its applications with it.
Soooo basically, if you want good replication and serious horizontal scaling where fault tolerance is more important than performance then go for couchdb, but if your looking for a high performance NoSQL replacement for a relational db like MySQL where scaling to massive size is your primary requirement, then go for Mongo
(waits to be flamed)
Old Comments
Sean cull(11/10/2011 22:37:24 GDT)
I must admit that using xpages is highlighting the limitations of the underlying NSF much more.
Adding 3 drop down filters to a repeat /view means a view with 3 key columns and many times more rows of data if a ft search is not possible.
Yes I know this wasn’t possible with notes but in xpages you want to match the feature sets on other modern web application.
Similarly my rule of thumb of <100k records in an NSF is severely challenged by the apps that I want to write now.
Xpages is cool but now the NSF ( which I need for replication ) is felling old.
Richard Moy(11/10/2011 16:04:12 GDT)
I have tried Coucbdb. It is a good analogy to NSF with one exception which I think is great, there is a true separation of form and data.
Mark Myers(11/10/2011 16:10:18 GDT)
Cool
Mark Myers(11/10/2011 23:46:47 GDT)
@sean – i could not agree more, the 32k limit and performance problems are really starting to cause issues, making me start to doubt notes as a platform or find it hard to justify, i reckon it should be IBMs next port of call, we have xpages, we have xwork server, time to update the data store
Simon Letourneau(15/12/2011 16:31:55 GMT)
In Domino there is the 64k limit of any @formula result.
-workaround easy with generating an evenly distributed index and using it as a key in lookups. In kiwi hoop we do a modulo X of the lenght of a field. We then make X lookups and merge the results. Once you code the layer in lotusscript it goes fine.
There is the 32k limit in a field. You can set the isSummary = false on the item. You can also use a wrapper class that will split the setValue and then merge the getValue.
We have solved these limits so there is really no advantage to drop domino. We still benefit from so much good features that will never see the light in couch or mongo.
Mark Myers(22/12/2011 14:44:57 GMT)
@simon your dead right, its one of the thinks i have mentioned to the mongo guys, that IBM have been fighting these problems for ages so learn from their lessons
