Given the current discussion about MongoDB, I think that the following post is worth revisiting.
http://news.ycombinator.com/item?id=2538037
I'm not a Riak user, but I agree with Basho's analysis on this case.
Don't use MongoDB
61–70 of 331 posts
Re: Don't use MongoDB
#62Earlier quoted context omitted.
Schema-less is imho a overrated feature. ORMs like DataMapper (Ruby) and NHibernate (.NET) can generate the schema on the fly for RMDBS, so no need for migrations pre-production. But when your application is in production you need migrations even with a "schema-less" db! See, rename a field and "all your data" is lost, unless you migrate the data from the old field to the new one..
"Schema-less" has the potential (if you use it properly) advantage of allowing gradual migration. As long as your code can handle all versions of objects in current use, you can deploy new code, then either migrate objects as they're updated/rewritten, and/or slowly migrate objects in the background. For certain types of schema changes in large enough data stores, this can be a killer feature. I remember one RDBMS se…
"Schemaless" most of the time means "code based schema". Dealing with multiple schema versions at the same time is always possible, relational or not, but it causes significant bloat and complexity. When I hear gradual migration I think code decay, but I can see why it could be useful sometimes.
In my view, schemaless models are only desirable if the schema is not known until runtime, e.g. user specified fields or message structures, external file formats that you don't control but might need to query, etc.
Re: Don't use MongoDB
#63Earlier quoted context omitted.
That's a fair problem, but I think It is true for other products as well and was true for things that we feel very solid today like MySQL. In other words there is a tention between stability and speed of development, a very "hard" tention indeed. It is up to the developers culture and sensibility to balance the two ingredients in the best way. One of the reasons I don't want to create a company around Redis, but want…
MySQL is a poor analogy because the history of MySQL is very similar to 10gen: a 'hacker' solution originally patched together by people who didn't take their responsibility as database engineers very seriously. It's only after years (decades) of work that MySQL has managed to catch up with database technology of the 80s in terms of reliability and stability (and it still has plenty of issues, as the most recent deba…
Where can I get info on the MySQL 5.5 issues? I'm considering upgrading from 5.1 to get the new InnoDB plugin...
Re: Don't use MongoDB
#64A story from a newly created account by a person nobody can verify is real and asking other people to submit his rant (to gain what? credibility to his story?) nomoremongo 4 hours ago | link I'd appreciate if someone would submit this story for me. http://pastebin.com/raw.php?i=FD3xe6Jt What's up with the trolling here. Who are you and what company do you work for that has had all those problems you mentioned ?
Attacking the messenger is shallow. How about you look at the points - whether valid or not - he or she raises instead and try to refute them? It matters little if that person is well known or someone entirely new. I don't see how the relative anonymity of a person is in any way related to his or her credibility. Besides, calling a position you don't agree with "trolling" with no further argumentation is 4chan level…
it's still a valid point as there are no references to back up any off the claims in the post. he should at least have included links to issues in their jira or some way of replicating the problem he is experiencing.
as it stands now it's not fact based and could as much be opinion as there is no way to weight the merit of the claims against anything substantial :(
Re: Don't use MongoDB
#65Earlier quoted context omitted.
Confirm or refute , doesn't matter but at least a comment giving some strong evidence would surely work !!
As the author made no specific claims or didn't show any failing test cases which can be discussed and reasoned about in a sensible way, it's going to be very hard to confirm or refute anything. Responding to anonymous flames in the internet is a waste of time.
After reading most of the comments now , I believe it is. I cant understand why would people just try to bring down something which is popular by all means by doing such rash publicity . HN should be a little careful while posting such links without verifying the source.
Re: Don't use MongoDB
#66Are we sure this isn't an Oracle employee?
Re: Don't use MongoDB
#67Are we sure this isn't an Oracle employee?
Does it matter, if they're right?
Edit: to the downvoters, this is a serious question.
Re: Don't use MongoDB
#68We extensively tested this inside Viralheat with a write heavy load of over 30,000 writes per second and basically it failed our test. It is not robust for the analytics world is the conclusion we came to. Though, I hope it gets better one day...it has potential.
Have you talked to Greenplum? They have a postgres derivative that can cope with Yahoo's clickstream data.
(I am not affiliated with either of them).
Re: Don't use MongoDB
#69Earlier quoted context omitted.
"Schema-less" has the potential (if you use it properly) advantage of allowing gradual migration. As long as your code can handle all versions of objects in current use, you can deploy new code, then either migrate objects as they're updated/rewritten, and/or slowly migrate objects in the background. For certain types of schema changes in large enough data stores, this can be a killer feature. I remember one RDBMS se…
Even more common is when you have a mature application with a lot of users and you need to add new fields to f.ex the user table and you can't because alter table across a sharded db setup will take days or weeks so you end up creating a table that's a hashtable key, value and then proceed to pay the cost of joins against it. Most of my excitement around NoSql comes from hard earned pain not from "oh new shiny thing,…
I'll take well-understood pain that I can patiently work around, one time, over the course of days or weeks, if the alternative is random bugs that bite you in the night for years at a time.
Joins are no fun, yes, but as you gritted your teeth and implemented those cute little table-based key-value stores, did you find yourself mentally calculating the time required to restore the whole system from backup while muttering tiny prayers? Probably not. Did your code wake up the ops team an average of once per month for several years? Did you lose data? Did you have to put up an apologetic blog post? Did anyone have to get on the phone and rescue customer accounts, one at a time, with profuse apologies and gifts? (Now that is a non-scalable process...)
But at least this argument about maintenance is a real argument. The one about wanting to save time during initial development by skipping the declaration of schemas reads like the punchline of a Dilbert cartoon that you'd find taped to the wall in the devops lunchroom.
Re: Don't use MongoDB
#70"They just disappeared sometimes. Cause unknown." If the cause is unknown, how can you blame it on a given piece of software?
I presume he's referring to the silent truncation stunt Mongo has been accused of by others before.
"Oh THAT", say Mongo boosters. "You should have read the IRC logs of June 22nd", they continue, "there was a 3 line patch posted in the channel. It totes fixes that problem".