4 ms·

Mongo: Mr Right... or Mr Right Now?

15 points by jbkring 14y ago

jbkring 14y ago
Anyone else have a good story about Mongo as a speccing tool (as opposed to a long term solution)?
- StavrosK 14y ago
  I did need a schemaless store for a project I was prototyping, but then I didn't see why I had to install MongoDB just to get a simple schemaless store. So, I wrote Goatfish: https://github.com/stochastic-technologies/goatfish/ https://github.com/stochastic-technologies/goatfish/
  - bravura 14y ago
    Wait, you found it too difficult and time-consuming to install software, so instead you wrote software?
    - kennywinker 14y ago
      I think he mains maintaining a mongodb installation, which is not trivial. Same reason people use SQLite instead of MySQL or Postgres. Don't want to have to deal with keeping a database server up.
      - StavrosK 14y ago
        Exactly. This way, I get my schemaless datastore without leaving the stdlib, and it doesn't eat my data at unsuspecting times.
stuffihavemade 14y ago
I don't understand how writing migrations takes "weeks (if not months)". I can see "hours (if not days)". But, you still have a schema and migrations, they just exist in the application layer instead without a clear upgrade path.
- jbkring 14y ago
  I think you're underestimating just how many times I rethought my schema and refactored my models :)
Zak 14y ago
I had Mongo lose data. The box it was hosted on was shut down (possibly uncleanly), and when it came back up, mongod refused to start. I ran mongod --repair and ended up with a running system, but the data was mangled. There were parts of records inside other records and a large amount of data that I just couldn't find. Fortunately, most of it was backed up elsewhere. I've been told that maybe some other version is more reliable. I've been told I need to configure it properly by hand before I use it. I don't care. This was a trivial single-machine installation and there is one thing any sane database absolutely must do: avoid completely losing all the data that has been stored in it.
- dmytton 14y ago
  What version was this? 2.0 (which has been out almost a year) has journaling enabled by default which almost always provides complete single server durability for these situations. Any database can suffer corruption if you shut down the server uncleanly - it depends on the state of the filesystem when it comes back up. That's why you have replication to protect against failure of a single node. Having run Mongo in production for over 3 years, I've never lost any data despite numerous failure scenarios (including unclean shutdown).
  - Zak 14y ago
    I believe it was 1.8. I know it wasn't a high-reliability configuration, and it could be that an unclean shutdown was to blame. I do not claim to know objectively how reliable MongoDB is. I am, however very hesitant to rely on it for anything now, much as I would be hesitant to touch a machine that previously gave me a severe electric shock even though its creator and other users assure me it's safe now.
    - JustinJ70s 14y ago
      I can tell you now that it's extremely reliable - we store a lot of data in our mongodb - several million documents a day. As mentioned, it would be because journalling wasn't enabled which would mean possible corruption on non-clean shutdown. That's history.

15 points by jbkring 14y ago

jbkring 14y ago

Anyone else have a good story about Mongo as a speccing tool (as opposed to a long term solution)?

StavrosK 14y ago
I did need a schemaless store for a project I was prototyping, but then I didn't see why I had to install MongoDB just to get a simple schemaless store. So, I wrote Goatfish: https://github.com/stochastic-technologies/goatfish/ https://github.com/stochastic-technologies/goatfish/
- bravura 14y ago
  Wait, you found it too difficult and time-consuming to install software, so instead you wrote software?
  - kennywinker 14y ago
    I think he mains maintaining a mongodb installation, which is not trivial. Same reason people use SQLite instead of MySQL or Postgres. Don't want to have to deal with keeping a database server up.
    - StavrosK 14y ago
      Exactly. This way, I get my schemaless datastore without leaving the stdlib, and it doesn't eat my data at unsuspecting times.

stuffihavemade 14y ago

I don't understand how writing migrations takes "weeks (if not months)". I can see "hours (if not days)". But, you still have a schema and migrations, they just exist in the application layer instead without a clear upgrade path.

jbkring 14y ago
I think you're underestimating just how many times I rethought my schema and refactored my models :)

Zak 14y ago

I had Mongo lose data. The box it was hosted on was shut down (possibly uncleanly), and when it came back up, mongod refused to start. I ran mongod --repair and ended up with a running system, but the data was mangled. There were parts of records inside other records and a large amount of data that I just couldn't find. Fortunately, most of it was backed up elsewhere. I've been told that maybe some other version is more reliable. I've been told I need to configure it properly by hand before I use it. I don't care. This was a trivial single-machine installation and there is one thing any sane database absolutely must do: avoid completely losing all the data that has been stored in it.

dmytton 14y ago
What version was this? 2.0 (which has been out almost a year) has journaling enabled by default which almost always provides complete single server durability for these situations. Any database can suffer corruption if you shut down the server uncleanly - it depends on the state of the filesystem when it comes back up. That's why you have replication to protect against failure of a single node. Having run Mongo in production for over 3 years, I've never lost any data despite numerous failure scenarios (including unclean shutdown).
- Zak 14y ago
  I believe it was 1.8. I know it wasn't a high-reliability configuration, and it could be that an unclean shutdown was to blame. I do not claim to know objectively how reliable MongoDB is. I am, however very hesitant to rely on it for anything now, much as I would be hesitant to touch a machine that previously gave me a severe electric shock even though its creator and other users assure me it's safe now.
  - JustinJ70s 14y ago
    I can tell you now that it's extremely reliable - we store a lot of data in our mongodb - several million documents a day. As mentioned, it would be because journalling wasn't enabled which would mean possible corruption on non-clean shutdown. That's history.