21–30 of 280 posts
Every single MongoDB step has had the old timers groaning.
Even with something solid like Tokutek's storage engine in it, its going to be a hard sell.
He's right that MongoDB could use improvements like string interning so you don't need to worry about field names. But overall, I think this article is very misleading. If you use MongoDB in production, you should definitely take he time to learn about the durability options on the database side AND in your driver. By using them appropriately, you can have as little or as much as you like. Data sets larger than 100GB…
For what use cases is Mongo the right tool?
Earlier quoted context omitted.
For what use cases is Mongo the right tool?
It's "a" right tool in any case where distributed storage of unstructured data in JSON format is wanted, where database-level locks won't be an issue of concern, and availability is the primary, overriding concern.
Earlier quoted context omitted.
> None of how MongoDB works is a secret. Maybe not now, but this hasn't always been the case. The fact that they had (have?) a global write lock was completely buried on the doc site for ages. Benchmarks were waved in front of developer's faces to distract them from the "drivers don't actually write data, they just blast it out in every direction and hope it lands somewhere good" BS. I don't use Mongo anymore, and I…
That's all true, but they were giving 90% of their users exactly what they wanted: "We value feature-set and expressiveness much more than scalability at our data size, but we want to feel like we're big data too so say some of that stuff" And that's their brilliance, they listened to what people said they wanted and then gave them what they really wanted.
The fact remains that Mongo just doesn't scale, and 10gen was never honest about that.
He's right that MongoDB could use improvements like string interning so you don't need to worry about field names. But overall, I think this article is very misleading. If you use MongoDB in production, you should definitely take he time to learn about the durability options on the database side AND in your driver. By using them appropriately, you can have as little or as much as you like. Data sets larger than 100GB…
For what use cases is Mongo the right tool?
I also use it as a metadata "scratch space" for highly available applications (things where failures are not acceptable and must run for days at a time). Again, with replication and automatic fail overs, I've been able to maintain 100% uptime outside of maintenance windows. Obviously that can't last, but so far it's been >2 years with no major problems.
EDIT: I should point out that although the size of the metadata objects can be highly variable, since I usually had a small number of them relative to the time series, fragmentation was still not an issue.
He's right that MongoDB could use improvements like string interning so you don't need to worry about field names. But overall, I think this article is very misleading. If you use MongoDB in production, you should definitely take he time to learn about the durability options on the database side AND in your driver. By using them appropriately, you can have as little or as much as you like. Data sets larger than 100GB…
For what use cases is Mongo the right tool?
You want a fixed-size, rolling backlog of time series data such as logs.
Earlier quoted context omitted.
It's "a" right tool in any case where distributed storage of unstructured data in JSON format is wanted, where database-level locks won't be an issue of concern, and availability is the primary, overriding concern.
I'd submit that database-level locks make any claims of availability or distributed storage a little overblown. If a single query can blow you out of the water, you're really not highly available. Although I don't have a lot of experience doing big mongodb personally, so maybe I'm missing something.
If you hit a db level lock limit, you're probably running a sub-optimal or unindexed query.
> MongoDB is easy to make fun of. I think more often its easy to poke fun at _how_ its used. When any tool or tech is used globally, before knowing its limitations, problems are likely. Attempting to use MongoDB in all storage or persistence scenarios is no more sensible than using MySQL in all cases. Yes, there is marketing around this product that must be looked at critically - after taking into account that many n…
Substantially less sensible in many cases. MySQL has its issues (it has a lot of issues), but people have been able to get it to work surprisingly well in roles that it wasn't designed for (albeit sometimes by just building a database on top of it, as with Twitter's thing).