Episode IV: A New Hope…and NoSQL
In this episode, we talk about NoSQL and the part it can play in a distributed system architecture. Specifically, we talk about a handful of NoSQL storage engines including RavenDB, MongoDB, CouchDB, Riak, and Cassandra.
Please send your comments and questions to /dev/null.
MP3 Download: Distributed Podcast, Episode 4
Episode references
- CQRS Google Group Question
- Enterprise Model
- Enterprise Data Model
- DDD Bounded Contexts
- NoSQL
- RavenDB
- RavenDB Indexes
- Jonathan Oliver’s EventStore
- MongoDB
- MongoDB Unique Indexes
- MongoDB Sharding
- CouchDB
- Riak
- Riak Map/Reduce
- Cassandra
In the podcast I (Jonathan Oliver) mentioned that Riak is a plain key/value store and that it isn’t necessarily aware of the contents of the “bucket”. That isn’t necessarily true. I neglected to mention that can peer into the buckets and has a very capable map/reduce feature and comprehensive search mechanism. Very cool.
For some reason this episode does not show up in “Google Listen” on Android. Episodes 1 – 3 are fine.
So, I know this is really late, but I just heard the mention of MongoDB as it relates to .NET.
The NoRM driver is NOT the only one with a linq provider. Another non-official driver (https://github.com/mongodb-csharp/mongodb-csharp) has had a linq provider for a long time. In fact, this linq provider has been pulled out and applied to the native 10gen driver here: https://github.com/craiggwilson/fluent-mongo. It is available via nuget for easy installation.
Anyways, hope that helps.
Hi – great episode.
During the episode, one of the Jonathans stated that dynamo implementations are better than MongoDB because “in Mongo there is a master which is a single-point of failure” and that “in dynamo you can specify the number of replicas to propagate changes to”
MongoDB has Replica Sets (beginning at 1.6 which is a while ago) where the master is not a single point of failure – if it fails then the set chooses a new master.
see http://www.mongodb.org/display/DOCS/Replica+Sets
There is also an optional parameter per any write action to control the amount of replicas to propagate to before it is considered a DONE action
see http://www.mongodb.org/display/DOCS/Verifying+Propagation+of+Writes+with+getLastError
While Mongo may elect a new master during the failure of one of the nodes, Dynamo is about a masterless/P2P solution for storage. It’s a totally different model. Unfortunately, it’s also a model that’s a lot more difficult to work with in many scenarios.
I’m not faulting Mongo–I think it’s a great storage engine–I’m just pointing about a fundamental difference in the theory and design of each system.
I guess the comment about /dev/null was a placeholder
No, it’s a real. But it’s meant as a joke.