5 ms·

MongoDB showing that in the years since this[1] was published that have learned nothing. Still chasing artificial benchmarks at the expensive of data safety and

MongoDB showing that in the years since this[1] was published that have learned nothing. Still chasing artificial benchmarks at the expensive of data safety and either personal or corporate integrity. [1]: http://pastebin.com/raw.php?i=FD3xe6Jt http://pastebin.com/raw.php?i=FD3xe6Jt

towelguy 11y ago
Does this still applies to MongoDB 3.0? since it seems to be a rewrite with a new storage engine [1]. [1] http://www.mongodb.com/blog/post/announcing-mongodb-30 http://www.mongodb.com/blog/post/announcing-mongodb-30
- nemo44x 11y ago
  That is based on a pre-2.0 version of MongoDB. The changes and vast improvements from that time to now are huge. MongoDB probably got a bit ahead of itself too fast - it wasn't mature and took a lot of development shortcuts to get features out fast and people started using it like a mature datastore too fast - and the company behind it didn't help either. But, without a doubt there have been vast improvements across the board and I give them credit for spending the last year and a half not adding many new features but rebuilding the codebase, making it extendable (pluggable storage engines is a cool thing) and addressing numerous issues. It still has some issues (b-trees aren't the best implementation imo) but the codebase is in a state where I expect over the next few years it will be quite reliable. The tooling around MongoDB has gotten better too. There's still a ton of ways to shoot yourself in the foot too but the defaults are more sensible I think now than then. What they got right is the clients are awesome and the query language is powerful - especially updates. This matters for a lot of people - it isn't just a drag race always in terms of performance. Now, with increased reliability it's becoming something usable for some use cases.
functional_test 11y ago
I reply to these posts on HN relatively frequently these days. These sorts of accusations about Mongo are out of hand, and not congruent with reality. I say this as someone who used MongoDB extensively. I don't have time to address all of the problems, but let's look at #1 on his list: 1. MongoDB issues writes in unsafe ways by default in order to win benchmarks This is objectively false. At the time, Mongo chose to turn off write confirmations by default -- this was clearly documented in many places including introductory documentation. Surely no one would have deployed a database without even a cursory skim of the docs, right? The notion that it was done to win benchmarks is baseless. Furthermore, in response to the community's reaction, the default was changed. This is a recurring problem with the complaints about Mongo. You cannot use ad copy to evaluate a database (or any product for that matter, but definitely not something as important as your primary data store). You must read the documentation. You must do a trial run and make sure it will meet the needs of your use case. You can't be upset about the results you didn't get from the work you didn't do.

towelguy 11y ago

Does this still applies to MongoDB 3.0? since it seems to be a rewrite with a new storage engine [1]. [1] http://www.mongodb.com/blog/post/announcing-mongodb-30 http://www.mongodb.com/blog/post/announcing-mongodb-30

nemo44x 11y ago
That is based on a pre-2.0 version of MongoDB. The changes and vast improvements from that time to now are huge. MongoDB probably got a bit ahead of itself too fast - it wasn't mature and took a lot of development shortcuts to get features out fast and people started using it like a mature datastore too fast - and the company behind it didn't help either. But, without a doubt there have been vast improvements across the board and I give them credit for spending the last year and a half not adding many new features but rebuilding the codebase, making it extendable (pluggable storage engines is a cool thing) and addressing numerous issues. It still has some issues (b-trees aren't the best implementation imo) but the codebase is in a state where I expect over the next few years it will be quite reliable. The tooling around MongoDB has gotten better too. There's still a ton of ways to shoot yourself in the foot too but the defaults are more sensible I think now than then. What they got right is the clients are awesome and the query language is powerful - especially updates. This matters for a lot of people - it isn't just a drag race always in terms of performance. Now, with increased reliability it's becoming something usable for some use cases.

functional_test 11y ago

I reply to these posts on HN relatively frequently these days. These sorts of accusations about Mongo are out of hand, and not congruent with reality. I say this as someone who used MongoDB extensively. I don't have time to address all of the problems, but let's look at #1 on his list: 1. MongoDB issues writes in unsafe ways by default in order to win benchmarks This is objectively false. At the time, Mongo chose to turn off write confirmations by default -- this was clearly documented in many places including introductory documentation. Surely no one would have deployed a database without even a cursory skim of the docs, right? The notion that it was done to win benchmarks is baseless. Furthermore, in response to the community's reaction, the default was changed. This is a recurring problem with the complaints about Mongo. You cannot use ad copy to evaluate a database (or any product for that matter, but definitely not something as important as your primary data store). You must read the documentation. You must do a trial run and make sure it will meet the needs of your use case. You can't be upset about the results you didn't get from the work you didn't do.