14 ms·

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.

scottostler 14y ago
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.
bsg75 14y ago
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.
- nknight 14y ago
  > It seems like the successful(popular) "NoSQL" engines will eventually reinvent many RDBMS wheels. The wheels in question aren't RDBMS wheels, they're just generic database wheels. The backlash against RDBMSs wasn't because of implementation details like this, it was because of the baggage of relational structures in general, and SQL in particular. The "reinvention" of these wheels is occurring now because non-relational databases are maturing now.
  - bsg75 14y ago
    Point taken. As I spend most of my time in SQL, and have come to find a comfortable language to use, I can still understand why fixed schemas give developers headaches - especially when schema migrations in MySQL can result in extra work to minimize downtime. I mention MySQL specifically, because most of the RDBMS -> NoSQL cases I see came from MySQL users. Coming from MSSQL, and now PostreSQL, it seems as though NoSQL is partially a NoMySQL sentiment.
- mitchellh 14y ago
  I don't claim that it is easy, especially with an RDBMS. Actually, given the few courses I took in university on database design, I know its very non-trivial. But MongoDB is not an RDBMS. There are no joins, so a query can only touch one collection (table) at a time anyways, so at least in that regards its much easier than an RDBMS.
  - bsg75 14y ago
    True - s/RDBMS/DBMS/g
- shubber 14y ago
  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 14y ago
    Just an FYI - you're using the word "nonplussed" incorrectly.
    - inportb 14y ago
      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 14y ago
        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 14y ago
        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.
        SystemOut 14y ago
- sausagefeet 14y ago
  AFAIK, the locking in Mongo has more to do with them using memory mapped files than anything else. Other DB's, like Riak, do not have this problem. But perhaps someone can prove me wrong.
DenisM 14y ago
No need to be snarky, but I certainly share your general sentiment: http://news.ycombinator.com/item?id=3412386 http://news.ycombinator.com/item?id=3412386
taligent 14y ago
And they've indicated that in the next stable release they will have collection level locking. All moving towards sub collection locking. 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.
- tinyjoe 14y ago
  Not that new, and with that much funding they received. They're just being lazy.

scottostler 14y ago

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.

bsg75 14y ago

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.

nknight 14y ago
> It seems like the successful(popular) "NoSQL" engines will eventually reinvent many RDBMS wheels. The wheels in question aren't RDBMS wheels, they're just generic database wheels. The backlash against RDBMSs wasn't because of implementation details like this, it was because of the baggage of relational structures in general, and SQL in particular. The "reinvention" of these wheels is occurring now because non-relational databases are maturing now.
- bsg75 14y ago
  Point taken. As I spend most of my time in SQL, and have come to find a comfortable language to use, I can still understand why fixed schemas give developers headaches - especially when schema migrations in MySQL can result in extra work to minimize downtime. I mention MySQL specifically, because most of the RDBMS -> NoSQL cases I see came from MySQL users. Coming from MSSQL, and now PostreSQL, it seems as though NoSQL is partially a NoMySQL sentiment.
mitchellh 14y ago
I don't claim that it is easy, especially with an RDBMS. Actually, given the few courses I took in university on database design, I know its very non-trivial. But MongoDB is not an RDBMS. There are no joins, so a query can only touch one collection (table) at a time anyways, so at least in that regards its much easier than an RDBMS.
- bsg75 14y ago
  True - s/RDBMS/DBMS/g
shubber 14y ago
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 14y ago
  Just an FYI - you're using the word "nonplussed" incorrectly.
  - inportb 14y ago
    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 14y ago
      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 14y ago
        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.
        SystemOut 14y ago
sausagefeet 14y ago
AFAIK, the locking in Mongo has more to do with them using memory mapped files than anything else. Other DB's, like Riak, do not have this problem. But perhaps someone can prove me wrong.

DenisM 14y ago

No need to be snarky, but I certainly share your general sentiment: http://news.ycombinator.com/item?id=3412386 http://news.ycombinator.com/item?id=3412386

taligent 14y ago

And they've indicated that in the next stable release they will have collection level locking. All moving towards sub collection locking. 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.

tinyjoe 14y ago
Not that new, and with that much funding they received. They're just being lazy.