12 Months with MongoDB
blog.wordnik.com
12 Months with MongoDB
1–10 of 75 posts
Re: 12 Months with MongoDB
#2Great writeup! Couple questions:
- I'm curious why querying before a write makes such a big difference. I would have guessed that updating a document that's not in RAM would first load it into RAM, then perform the update. Does the write get applied to disk without loading the page into RAM first? If you do an update to a document that is not in RAM, is it in RAM following the update?
- Can you elaborate on the corruption that occurred to both the master & the slave during a DAS failure? We have seen something similar in our deployment (high write volume leading to corruption in both master & slave. required repair to recover. ran on a partially functioning slave during the repair), but were unable to identify the root cause.
Re: 12 Months with MongoDB
#3Where are the "MongoDB is Web Scale" jokes? crickets. If you are not using MongoDB, you are missing out badly and are probably developing at a much slower rate than someone who is.
Re: 12 Months with MongoDB
#4Where are the "MongoDB is Web Scale" jokes? crickets. If you are not using MongoDB, you are missing out badly and are probably developing at a much slower rate than someone who is.
MongoDB is web scale. No downvotes this time, please!
Re: 12 Months with MongoDB
#5Where are the "MongoDB is Web Scale" jokes? crickets. If you are not using MongoDB, you are missing out badly and are probably developing at a much slower rate than someone who is.
I think it's a bit short-sighted to assume everyone can use MongoDB if you're dealing with ACID type apps, or anything that deals with money. It's silly to say that they're developing at a much slower rate than someone that is. Use the right tool, or a combination of right tools, for the job.
Re: 12 Months with MongoDB
#6Where are the "MongoDB is Web Scale" jokes? crickets. If you are not using MongoDB, you are missing out badly and are probably developing at a much slower rate than someone who is.
I think it's a bit short-sighted to assume everyone can use MongoDB if you're dealing with ACID type apps, or anything that deals with money. It's silly to say that they're developing at a much slower rate than someone that is. Use the right tool, or a combination of right tools, for the job.
Yes everyone, upvote the strawman argument.
Re: 12 Months with MongoDB
#7It is kind of odd that speed is the main motivation to switch from MySQL. Horizontal scaling is the usually given reason. From what I have seen Mongo achieves most of its speed by not using fsync by default. There were some slides floating around a while ago that showed Postgres at about the same speed by turning off fsync.
Re: 12 Months with MongoDB
#8Where are the "MongoDB is Web Scale" jokes? crickets. If you are not using MongoDB, you are missing out badly and are probably developing at a much slower rate than someone who is.
People probably mistook this for a comment thread on an interesting and informative blog post, not SQL/NOSQL flamewar central.
Re: 12 Months with MongoDB
#9Earlier quoted context omitted.
I think it's a bit short-sighted to assume everyone can use MongoDB if you're dealing with ACID type apps, or anything that deals with money. It's silly to say that they're developing at a much slower rate than someone that is. Use the right tool, or a combination of right tools, for the job.
Yes everyone, upvote the strawman argument.
Why is it wrong to upvote the argument that says "use the tool that suits the job"? MongoDB fits some use cases really well, and even then we're still learning how to use it (read the post about the problems they had and how they fixed them). It's basically like any other database: it's good for some things, not so good for others, and when you use, learn it like you would learn any other part of your technology stack.
Re: 12 Months with MongoDB
#10Earlier quoted context omitted.
I think it's a bit short-sighted to assume everyone can use MongoDB if you're dealing with ACID type apps, or anything that deals with money. It's silly to say that they're developing at a much slower rate than someone that is. Use the right tool, or a combination of right tools, for the job.
Yes everyone, upvote the strawman argument.
> Why is it wrong to upvote the argument that says "use the tool that suits the job"?
1) Because it's a strawman argument.
2) Because the reply addresses a very small subset of apps, which 10gen specifically says is not recommended for use with MongoDB.
My point is simply that you gain productivity and Mongo tends to get a lot of hate on HN. My time is limited. For 90% of use cases, I am going Mongo.