7 ms·

Since when MongoDB is considered as a database comparable with PostgreSQL?)

by dschiptsov 12y ago

Sanddancer 12y ago
It's a comparison on MongoDB's home turf, showing how well PostgreSQL works when used as a NoSQL document store.
wmf 12y ago
That's not really relevant, since the point is that Postgres can do what MongoDB does but faster.
- threeseed 12y ago
  Except it doesn't. It just has a JSON data type. As does many other databases e.g. Oracle, Teradata. People are switching to MongoDB because the developer and deployment experience is so good.
  - vinceguidry 12y ago
    Capability is not the same thing as usability. Postgres is demonstratively more capable than Mongo, it's just not perceived as usable. There's a deep lesson here to be learned. One that can make you rich.
  - Argorak 12y ago
    Hate to say so, but many are switching to MongoDB because it's the current new kid on the block. I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. Not that MongoDB is a bad database, but it has it's fair share of issues. Granted, this is the case for every database, but if you pick any database without being aware of those, you end up in a world of pain. (Context: I consult for backend systems in general)
    - davidw 12y ago
      That was my only experience with MongoDB - "let's try this, for this experimental project, to see what it's like", without taking into account its characteristics. After that the project grew, I was brought in and needed to do some reports, which were a huge pain in the ass without proper SQL and joins. I don't intend to have anything to do with people using MongoDB unless they have a really, really good reason for doing so, and it's used alongside other databases.
      - bostik 12y ago
        A friend of mine came up with the perfect use-case for MongoDB. His company installs and monitors sensors in civic infrastructure: roads, train tracks, bridges, ... These sensors provide constant data streams which need to be stored somewhere before processing. Any raw data older than 2 weeks is worthless, and if 2-3% of data is lost before written it's not much of a problem. More data is coming in all the time any way. For them MongoDB is the perfect transient cache. Sensor data is processed and the results stored elsewhere. Easy to expand. Flipping between installations is just a matter of toggling load balancer, an once an offline cache has been processed, it can be nuked and put back as a fresh system. So, for a setup where easy size expansion, fast mostly-reliable writes and ease of use are the primary design constraints, mongo fits in suprisingly well. It's a fascinating use-case.
        Argorak 12y ago
        From what that sounds like, I agree. This is a complex problem description with a pointer where the database provides solutions.
    - Xylakant 12y ago
      > I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. As in "Our lead dev always wanted to try X, because he likes the name". Given that, I really need to build an app using project-he-who-may-not-be-named.
    - larry_the_lover 12y ago
  - jsemrau 12y ago
    >because the developer and deployment experience is so good. That was ironic, right? http://php.net/manual/en/mongo.sqltomongo.php http://php.net/manual/en/mongo.sqltomongo.php
    - deleted 12y ago
      [deleted]
    - deleted 12y ago
      [deleted]
    - aikah 12y ago
      Strangely,there is no JOIN example ...
      - Xylakant 12y ago
        Well, you won't find one. That's a property of the way the system works. It can be either good or bad, but you won't find an example on how to store and query whole documents with a map/reduce implementation on an SQL database. Both can be either a good fit or a bad fit to your needs - I've seen project that leveraged CouchDB to basically return all data for any given view with a single query from a pre-calculated view, something which would have impossible with an SQL database. That's a good fit. Using a document store as drop-in-replacement for an SQL dabase is most of the time a very very bad fit. The general issue that I often see is that people don't choose their databases by "is this a good fit or a bad fit for our use case" but rather by "that looks cool" or "we need that to attract talent" or "we did that project with X, so X is also fine for that new, totally different thing". And then they also try and stick with it at all costs, instead of acknowledging that the choice was a bad fit. And then they call you and say "we have an X database in flames, can you come in and rescue our data? Best would be yesterday?" This is not restricted to document databases. I've seen apps run on mysql on a cluster with 10 Sun XFires where after a man-month of index-optimization 3 would have been sufficient. That was like shooting dead fish in a dry barrel. A lot of developers don't want to bother with stuff like "how does that complicated piece of machinery actually behave if I push it."
  - Xylakant 12y ago
    I maintain an environment that has both pg and mongodb. While pg was simple to install and to debug, mongo has given me just pains. I agree that MongoDBs developer experience is nice - download, run, develop, but from the OPS side, that looks totally different. PG is a bit the other way round. The sad state of affairs however is that often developers choose which DB they'd like to work with and (Dev)OPS doesn't get a say in that.
  - kristaps 12y ago
    I refuse to believe you speak from experience.
  - kristaps 12y ago
    I refuse to believe you speak from experience.
  - aikah 12y ago
    > People are switching to MongoDB because the developer and deployment experience is so good. WAT? can you tell us more about your experience? according to mine ,developers are moving away "en masse" from Mongodb,because the experience was so bad.
- rwmj 12y ago
  ... and far more safely. No one should be using MongoDB in production (or if you do, please never let me store data in your service).
pjmlp 12y ago
Since NoSQL movement started comparing their database options with SQL based ones.
- dschiptsov 12y ago
  Come on. To call itself a database the product should have state-of-the-art storage technology implemented, not just a simple API which always returns OK before actual data has been committed to disk. In old times you could suddenly switch off power of a running Informix server and it will correctly restore the state on that very moment after reboot, dropping all partially (unfinished) transactions, keeping all the committed ones, so it was possible to have a clean state of the system. How does it work? Append-only so-called "physical logs" on an direct-access, unbuffered by an OS and hard drives storage, proper partitioning on separate physical drives (for real parallelism), etc. Again, real databases are all about data-storage (architecture, data-structures, algorithms, design decisions, proper implementation) not some "user-friendly" APIs and "well-written" docs to quickly gain popularity among ignorant. Database back-ends are among the hardest problems in programming and the amount of research which has been done in 80s and 90s in this field is quite remarkable. I doubt that a bunch of punks with professional marketing and sales techniques could adequately replace implementation of a high-performance and fail-safe storage back-end, which is called a database.
  - Xylakant 12y ago
    So CouchdDB qualifies? Given a proper hardware underneath it will at most loose the last, unfinished write.
  - csmitheu 12y ago
    You are right on all counts. As someone who evaluated and eventually recommended against implementing MongoDB for a new product, I entirely agree with you. The Mongo implementation was shot after about three months of wasted time after failure in pre-production testing. It was rolled back at great cost to SQL Server with a light document-style abstraction as Mongo failed miserably on precisely what you said: reliability, consistency, scalability and storage management. Proper relational databases (PostgreSQL, Oracle, SQL Server in my scope of experience) can take an absolute incredible amount of punishment without breaking any guarantees. The relational bit above is optional but it is at least something you can choose to use or not.
collyw 12y ago
Since the phrase "big data" appeared.

Since when MongoDB is considered as a database comparable with PostgreSQL?)

Sanddancer 12y ago

It's a comparison on MongoDB's home turf, showing how well PostgreSQL works when used as a NoSQL document store.

wmf 12y ago

That's not really relevant, since the point is that Postgres can do what MongoDB does but faster.

threeseed 12y ago
Except it doesn't. It just has a JSON data type. As does many other databases e.g. Oracle, Teradata. People are switching to MongoDB because the developer and deployment experience is so good.
- vinceguidry 12y ago
  Capability is not the same thing as usability. Postgres is demonstratively more capable than Mongo, it's just not perceived as usable. There's a deep lesson here to be learned. One that can make you rich.
- Argorak 12y ago
  Hate to say so, but many are switching to MongoDB because it's the current new kid on the block. I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. Not that MongoDB is a bad database, but it has it's fair share of issues. Granted, this is the case for every database, but if you pick any database without being aware of those, you end up in a world of pain. (Context: I consult for backend systems in general)
  - davidw 12y ago
    That was my only experience with MongoDB - "let's try this, for this experimental project, to see what it's like", without taking into account its characteristics. After that the project grew, I was brought in and needed to do some reports, which were a huge pain in the ass without proper SQL and joins. I don't intend to have anything to do with people using MongoDB unless they have a really, really good reason for doing so, and it's used alongside other databases.
    - bostik 12y ago
      A friend of mine came up with the perfect use-case for MongoDB. His company installs and monitors sensors in civic infrastructure: roads, train tracks, bridges, ... These sensors provide constant data streams which need to be stored somewhere before processing. Any raw data older than 2 weeks is worthless, and if 2-3% of data is lost before written it's not much of a problem. More data is coming in all the time any way. For them MongoDB is the perfect transient cache. Sensor data is processed and the results stored elsewhere. Easy to expand. Flipping between installations is just a matter of toggling load balancer, an once an offline cache has been processed, it can be nuked and put back as a fresh system. So, for a setup where easy size expansion, fast mostly-reliable writes and ease of use are the primary design constraints, mongo fits in suprisingly well. It's a fascinating use-case.
      - Argorak 12y ago
        From what that sounds like, I agree. This is a complex problem description with a pointer where the database provides solutions.
  - Xylakant 12y ago
    > I found that many companies have incredibly bad, not use-case driven reasons to pick their DB. As in "Our lead dev always wanted to try X, because he likes the name". Given that, I really need to build an app using project-he-who-may-not-be-named.
  - larry_the_lover 12y ago
- jsemrau 12y ago
  >because the developer and deployment experience is so good. That was ironic, right? http://php.net/manual/en/mongo.sqltomongo.php http://php.net/manual/en/mongo.sqltomongo.php
  - deleted 12y ago
    [deleted]
  - deleted 12y ago
    [deleted]
  - aikah 12y ago
    Strangely,there is no JOIN example ...
    - Xylakant 12y ago
      Well, you won't find one. That's a property of the way the system works. It can be either good or bad, but you won't find an example on how to store and query whole documents with a map/reduce implementation on an SQL database. Both can be either a good fit or a bad fit to your needs - I've seen project that leveraged CouchDB to basically return all data for any given view with a single query from a pre-calculated view, something which would have impossible with an SQL database. That's a good fit. Using a document store as drop-in-replacement for an SQL dabase is most of the time a very very bad fit. The general issue that I often see is that people don't choose their databases by "is this a good fit or a bad fit for our use case" but rather by "that looks cool" or "we need that to attract talent" or "we did that project with X, so X is also fine for that new, totally different thing". And then they also try and stick with it at all costs, instead of acknowledging that the choice was a bad fit. And then they call you and say "we have an X database in flames, can you come in and rescue our data? Best would be yesterday?" This is not restricted to document databases. I've seen apps run on mysql on a cluster with 10 Sun XFires where after a man-month of index-optimization 3 would have been sufficient. That was like shooting dead fish in a dry barrel. A lot of developers don't want to bother with stuff like "how does that complicated piece of machinery actually behave if I push it."
- Xylakant 12y ago
  I maintain an environment that has both pg and mongodb. While pg was simple to install and to debug, mongo has given me just pains. I agree that MongoDBs developer experience is nice - download, run, develop, but from the OPS side, that looks totally different. PG is a bit the other way round. The sad state of affairs however is that often developers choose which DB they'd like to work with and (Dev)OPS doesn't get a say in that.
- kristaps 12y ago
  I refuse to believe you speak from experience.
- kristaps 12y ago
  I refuse to believe you speak from experience.
- aikah 12y ago
  > People are switching to MongoDB because the developer and deployment experience is so good. WAT? can you tell us more about your experience? according to mine ,developers are moving away "en masse" from Mongodb,because the experience was so bad.
rwmj 12y ago
... and far more safely. No one should be using MongoDB in production (or if you do, please never let me store data in your service).

pjmlp 12y ago

Since NoSQL movement started comparing their database options with SQL based ones.

dschiptsov 12y ago
Come on. To call itself a database the product should have state-of-the-art storage technology implemented, not just a simple API which always returns OK before actual data has been committed to disk. In old times you could suddenly switch off power of a running Informix server and it will correctly restore the state on that very moment after reboot, dropping all partially (unfinished) transactions, keeping all the committed ones, so it was possible to have a clean state of the system. How does it work? Append-only so-called "physical logs" on an direct-access, unbuffered by an OS and hard drives storage, proper partitioning on separate physical drives (for real parallelism), etc. Again, real databases are all about data-storage (architecture, data-structures, algorithms, design decisions, proper implementation) not some "user-friendly" APIs and "well-written" docs to quickly gain popularity among ignorant. Database back-ends are among the hardest problems in programming and the amount of research which has been done in 80s and 90s in this field is quite remarkable. I doubt that a bunch of punks with professional marketing and sales techniques could adequately replace implementation of a high-performance and fail-safe storage back-end, which is called a database.
- Xylakant 12y ago
  So CouchdDB qualifies? Given a proper hardware underneath it will at most loose the last, unfinished write.
- csmitheu 12y ago
  You are right on all counts. As someone who evaluated and eventually recommended against implementing MongoDB for a new product, I entirely agree with you. The Mongo implementation was shot after about three months of wasted time after failure in pre-production testing. It was rolled back at great cost to SQL Server with a light document-style abstraction as Mongo failed miserably on precisely what you said: reliability, consistency, scalability and storage management. Proper relational databases (PostgreSQL, Oracle, SQL Server in my scope of experience) can take an absolute incredible amount of punishment without breaking any guarantees. The relational bit above is optional but it is at least something you can choose to use or not.

collyw 12y ago

Since the phrase "big data" appeared.