7 ms·

No, the bad reputation is not overrated. This is the essence of why appeal to authority is a fallacy. Facebook is (or was) largely written in PHP; that doesn'

No, the bad reputation is not overrated. This is the essence of why appeal to authority is a fallacy. Facebook is (or was) largely written in PHP; that doesn't mean PHP's bad reputation is overrated. Many banks run on COBOL; that doesn't mean Cobol's bad reputation is overrated. MongoDB's bad reputation is well-deserved and based on a long history of misleading (or outright false) marketing claims coupled with poor technical properties (from unavoidable data loss to horrible compaction performance to global write locks). At this point, even if all the known issues were fixed (and they aren't) it would still take a long time for their reputation to recover. Given that some of MongoDB's direct competitors do not suffer from these problems and can largely function as drop-in replacements, recommending people use something else is really the only responsible course of action.

spimmy 12y ago
God yeah, the write locks have been a pain in my ass for so long. Fortunately the storage engine API delegates locking to the engine, so we get document level locking in RocksDB or WT.
lacker 12y ago
some of MongoDB's direct competitors do not suffer from these problems and can largely function as drop-in replacements Which competitors are you referring to? Personally I find the power and flexibility of the MongoDB query language to be a big positive that for many cases outweighs performance and reliability issues. It seems like no other competitors are quite there.
- andrewflnr 12y ago
  GP may be thinking of RethinkDB.
- functional_test 12y ago
  TokuMX supports most of Mongo's features besides the aggregation framework last I looked. Better locking, transaction support, better indices too -- you should check it out.
- benjarrell 12y ago
  I don't know that I would call them competitors, but DB2 and Informix both have JSON support and both implement the MonogoDB protocol.
  - ahachete 12y ago
    Also ToroDB (https://github.com/torodb/torodb https://github.com/torodb/torodb) implements the MongoDB protocol. But it uses PostgreSQL as a backend and it's open source ;P (ToroDB developer here)
- Jweb_Guru 12y ago
  In addition to the others already mentioned, http://hyperdex.org/ http://hyperdex.org/ implements the MongoDB API (though I cannot vouch for all of its claims, it seems worth including for completeness).
functional_test 12y ago
This is the last one of these posts I'll ever respond to, I promise. And I'll give you the same response I've given every other time before: You should not base your decision of database (or anything else for that matter) on marketing copy. For something as important as your primary data store, you should at minimum read the full documentation and run some tests with dummy data to see if it will even plausibly work for your use case. I used MongoDB successfully for years with a large data set (>1TB) and 100% production uptime for more than 3 years. I never lost data. Your claim that you will unavoidably lose data is baseless and without merit. In fact, every issue you listed has been fixed, again, counter to your claim. Personally, these days I prefer TokuMX if I'm looking for something compatible with MongoDB, but these baseless attacks on MongoDB have to stop. EDIT: Every time I make a post like this, I get some downvotes without responses. Please tell me why I'm wrong. If it's just that I'm abrasive... Well, you would be too if you were addressing the same thing for the Nth time.
- inglor 12y ago
  Not the downvoter - but I can totally understand the downvote. The fact your anecdotal evidence is that you did not lose any data doesn't mean the internet is not full of people who have lost data with Mongo. I have no idea what your workload is, but my experience with data loss and uptime has not been as great as yours. I'm not for bashing things either - I think there are cases Mongo might be appropriate, I just don't like countering claims with "it worked for me on this one data set". If it drops writes for one out of 100 people that's still a big reason to avoid it if that's a big concern for you. As for "these issues have been fixed" you're welcome to open the issue tracker - no one at Mongo claims all of these issues have been fixed (then again, PostgreSQL has open issues too) so your claim that "these issues have been fixed" is kind of odd...
  - functional_test 12y ago
    I only brought that up to counter his claim that data loss is inevitable. Of course my anecdote doesn't mean it's not common =) But anecdotes are all anyone else has, and every time I've read one about someone losing data, they either hadn't read the documentation, or just didn't understand the semantics of what they were doing. Very very rarely, especially these days, has it been an actual DB bug (though I will admit I got Mongo to core one time on 2.4 doing a compaction). And it's a little disingenuous to point at the issue tracker -- as you say, everyone has open issues. The specific things that are mentioned though have been fixed: writes are checked by default now, the global lock has been broken up into per table locks, etc. There may still be common issues that aren't being addressed, but if there are, I'm not aware of them.

spimmy 12y ago

God yeah, the write locks have been a pain in my ass for so long. Fortunately the storage engine API delegates locking to the engine, so we get document level locking in RocksDB or WT.

lacker 12y ago

some of MongoDB's direct competitors do not suffer from these problems and can largely function as drop-in replacements Which competitors are you referring to? Personally I find the power and flexibility of the MongoDB query language to be a big positive that for many cases outweighs performance and reliability issues. It seems like no other competitors are quite there.

andrewflnr 12y ago
GP may be thinking of RethinkDB.
functional_test 12y ago
TokuMX supports most of Mongo's features besides the aggregation framework last I looked. Better locking, transaction support, better indices too -- you should check it out.
benjarrell 12y ago
I don't know that I would call them competitors, but DB2 and Informix both have JSON support and both implement the MonogoDB protocol.
- ahachete 12y ago
  Also ToroDB (https://github.com/torodb/torodb https://github.com/torodb/torodb) implements the MongoDB protocol. But it uses PostgreSQL as a backend and it's open source ;P (ToroDB developer here)
Jweb_Guru 12y ago
In addition to the others already mentioned, http://hyperdex.org/ http://hyperdex.org/ implements the MongoDB API (though I cannot vouch for all of its claims, it seems worth including for completeness).

functional_test 12y ago

This is the last one of these posts I'll ever respond to, I promise. And I'll give you the same response I've given every other time before: You should not base your decision of database (or anything else for that matter) on marketing copy. For something as important as your primary data store, you should at minimum read the full documentation and run some tests with dummy data to see if it will even plausibly work for your use case. I used MongoDB successfully for years with a large data set (>1TB) and 100% production uptime for more than 3 years. I never lost data. Your claim that you will unavoidably lose data is baseless and without merit. In fact, every issue you listed has been fixed, again, counter to your claim. Personally, these days I prefer TokuMX if I'm looking for something compatible with MongoDB, but these baseless attacks on MongoDB have to stop. EDIT: Every time I make a post like this, I get some downvotes without responses. Please tell me why I'm wrong. If it's just that I'm abrasive... Well, you would be too if you were addressing the same thing for the Nth time.

inglor 12y ago
Not the downvoter - but I can totally understand the downvote. The fact your anecdotal evidence is that you did not lose any data doesn't mean the internet is not full of people who have lost data with Mongo. I have no idea what your workload is, but my experience with data loss and uptime has not been as great as yours. I'm not for bashing things either - I think there are cases Mongo might be appropriate, I just don't like countering claims with "it worked for me on this one data set". If it drops writes for one out of 100 people that's still a big reason to avoid it if that's a big concern for you. As for "these issues have been fixed" you're welcome to open the issue tracker - no one at Mongo claims all of these issues have been fixed (then again, PostgreSQL has open issues too) so your claim that "these issues have been fixed" is kind of odd...
- functional_test 12y ago
  I only brought that up to counter his claim that data loss is inevitable. Of course my anecdote doesn't mean it's not common =) But anecdotes are all anyone else has, and every time I've read one about someone losing data, they either hadn't read the documentation, or just didn't understand the semantics of what they were doing. Very very rarely, especially these days, has it been an actual DB bug (though I will admit I got Mongo to core one time on 2.4 doing a compaction). And it's a little disingenuous to point at the issue tracker -- as you say, everyone has open issues. The specific things that are mentioned though have been fixed: writes are checked by default now, the global lock has been broken up into per table locks, etc. There may still be common issues that aren't being addressed, but if there are, I'm not aware of them.