No it's a tool, do I dislike a hammer because it can't turn screws?
Does everyone hate MongoDB?
141–150 of 159 posts
Re: Does everyone hate MongoDB?
#142Earlier quoted context omitted.
I like the concept of MongoDB. My main problem (which perhaps is not totally clear from my post, linked in the article) is that there are certain historical conventions about what a database should be. In particular, a database will not have the following default behavior: - return from a write call silently, when the data wasn't written and will not be. If you are going to break conventions on a multi-decade traditi…
> In particular, a database will not have the following default behavior: > - return from a write call silently, when the data wasn't written and will not be There isn't some defined set of rules for how a database should operate. This attitude implies that an asynchronous database should never ever exist. If that's the case, how could I ever use a database for HTTP logging? I can't have every single HTTP request blo…
MySQL has INSERT DELAYED which is async. Of course, it's not the default - you have to specifically choose to call INSERT DELAYED when you know the data you're inserting isn't life-and-death.
Re: Does everyone hate MongoDB?
#143Earlier quoted context omitted.
...with more established DBs like MySQL and PostgreSQL, you never really saw the same kind of marketing efforts towards developers, startups, etc. It is kind of a newer concept. That's funny because MySQL used to do exactly the same kind of marketing fifteen years ago: comparing itself to Oracle, "it's a thousand times faster" when it obviously didn't do one thousandth of what a RDBMS does. History repeats... and has…
I don't think that is correct. They never compared themselves to Oracle. I spent some time with Monty parts of the team and also tried working with their business side and they never went after the Oracle workloads. Their huge popularity come with the LAMP stack and their ease of use. They went after this along with data warehousing.
Fortunately, it was public. Don't take my word for it.
Re: Does everyone hate MongoDB?
#144Earlier quoted context omitted.
> In particular, a database will not have the following default behavior: > - return from a write call silently, when the data wasn't written and will not be There isn't some defined set of rules for how a database should operate. This attitude implies that an asynchronous database should never ever exist. If that's the case, how could I ever use a database for HTTP logging? I can't have every single HTTP request blo…
MySQL has INSERT DELAYED which is async. Of course, it's not the default - you have to specifically choose to call INSERT DELAYED when you know the data you're inserting isn't life-and-death.
INSERT DELAYED does not work for InnoDB tables and is now deprecated since MySQL 5.6. I am not a MySQL user though so I have no idea if there are any alternatives to INSERT DELAYED.
The reason for the deprecation seems to be the many gotchas with it combined with the doubtful performance gains. It seems to have been an ugly hack.
Re: Does everyone hate MongoDB?
#145Earlier quoted context omitted.
I like the concept of MongoDB. My main problem (which perhaps is not totally clear from my post, linked in the article) is that there are certain historical conventions about what a database should be. In particular, a database will not have the following default behavior: - return from a write call silently, when the data wasn't written and will not be. If you are going to break conventions on a multi-decade traditi…
Both are clearly stated in the documentation. Anyone that puts any DB into production without reading all the documentation beforehand is foolish and has no room to complain. If there are only "experimenting" then at what point will they read the documentation?
I would guess almost every DBA and sysamdin in the world is foolish. I doubt almost nobody has read the entire documentation for PostgreSQL, Oracle or MySQL.
Still they manage to get those databases up an running without any data loss with just some generic knowledge about OS:es and hardware and reading choice parts of the documentation. Strange, huh?
Re: Does everyone hate MongoDB?
#146I think a lot of the "hating" is a side effect of MongoDB being consistently oversold in terms of its capabilities and architecture. Many people who are not experts on databases discover this the hard way later. If the claims about it were qualified a little better and the limitations acknowledged more openly by its proponents it would help to mitigate this outcome. I am indifferent to MongoDB but I do caution people…
"Oversold" is the key word here. And that's a marketing concept. To dig deeper, the problem has and always will be that MongoDB toes the line between a caching product and a database product, yet 10gen markets it simply as a database product. MongoDB is flexible and fast, but practically speaking it's a hybrid product that defies simple categorization. That means it must be well understood to leverage it. Ultimately…
Compare with the marketing of Redis. Redis makes it obvious that persistence is a trade off you must make as a user.
Re: Does everyone hate MongoDB?
#147Outstanding article. Well overdue for the Mongo community. There are always the haters whom find themselves ignoring documents then complaining about how things are setup.
Thank you for going back through mongo articles to iterate the key failures to understanding points.
Re: Does everyone hate MongoDB?
#148Earlier quoted context omitted.
This is an excellent anecdote and one that others should pay attention to, regardless of the technology. Developers often have confirmation bias for their choices—it's a common human fault. We do it for purchases, life decisions, and software decisions alike. But it's important to watch out for it and be aware when you might be in the thick of your own bias. A friend of mine (let's call him "me") used Adobe Flex for…
You know what I do before making big decisions: Read. The. Documentation. Every single issue mentioned about MongoDB is in the documentation and pretty fundamental to how it works.
Of course. But this isn't a question about what is or isn't in the documentation. Of course everything you need to know should be in the documentation, and you should RTFM.
No, it's about obfuscation vs clarity, and to an extent, about how good the overall design really is. Look at it as a measure of quality. If I have to read every word of the documentation to find the tiny part on page 18 where it tells about that one flag I need to start it up with in order to ensure that one feature works the way I want; versus a sensible default and clear documentation and even clear design where perhaps that flag isn't even required (think automated memory management that Just Works, versus a dozen command-line or config-file switches about memory buffer size and such).
When you run into issues, it's not a useful excuse to say "Well, you should have read the documentation, it was all there." That's like a shady credit card contract where the rate goes up 30% if you miss a payment. It's easy, even if you read it, to say "well I won't ever miss a payment," and even easier to miss that clause completely. Can you blame people for not reading the fine print? Sure, it was their responsibility. Will people still do it? Of course. Will people who read the contract fully still run into issues if they make one mistake? Probably.
And the point: is it a crappy contract? Yes. It has a crappy feature to begin with, and it's made worse by its obfuscation. This is almost unarguable: a credit card with a lower rate penalty is better. A piece of software with good defaults and sensible design is better.
The requirement for asinine and lengthy documentation isn't just a big warning sign that you should read it—it's a sign of poor design, or at least the word everyone's been using to describe Mongo: immature.
Good design includes the whole experience of using the software, and takes into account good integrated systems and human interaction. Bad design requires you to read the documentation extremely carefully. These are not hard and fast rules, but they're certainly warning signs. Really clear and obvious warning signs. And the overall point is that the well-documented issues that come up with Mongo are not just stupid people who don't read documentation—they are statistically relevant pieces of evidence pointing to some poor design decisions.
You should really think of this whenever you see a trend. You have a choice. You can blame individuals for "not reading the documentation"—or you can look at the systematic trend and statistically evaluate the problem. The former allows you to quickly dismiss issues on an emotional basis and make yourself feel better, while doing absolutely nothing to solve the issue. The latter lets you collect useful information and make real changes that have a real impact on the issue at hand. Your call.
Re: Does everyone hate MongoDB?
#149Earlier quoted context omitted.
I haven't got a 32 bit version of Mongo, but people pointed out in the other thread that 32-bit version of mongod displays a little warning every time you start it saying it can handle only 2GB of data. Can you confirm this ( because I don't have the 32-bit version installed )? It still stinks, especially because it "silently failed after hitting the threshold", but I personally would feel better about 10gen if this…
Yes that is true for me, at least using the 10g binaries for Linux (not the Ubuntu package). You get this warning everytime you start the engine. You'd probably have to look at your logs to see it. It is also referenced in the installation documentation. Look guys, MongoDB uses a memory-mapped file. How can it be larger than 2GB on a 32-bit system? There should not need to be "warnings everywhere".
How could it be larger?
You could use mmap64.
Re: Does everyone hate MongoDB?
#150It is easy to criticize the things closest to you.