I am a Real Database(tm) person, but I will give them some credit for:
"Nevertheless, a major focus for the upcoming 2.2 release has been removing the global lock and introducing database level locking as an initial step towards collection level locking and potentially even more granular concurrency in future releases."
This stuff is hard to get right, and why RDBMS' are simultaneously maligned as "old tech", yet are still the most dependable database mechanisms available.
It seems like the successful(popular) "NoSQL" engines will eventually reinvent many RDBMS wheels - at least in the cases where they are aiming to be replacements.
If you take a look at the benchmarks further down the page, the real improvement seems to be that mongo does a better job of yielding during page faults. That provides an improvement even with a single database.
Well done 10gen peeps! Keep up the good work. You deserve all the credit you can get. There's still a lot of work to do to catch up with established RDBMSes but you're definitely getting a bunch of things right already today.
"10gen do not provide official benchmarks because they tend to be irrelevant to real world usage."
Anybody else thing this sentence is silly? I definitely do not base my judgement on a tool off its artificial benchmarks but I do check them to see if an upgrade is worth it or not. Irrelevant or not, please publish them.
I'm a mongo user(for offline analytics) so any improvement in performance will be good.
Not really. It's a lose/lose proposition to publish benchmarks, especially on something that's so environment and dataset dependent. Either real world performance is way below the benchmark leading to all kinds of storm and strife, or way above and then you lose credibility and people wondered why you bother anyways.
What actual use case do you have that CPython's GIL is affecting in any serious way? And if you do have a real case which somehow requires the removal of the GIL, why don't you just use Jython, which has no GIL and recently released an implementation of Python 2.7?
These posts (the one about 20ms for a memcached lookup especially) make me doubt the technical prowess of the entire ServerDensity staff, and thereby stopping me from ever considering this product.
[+] [-] mitchellh|14 years ago|reply
Use a real database.
[+] [-] bsg75|14 years ago|reply
"Nevertheless, a major focus for the upcoming 2.2 release has been removing the global lock and introducing database level locking as an initial step towards collection level locking and potentially even more granular concurrency in future releases."
This stuff is hard to get right, and why RDBMS' are simultaneously maligned as "old tech", yet are still the most dependable database mechanisms available.
It seems like the successful(popular) "NoSQL" engines will eventually reinvent many RDBMS wheels - at least in the cases where they are aiming to be replacements.
[+] [-] scottostler|14 years ago|reply
[+] [-] DenisM|14 years ago|reply
http://news.ycombinator.com/item?id=3412386
[+] [-] taligent|14 years ago|reply
It is a relatively new database and they trying to make changes in small increments to ensure they don't break anything.
Seems prudent to me.
[+] [-] peterbe|14 years ago|reply
[+] [-] timmyd|14 years ago|reply
http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use...
[+] [-] scorpioxy|14 years ago|reply
Anybody else thing this sentence is silly? I definitely do not base my judgement on a tool off its artificial benchmarks but I do check them to see if an upgrade is worth it or not. Irrelevant or not, please publish them.
I'm a mongo user(for offline analytics) so any improvement in performance will be good.
[+] [-] Karunamon|14 years ago|reply
Not really. It's a lose/lose proposition to publish benchmarks, especially on something that's so environment and dataset dependent. Either real world performance is way below the benchmark leading to all kinds of storm and strife, or way above and then you lose credibility and people wondered why you bother anyways.
[+] [-] facorreia|14 years ago|reply
[+] [-] slurgfest|14 years ago|reply
[+] [-] onetwothreefour|14 years ago|reply
[+] [-] unknown|14 years ago|reply
[deleted]