A New Perspective on MongoDB(dirolf.com)
dirolf.com
A New Perspective on MongoDB
http://dirolf.com/2011/03/28/new-perspective-on-mongodb.html
2 comments
We've been pretty happy with the scalability of Mongo where we use it for RowFeeder. We've got over 1 billion documents over several terabytes. The main challenge we encounter is our indexes are much larger than RAM, but given that we index by date this isn't a huge problem. Inserts are still very fast and only slow down if we have to load old data. 1.8's ability to distribute reads to replica slaves will help with this a lot, though.
Exactly. The option of scaling out later is great, but the huge benefits for early stage projects are flexibility and ease of use.
These are the reasons I've really enjoyed playing around with it. Unfortunately I tend to get distracted with many of my toy projects, and so little ever gets seen by anyone. But so far, with Mongo, I don't tend to get as bogged down with data modeling. That means that I usually get further into it before life takes me away.
I have no idea how well it would scale if I did build something that ended up being a success - but it's a risk I'm happy to take if (due to my own personal quirks :), it increases that chances that something that I build ends up being a success.
I have no idea how well it would scale if I did build something that ended up being a success - but it's a risk I'm happy to take if (due to my own personal quirks :), it increases that chances that something that I build ends up being a success.
What about data persistence? Is it still enforced only through replication?
I really liked MongoDB's philosophy but this was the show stopper for me when I was exploring it. At least for some services I need to be certain that if the DB says it stored some data that really stored and not kept in volatile memory until it decides it's the right time to write them to disk.
It's been a while since I looked at it though, and that may no longer be the case. Are there any improvements in this area?
I really liked MongoDB's philosophy but this was the show stopper for me when I was exploring it. At least for some services I need to be certain that if the DB says it stored some data that really stored and not kept in volatile memory until it decides it's the right time to write them to disk.
It's been a while since I looked at it though, and that may no longer be the case. Are there any improvements in this area?
1.8 has single server durability, but TBH I haven't had a chance to check it out in depth yet.
I've looked at mongodb for one particular application and it's currently uneconomic for my particular situation on Amazon EC2.
I've got a lot of data but a relatively light workload. One m1.large w/ mysql handles the workload easily, to fit two copies of everything in RAM with mongo I estimate I'd be paying four times as much.
Now, if I had more traffic, there's a crossover where mongodb is probably cheaper but the system I've got ought to scale affordably to the point where I'll have enough money for the next thing if I need it.
I've got a lot of data but a relatively light workload. One m1.large w/ mysql handles the workload easily, to fit two copies of everything in RAM with mongo I estimate I'd be paying four times as much.
Now, if I had more traffic, there's a crossover where mongodb is probably cheaper but the system I've got ought to scale affordably to the point where I'll have enough money for the next thing if I need it.
- it's super flexible (and schema-less)
- dynamic queries are fast and powerful
- it's very easy work with
Scalability is another issue, but I think Mongo can scale (and that's slowly and bravely being proven by Foursquare). And almost all startups need to drastically re-architect their datastores when they hit massive scale anyways, so why not start out with the easiest and most flexible option that will let you iterate the fastest?