11–20 of 54 posts
remind me on the arguments of which programming language is the best. There is no best technology. Different technologies are designed for different engineering problems. You can't really blame the technology when you are choosing the wrong tools for your problem.
We should never forget that, too. Even in carpentry, there are badly made hammers.
Mongo is fine until it's not. It's been fine for us for many months, but once you hit its limitations, it's pretty horrible. We're in this situation right now and we're seriously considering moving back to MySQL or Postgres. Basically, "it doesn't scale" unless you throw tons of machines/shards at it. Once they fix a few of their main issues such as the global write lock and fix many of the bugs, it could become an o…
In my opinion, there is but one feature that a database really must have: whatever data I write into it, if I don't delete it, I want to read it back - unaltered (preferably without needing at least three machines, but I'm willing to compromise) Software that cannot provide this single feature just isn't something I would call database. If it's unsafe default configurations or just bugs. I don't care. Between these t…
I'm not sure how hosting a video for Gawker builds a lot of credibility for having field tested a database; perhaps there are more details he can provide about how that is a particularly interesting trial for a database. Among other things, that seems like "lots and lots of reads, very few writes" and a "very consistent access pattern regardless" kind of situation.
The thing that struck me about the original post was how it seemed some of the complaints were just normal things that people learn when dealing with clusters under load. "Adding a shard under heavy load is a nightmare." Well, I mean, duh. If you add a shard and the cluster has to rebalance, you're adding load. It's like how you're more likely to get a disk failure during a RAID rebuild. The correct time to add a shard is during the off hours.
The author would have us believe that it's unfair to pick on any piece of software because it "all sucks." They'd also have us believe that complaining about your data disappearing in MongoDB is an unfair criticism, and then takes the logical leap that judging the destruction of data and buggy software somehow has something to do with your own ability to create backups. Generally speaking the people who have been bur…
Yeah, right.
Not only are his arguments void, but the anecdote used to back up the "mongo is fine, f off!" message is laughable.
The author would have us believe that it's unfair to pick on any piece of software because it "all sucks." They'd also have us believe that complaining about your data disappearing in MongoDB is an unfair criticism, and then takes the logical leap that judging the destruction of data and buggy software somehow has something to do with your own ability to create backups. Generally speaking the people who have been bur…
As he highlights, it is software it will likely have bugs
This is not a valid excuse. This is like running a red light, smashing into someone, and then telling them "hey, you should have looked before entering the intersection... you should know that people sometimes run red lights".
Yes, you should have backups. No, that doesn't make data-loss bugs any more excusable.