"Being document-based datastores, Riak and CouchDB are the most direct competitors to MongoDB"
But Riak is a Key-Value store, not a document one. If that's the premise I wonder how illuminating the rest can be (I kept reading: it's not)
MongoDB 2.0 Should Have Been 1.0
21–30 of 51 posts
Re: MongoDB 2.0 Should Have Been 1.0
#22I don't intend this comment to be an insightful deconstruction of the NoSQL space and/or Mongo... but does anyone else notice that the level of energy around a project (positive or negative) usually indicates its progress along the hype-dissolution cycle[1]?
I try not to take the actual comments or articles as law, but rather use them as a temperature reading to figure out where in the slope we are currently for a given tech or trend.
Given that Mongo-talk has absolutely dominated HN over the weekend as well as reddit/r/programming, I am interpreting this as being in the bottom of the dissolution curve right now.
It is this point where the community push-back and temporary "hating on" forces the team to go into overdrive, addressing whatever pain points the community has griped on the loudest, in this case:
- Write locks
- Durability / Replication consistency (already addressed)
I imagine Mongo 3.0 will represent the final climb out of the dissolution curve where all open complaints have been addressed and we actually get back to solving problems with the technology.
I don't know that Cassandra or Redis or CouchDB have completed their hype-cycles yet, because they haven't had the hyper-aggressive response from the community during the dissolution step. They are all popular and well-liked, but it seems like their popularity is still climbing.
It is all interesting none the less. Mongo is a huge success, regardless of how many of these articles are written.
I've not seen a team as dedicated and involved like 10gen is for a long time; Eliot still answered 100s of messages on the group every week (Along with every new member of the team) -- which I find the biggest indicator of Mongo's future success. If the CTO is carving out that much time during the day to stay involved, while still bug fixing, replying to posts like these and testing bug reports... that's a lot of love right there.
Re: MongoDB 2.0 Should Have Been 1.0
#23This is funny. I thought that the whole paradigm of startups is to first release the minimally useful featureset and work on the other items later? I mean - isn't the goal is to first get revenue and then fix up what needs working later?
Re: MongoDB 2.0 Should Have Been 1.0
#24"Being document-based datastores, Riak and CouchDB are the most direct competitors to MongoDB" But Riak is a Key-Value store, not a document one. If that's the premise I wonder how illuminating the rest can be (I kept reading: it's not)
Riak has secondary indices, and map/reduce for ad-hoc queries. You can store raw binary data in it, and it's happy with that, but if you store JSON then it can query it. From what I can tell, the biggest difference between Riak and Bigcouch from a data model POV is that Bigcouch has materialized views, while Riak's are ad-hoc. I'm not an expert in either though...
Re: MongoDB 2.0 Should Have Been 1.0
#25I've been using MongoDB for well over a year now in around 6 apps (moved on from CouchDB) and I agree prior to 1.8 it should have been made more obvious that there were still some stability issues. I have seen first hand some of the issues raised, we've had data disappear, recurring random crashes, ect. But I think the difference is 'everyone' knew that there were issues with MongoDB, you just needed to check in jira…
Why did you move from couch? I'm considering couch for a project, and am not especially knowledgeable in the space. Couch has worked fine for a low-load, minimal-functioning prototype store (no replication needs, etc.). Its scary feature to me is dealing with compacting-- how and when to schedule it so a large db won't get bogged-down.
Couch now has an inbuilt compaction deamon, so you can configure it to run automatically
https://github.com/apache/couchdb/blob/trunk/etc/couchdb/def...
Re: MongoDB 2.0 Should Have Been 1.0
#26Earlier quoted context omitted.
Why did you move from couch? I'm considering couch for a project, and am not especially knowledgeable in the space. Couch has worked fine for a low-load, minimal-functioning prototype store (no replication needs, etc.). Its scary feature to me is dealing with compacting-- how and when to schedule it so a large db won't get bogged-down.
Couch now has an inbuilt compaction deamon, so you can configure it to run automatically https://github.com/apache/couchdb/blob/trunk/etc/couchdb/def...
What I haven't tested, though, is how long compaction takes- that is, how it scales with db size and whether more frequent compaction means closer to constant scaling.
Once the prototype was up I started working on other parts of the system (and the business for that matter) and only half-paid-attention to the mailing list.
The mailing list for couch is quite good, btw.
Re: MongoDB 2.0 Should Have Been 1.0
#27I remember being around when everyone was laying into PHP in much the same way as people are tearing into mongodb now and it makes me smile, because it means they're doing something right and they'll be around for quite a while if they're responsive to the feedback.
Re: MongoDB 2.0 Should Have Been 1.0
#28Earlier quoted context omitted.
A hoax or a double-hoax? Original post was this by nomoremongo: http://news.ycombinator.com/item?id=3201772 Post actually discussed was: http://news.ycombinator.com/item?id=3202081 Very clever. The way I understand, apparently nomoremongo wrote it but it was reposted quickly by nmongo ( http://news.ycombinator.com/threads?id=nmongo ) in hopes that they could then become the top post, so later on they can yell in all…
There was always something suspicious about an anonymous post lacking any verifiable facts. Then, 10gen's CTO states that none of it resonates with any support issues they've had. Then, add this. I know exactly what it will take for me to believe the pastbin story. I'm curious, what will it take for you to not believe it?
I agree this is a shady post. Even "how" it was posted is shady. So I am not standing 100% behind it. It is just more of a gut instinct.
At the same time, it got on the front page because the story resonated and made sense to others.
There were quite a few people who commented how "oh yeah I've had problems with lost data". And I think that is what pushed the post's popularity more than the original pastebin. So the discussion got a life of its own after a while. Followed by response posts and response posts to those and so on.
Re: MongoDB 2.0 Should Have Been 1.0
#29"Being document-based datastores, Riak and CouchDB are the most direct competitors to MongoDB" But Riak is a Key-Value store, not a document one. If that's the premise I wonder how illuminating the rest can be (I kept reading: it's not)
Riak has secondary indices, and map/reduce for ad-hoc queries. You can store raw binary data in it, and it's happy with that, but if you store JSON then it can query it. From what I can tell, the biggest difference between Riak and Bigcouch from a data model POV is that Bigcouch has materialized views, while Riak's are ad-hoc. I'm not an expert in either though...
can they be used to do similar things? yes. are there overlapping use cases? indeed. Are they going to overlap more and more as time goes by and they try to expand out of their niches? absolutely.
But they fall squarely in different categories: Riak KV, MongoDB document (and HBase Column, Neo4J Graph for example)
Re: MongoDB 2.0 Should Have Been 1.0
#30Earlier quoted context omitted.
Couch now has an inbuilt compaction deamon, so you can configure it to run automatically https://github.com/apache/couchdb/blob/trunk/etc/couchdb/def...
What I haven't tested, though, is how long compaction takes- that is, how it scales with db size and whether more frequent compaction means closer to constant scaling. Once the prototype was up I started working on other parts of the system (and the business for that matter) and only half-paid-attention to the mailing list. The mailing list for couch is quite good, btw.
It is better to do it during downtime. You can basically provide scheduling rules such as 'compact when fragmentation % > X AND time-of-day window is Y'.