

Goodbye global lock – MongoDB 2.0 vs 2.2 - bsg75
http://blog.serverdensity.com/2012/05/23/goodbye-global-lock-mongodb-2-0-vs-2-2/

======
mitchellh
They've moved from a _process_ level lock to a _database_ level lock. Let's
take a moment to golf clap their mediocrity. _golf clap_

Use a real database.

~~~
bsg75
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.

~~~
shubber
It seems like Mongo in particular is reinventing the RDBMS wheel entirely,
except with a frustrating JSON query language. The benchmark blog post a
couple of days ago versus an out-of-the-box Postgres deploy (i.e. memory
crippled) was not very impressive.

And look: they've implemented clusters - by pushing a Slony equivalent into
the DB itself.

Please forgive my bile - I was a little nonplussed with Mongo, and now I have
to use it for a client. Now I'm a lot nonplussed.

~~~
defen
Just an FYI - you're using the word "nonplussed" incorrectly.

~~~
inportb
Perhaps shubber is nonplussed after learning about MongoDB's query language
design and the client's choice of database -- why would anyone actually want
such a monstrosity?!

~~~
taligent
Because MongoDB is a fantastic database for developers whilst RDBMS can suck
big time.

In this age of agile development requirements and schemas change very, very
rapidly and MongoDB excels at being able to support that.

~~~
bsg75
I am genuinely interested in why schema changes in RDBMS' are such a point of
contention. Is it the addition of new columns that are problematic, or the
modification of existing column datatypes?

Having written more than one mechanism to automate schema upgrades in remote
deployments, and numerous migration scripts, I know it is an extra step in the
development process, but I have not considered it an onerous one.

~~~
gcarre
Try ALTER TABLE ADD COLUMN on a 100 million rows table :).

Jeremy Zawodny from Craigslist explained why it helped them a lot for
Craigslist archives database, where an alter table could take up to 24 hours:
<http://www.10gen.com/presentations/mongosf2011/craigslist>

~~~
bsg75
OK, a MySQL problem. Not so much with PostgreSQL, where adding new columns
noes not need to touch every table row.

NoSQL ~= NoMySQL

------
peterbe
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.

------
timmyd
i guess then in some respects - its funny how correct Adam was in his comments

[http://www.quora.com/Quora-Infrastructure/Why-does-Quora-
use...](http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-
the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc)

------
scorpioxy
"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.

~~~
Karunamon
>Anybody else thing this sentence is silly?

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
Damn, when I glanced upon the title I thought it was about Python's GIL.

~~~
slurgfest
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?

~~~
Mavrik
Um, pretty much all parallelizable CPU number crunching (data mining
algorithms, computer vision etc.) which aren't covered in C code. Those are
especially problematic, since they're usually coupled with numpy and simillar
libraries not supported on other Python implementations - including Jython.

------
onetwothreefour
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.

