Mongo: Mr Right... or Mr Right Now?
blog.scripted.com
Mongo: Mr Right... or Mr Right Now?
1–10 of 13 posts
Re: Mongo: Mr Right... or Mr Right Now?
#2Anyone else have a good story about Mongo as a speccing tool (as opposed to a long term solution)?
Re: Mongo: Mr Right... or Mr Right Now?
#3Anyone else have a good story about Mongo as a speccing tool (as opposed to a long term solution)?
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:
Re: Mongo: Mr Right... or Mr Right Now?
#4I 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.
Re: Mongo: Mr Right... or Mr Right Now?
#5I 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.
Re: Mongo: Mr Right... or Mr Right Now?
#6I 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 m…
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).
Re: Mongo: Mr Right... or Mr Right Now?
#7Anyone else have a good story about Mongo as a speccing tool (as opposed to a long term solution)?
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/
Wait, you found it too difficult and time-consuming to install software, so instead you wrote software?
Re: Mongo: Mr Right... or Mr Right Now?
#8I 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 m…
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 pr…
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.
Re: Mongo: Mr Right... or Mr Right Now?
#9Earlier quoted context omitted.
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 pr…
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.
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.
Re: Mongo: Mr Right... or Mr Right Now?
#10Earlier quoted context omitted.
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.
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.
That makes me willing to consider subjecting a test environment to abuse to see if it loses data so as to consider it for production use, but only if I had a compelling use case for it.