15 ms·

Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read

by dia80 14y ago

Genuine question: In what use cases does mongo kick mysql's ass? I've used it a couple of times in hobby projects and enjoyed not maintaining a schema. I read so many of these 'gotcha' style articles and for example one commenter here wants to have a manual "recently dirty" flag to combat the master / slave lag mentioned in the article. I know it's faster (tm) but once you have to take in to account all this low level stuff you have to worry about yourself wouldn't it just be better to rent/buy another rack of mysql servers and not worry about it? Look forward to learning something...

alexro 14y ago
IMO there is no rational explanation to this phenomena other than: people are different. Some get bored with stored procs and want same hassle but in another form.
- morsch 14y ago
  A cynical but insightful description of many kinds of progress and change. ;)
- taligent 14y ago
  Yes. There is no rational explanation for people using the right tool for the right job. Let me guess. You would build a skyscraper using a trough and cement in a bucket ?
  - jamesaguilar 14y ago
    Are you trying to give us an idea of what it's like to build an even moderate sized app without transactional consistency and with mapreduce? Because that is what it sounds like to me.
diminoten 14y ago
Mongo isn't so important to this question as ODB vs RDBMS. Here's some light reading: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis... MongoDB is just ODB, and MySQL is just RDB. Besides, postgres is the real future!
- dleblanc 14y ago
  Not sure what Wu-Tang has to do with this, but.... Seriously though, is Mongo an ODB, or a document oriented database? ODBs/OODBs imply a much different use-case and functionality, and I think we ought not conflate the two.
  - ww520 14y ago
    Mongo is not an ODB in the traditional ODB sense. Mongo is just a document (or blob) database. ODB supports relationship, link traversal, inheritance, etc. Basically the whole shebang of the OO notions in a database.
  - diminoten 14y ago
    You're right, I didn't know there was a difference.
- taligent 14y ago
  PostgreSQL is the PAST and it will forever remain there until it solves its biggest problems. It is the hardest out of all databases I've used to cluster, replicate, shard and manage. And the database world is moving towards scaling horizontally rather than vertically. I can push a button in say CouchDB to replicate and shard. Try doing that in PostgreSQL.
  - true_religion 14y ago
    People still use SQLlite. Why? Because its suits a specific set of circumstances. Postgres does the same---its an incredibly powerful database with a large suit of features that make application development both easy and sane. To the vast majority of projects where you won't outgrow a single server, it makes sense to use it.
  - jeffdavis 14y ago
    "And the database world is moving towards scaling horizontally rather than vertically." I think that's an oversimplification. Two counterpoints: * Database systems will always need to make heavy use of locality. The speed of light means that synchronizing access over long distances (even medium distances -- light only goes about a foot per nanosecond) will always be a challenge. * Multi-core means vertical scaling is back in (if by "vertical scaling" you mean "scaling on one box"), and probably for a while. Postgres is doing an excellent job at both. I do agree with the less-exaggerated point that postgres really needs to improve its multi-machine scaling. But it's far from a solved problem on any system under discussion.
thibaut_barrere 14y ago
MongoDB kicks ass in the following situations (real projects I did as a freelancer): - dealing with semi-structured input (forms with some variability) and storing as a document, all while being able to query across the data - used as a store to provide very flexible ETL jobs (with ability to upsert, filter/query, geonear etc) For those situations, I would definitely use MongoDB again. As a RDBMS replacement, I wouldn't use it today.
- jandy 14y ago
  To elaborate on the semi-structured input point: Monogo and it's kin are great for EAV systems (http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%...), where your entities can have an arbitrary number of fields (often user defined). Trying to build this kind of system in a traditional RDBMs can be quite tricky.
  - sgolestane 14y ago
    Since we are a mysql shop, for this use-cases I serialize and store the form as xml in a CLOB column. For any field that needs to be searched on, I create an additional column. Disadvantage of this is you can't run mysql queries against the data stored in the CLOB column.
    - thibaut_barrere 14y ago
      Adding column per searchable field is precisely what I wanted to avoid :-) If you need to store multiple forms types, it gets hairy very fast. MongoDB allows to query inside the data (which is not a blob in that case).
      - jeltz 14y ago
        So does PostgreSQL, but I have no idea about MySQL. You can run xpath queries against XML documents, and you can also index specific xpath queries (there is no general indexing infrastructure for XML in PostgreSQL). For JSON no path lookup functions are included in the core yet, but I assume there are extensions which add them.
mattparlane 14y ago
My number one reason for choosing MongoDB is replication that just works out of the box and doesn't require either a read lock or shutting down the master to set up a new slave.
- sausagefeet 14y ago
  As far as I can tell, Riak blows mongo away for this particular criteria.
  - mattparlane 14y ago
    That's my understanding too, but MongoDB hit the sweet-spot for us, Riak couldn't handle the raw queries-per-second we needed without requiring extra hardware ($$).
  - jaimebuelta 14y ago
    But Riak is much limited on the queries you can run.
- jeltz 14y ago
  Serious question: What database requires read locks or shutting down the master for setting up a new slave? Is it MySQL? Both sounds like really weird requirements for replication which defeats half the purpose of having it. PostgreSQL has never had any of these two problems. Still working on improving usability but with the addition and improvements of pg_basbackup I would say it is almost there. Hopefully 9.3 will get timeline switching to simplify failover.
untog 14y ago
I think there are legitimate reasons to use a "NoSQL" solution rather than MySQL. I'm more interested to know in what use cases Mongo kicks it's competitors asses? What are it's competitors, even? I'll admit that the NoSQL world is a slightly blurry mess to me, with different products seemingly optimised for different cases.
- taligent 14y ago
  MongoDB is a JSON document store. Almost all other NoSQL are key/value type stores. If you have a use case that centres around storing document style data then MongoDB will be better suited.
  - trustfundbaby 14y ago
    not to be persnickety but its a BSON document store. Theres a difference.
mrkurt 14y ago
Eventually consistant replication is not unique to MongoDB, most DBs have an async replication option. Using "not Mongo" won't really solve it.
- krichman 14y ago
  An option is not a default, though, so using Postgres or MySQL absolutely would solve the problem of returning with success before persisting the data. The contentious area isn't really that Mongo does this, it's because for whatever reason the people trying it don't expect Mongo to do this.
mrinterweb 14y ago
Map reduce across sharded servers comes to mind as an advantage. For that matter, horizontal scalability in general is a big advantage that many of the NoSQL data stores have over RDBMS databases.
elchief 14y ago
When you have so many writes that sharding isn't enough. When you make changes so fast you need a liquid schema. When you want to make your boss learn map-reduce so he can query the data. When the application can take care of integration and not the database itself.
- lwat 14y ago
  > When you have so many writes that sharding isn't enough. Does Mongo still have a global write lock?
  - elchief 14y ago
    no longer (but only a few months)
    - mgummelt 14y ago
      Though I believe it still has a per-collection lock.
      - Jare 14y ago
        It has per-database locking. Per-collection is being worked on but no planned date yet. [1] [1] http://www.mongodb.org/display/DOCS/How+does+concurrency+work#Howdoesconcurrencywork-mongod http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...
- leif 14y ago
  This will be obvious, but I work at Tokutek. > When you have so many writes that sharding isn't enough. TokuDB does indexed insertions very fast. [1] We've even plugged ourselves in underneath MongoDB (just for fun) and we beat them too. [2] > When you make changes so fast you need a liquid schema. TokuDB supports lots of schema changes with zero downtime. [3] > When you want to make your boss learn map-reduce so he can query the data. Can't help you there, but I can make you not need to torture your boss that way. > When the application can care of integration and not the database. What if it didn't need to? We also get fantastic compression [4], retain full transactional semantics, and lots of other fun stuff. Email us if you're curious! [1]: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#iiBench http://www.tokutek.com/resources/benchmark-results/benchmark... [2]: http://www.tokutek.com/2012/08/10x-insertion-performance-increase-for-mongodb-with-fractal-tree-indexes/ http://www.tokutek.com/2012/08/10x-insertion-performance-inc... [3]: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#HotSchema http://www.tokutek.com/resources/benchmark-results/benchmark... [4]: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#Compression http://www.tokutek.com/resources/benchmark-results/benchmark...
jeremyjh 14y ago
One issue with MySQL in large databases is that schema changes are extremely expensive, so much so that you'll be making design decisions around it (e.g. how do we implement this feature without executing our two-day alter table statement). Not all RDBMS have this problem to such a degree but none can escape it entirely. A lot of the gotchas that he notes are related to design trade-offs with different default behavior than an RDBMS typically would have. For example as your system gets large enough in MySQL you may find you have to do asynchronous replication as well, and then you will have similar problems with dirty reads.
- bsg75 14y ago
  > e.g. how do we implement this feature without executing our two-day alter table statement? With MySQL being so prevalent, IMO this is the principal reason why the concept that RDBMS' are hard to work with exists. None of the other major platforms have this issue, but if a developer's only exposure is to MySQL, then the idea of schema alters are always fearsome. This is not to say that ALTER TABLE statements are always quick - if constraint checks or default values are included, there can be long runtimes in PostgreSQL, MSSQL, Oracle, etc. - but significant downtime to add an empty nullable column is just plain stupid for a platform that has been around as long as MySQL. MySQL has forced a major population segment of developers to toss the advantages of DB side validation and rich query languages for the purpose of _avoiding_MySQL_. Sure the whole object-relational impedance mismatch exists, SQL is hard, yada-yada, but I have never seen these reasons cause as much angst as taking a service offline to add a column to a table. 10gen should have a picture of Monty in their CFO's office.

by dia80 14y ago

alexro 14y ago

IMO there is no rational explanation to this phenomena other than: people are different. Some get bored with stored procs and want same hassle but in another form.

morsch 14y ago
A cynical but insightful description of many kinds of progress and change. ;)
taligent 14y ago
Yes. There is no rational explanation for people using the right tool for the right job. Let me guess. You would build a skyscraper using a trough and cement in a bucket ?
- jamesaguilar 14y ago
  Are you trying to give us an idea of what it's like to build an even moderate sized app without transactional consistency and with mapreduce? Because that is what it sounds like to me.

diminoten 14y ago

Mongo isn't so important to this question as ODB vs RDBMS. Here's some light reading: http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch http://en.wikipedia.org/wiki/Object-relational_impedance_mis... MongoDB is just ODB, and MySQL is just RDB. Besides, postgres is the real future!

dleblanc 14y ago
Not sure what Wu-Tang has to do with this, but.... Seriously though, is Mongo an ODB, or a document oriented database? ODBs/OODBs imply a much different use-case and functionality, and I think we ought not conflate the two.
- ww520 14y ago
  Mongo is not an ODB in the traditional ODB sense. Mongo is just a document (or blob) database. ODB supports relationship, link traversal, inheritance, etc. Basically the whole shebang of the OO notions in a database.
- diminoten 14y ago
  You're right, I didn't know there was a difference.
taligent 14y ago
PostgreSQL is the PAST and it will forever remain there until it solves its biggest problems. It is the hardest out of all databases I've used to cluster, replicate, shard and manage. And the database world is moving towards scaling horizontally rather than vertically. I can push a button in say CouchDB to replicate and shard. Try doing that in PostgreSQL.
- true_religion 14y ago
  People still use SQLlite. Why? Because its suits a specific set of circumstances. Postgres does the same---its an incredibly powerful database with a large suit of features that make application development both easy and sane. To the vast majority of projects where you won't outgrow a single server, it makes sense to use it.
- jeffdavis 14y ago
  "And the database world is moving towards scaling horizontally rather than vertically." I think that's an oversimplification. Two counterpoints: * Database systems will always need to make heavy use of locality. The speed of light means that synchronizing access over long distances (even medium distances -- light only goes about a foot per nanosecond) will always be a challenge. * Multi-core means vertical scaling is back in (if by "vertical scaling" you mean "scaling on one box"), and probably for a while. Postgres is doing an excellent job at both. I do agree with the less-exaggerated point that postgres really needs to improve its multi-machine scaling. But it's far from a solved problem on any system under discussion.

thibaut_barrere 14y ago

MongoDB kicks ass in the following situations (real projects I did as a freelancer): - dealing with semi-structured input (forms with some variability) and storing as a document, all while being able to query across the data - used as a store to provide very flexible ETL jobs (with ability to upsert, filter/query, geonear etc) For those situations, I would definitely use MongoDB again. As a RDBMS replacement, I wouldn't use it today.

jandy 14y ago
To elaborate on the semi-structured input point: Monogo and it's kin are great for EAV systems (http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%...), where your entities can have an arbitrary number of fields (often user defined). Trying to build this kind of system in a traditional RDBMs can be quite tricky.
- sgolestane 14y ago
  Since we are a mysql shop, for this use-cases I serialize and store the form as xml in a CLOB column. For any field that needs to be searched on, I create an additional column. Disadvantage of this is you can't run mysql queries against the data stored in the CLOB column.
  - thibaut_barrere 14y ago
    Adding column per searchable field is precisely what I wanted to avoid :-) If you need to store multiple forms types, it gets hairy very fast. MongoDB allows to query inside the data (which is not a blob in that case).
    - jeltz 14y ago
      So does PostgreSQL, but I have no idea about MySQL. You can run xpath queries against XML documents, and you can also index specific xpath queries (there is no general indexing infrastructure for XML in PostgreSQL). For JSON no path lookup functions are included in the core yet, but I assume there are extensions which add them.

mattparlane 14y ago

My number one reason for choosing MongoDB is replication that just works out of the box and doesn't require either a read lock or shutting down the master to set up a new slave.

sausagefeet 14y ago
As far as I can tell, Riak blows mongo away for this particular criteria.
- mattparlane 14y ago
  That's my understanding too, but MongoDB hit the sweet-spot for us, Riak couldn't handle the raw queries-per-second we needed without requiring extra hardware ($$).
- jaimebuelta 14y ago
  But Riak is much limited on the queries you can run.
jeltz 14y ago
Serious question: What database requires read locks or shutting down the master for setting up a new slave? Is it MySQL? Both sounds like really weird requirements for replication which defeats half the purpose of having it. PostgreSQL has never had any of these two problems. Still working on improving usability but with the addition and improvements of pg_basbackup I would say it is almost there. Hopefully 9.3 will get timeline switching to simplify failover.

untog 14y ago

I think there are legitimate reasons to use a "NoSQL" solution rather than MySQL. I'm more interested to know in what use cases Mongo kicks it's competitors asses? What are it's competitors, even? I'll admit that the NoSQL world is a slightly blurry mess to me, with different products seemingly optimised for different cases.

taligent 14y ago
MongoDB is a JSON document store. Almost all other NoSQL are key/value type stores. If you have a use case that centres around storing document style data then MongoDB will be better suited.
- trustfundbaby 14y ago
  not to be persnickety but its a BSON document store. Theres a difference.

mrkurt 14y ago

Eventually consistant replication is not unique to MongoDB, most DBs have an async replication option. Using "not Mongo" won't really solve it.

krichman 14y ago
An option is not a default, though, so using Postgres or MySQL absolutely would solve the problem of returning with success before persisting the data. The contentious area isn't really that Mongo does this, it's because for whatever reason the people trying it don't expect Mongo to do this.

mrinterweb 14y ago

Map reduce across sharded servers comes to mind as an advantage. For that matter, horizontal scalability in general is a big advantage that many of the NoSQL data stores have over RDBMS databases.

elchief 14y ago

When you have so many writes that sharding isn't enough. When you make changes so fast you need a liquid schema. When you want to make your boss learn map-reduce so he can query the data. When the application can take care of integration and not the database itself.

lwat 14y ago
> When you have so many writes that sharding isn't enough. Does Mongo still have a global write lock?
- elchief 14y ago
  no longer (but only a few months)
  - mgummelt 14y ago
    Though I believe it still has a per-collection lock.
    - Jare 14y ago
      It has per-database locking. Per-collection is being worked on but no planned date yet. [1] [1] http://www.mongodb.org/display/DOCS/How+does+concurrency+work#Howdoesconcurrencywork-mongod http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...
leif 14y ago
This will be obvious, but I work at Tokutek. > When you have so many writes that sharding isn't enough. TokuDB does indexed insertions very fast. [1] We've even plugged ourselves in underneath MongoDB (just for fun) and we beat them too. [2] > When you make changes so fast you need a liquid schema. TokuDB supports lots of schema changes with zero downtime. [3] > When you want to make your boss learn map-reduce so he can query the data. Can't help you there, but I can make you not need to torture your boss that way. > When the application can care of integration and not the database. What if it didn't need to? We also get fantastic compression [4], retain full transactional semantics, and lots of other fun stuff. Email us if you're curious! [1]: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#iiBench http://www.tokutek.com/resources/benchmark-results/benchmark... [2]: http://www.tokutek.com/2012/08/10x-insertion-performance-increase-for-mongodb-with-fractal-tree-indexes/ http://www.tokutek.com/2012/08/10x-insertion-performance-inc... [3]: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#HotSchema http://www.tokutek.com/resources/benchmark-results/benchmark... [4]: http://www.tokutek.com/resources/benchmark-results/benchmarks-vs-innodb-hdds/#Compression http://www.tokutek.com/resources/benchmark-results/benchmark...

jeremyjh 14y ago

One issue with MySQL in large databases is that schema changes are extremely expensive, so much so that you'll be making design decisions around it (e.g. how do we implement this feature without executing our two-day alter table statement). Not all RDBMS have this problem to such a degree but none can escape it entirely. A lot of the gotchas that he notes are related to design trade-offs with different default behavior than an RDBMS typically would have. For example as your system gets large enough in MySQL you may find you have to do asynchronous replication as well, and then you will have similar problems with dirty reads.

bsg75 14y ago
> e.g. how do we implement this feature without executing our two-day alter table statement? With MySQL being so prevalent, IMO this is the principal reason why the concept that RDBMS' are hard to work with exists. None of the other major platforms have this issue, but if a developer's only exposure is to MySQL, then the idea of schema alters are always fearsome. This is not to say that ALTER TABLE statements are always quick - if constraint checks or default values are included, there can be long runtimes in PostgreSQL, MSSQL, Oracle, etc. - but significant downtime to add an empty nullable column is just plain stupid for a platform that has been around as long as MySQL. MySQL has forced a major population segment of developers to toss the advantages of DB side validation and rich query languages for the purpose of _avoiding_MySQL_. Sure the whole object-relational impedance mismatch exists, SQL is hard, yada-yada, but I have never seen these reasons cause as much angst as taking a service offline to add a column to a table. 10gen should have a picture of Monty in their CFO's office.