51–60 of 123 posts
I know nothing about MongoDB and have never tried it. But the message seems pretty clear.
But.. but.. MongoDB is web-scale: http://www.youtube.com/watch?v=b2F-DItXtZs (Note how the video raises some of the same concerns as the blog post)
I feel like 1 - 2 years ago I was reading a slew of blog posts with the title "Why We Chose MongoDB." Now it seems like all of the blog posts are some sort of "We Just Finished Migrating off of MongoDB, Here's Why." I know nothing about MongoDB and have never tried it. But the message seems pretty clear.
Kind of a bummer.
Actually, using mmap-ed files is a great idea. It's precisely what Varnish does too.
Yes, using mmap is a good idea and not because it is easy. The problem is that mmap-ing is simple, so a lot of first-time database engine developers use it, but a naive usage of mmap is a recipe for poor operational behavior. A competent database engine that fully leverages mmap is actually pretty complicated internally. Things like managing write back scheduling behavior are important. mmap() is a good way of doing…
The old-school DBA in me immediately thinks that the "70's tech" of the RDBMS is still widely used because the time to develop sufficient memory management is hard work and takes time.
I feel like 1 - 2 years ago I was reading a slew of blog posts with the title "Why We Chose MongoDB." Now it seems like all of the blog posts are some sort of "We Just Finished Migrating off of MongoDB, Here's Why." I know nothing about MongoDB and have never tried it. But the message seems pretty clear.
I think a lot of people switched to it because it was cool, and maybe assumed that it could solve any application data storage problem and are now finding out that it may not have been a great choice for them.
I don't think its appropriate to take away from this that MongoDB and/or other document stores are bad. Instead, I think its important to understand how they work and decide how well it applies to your use case. It's not going to work well for all applications.
Hell yeah. From what I've seen of MongoDB I'm not impressed at all. In some carefully controlled cases, performance would be acceptable, but change anything at all (even the order that data is inserted) and it just sucks. For one particular application, the performance difference between MySQL and Mongo was like the difference between the Space Shuttle and a Chevy Sonic.
I've launched very high traffic websites using MongoDB, where it was the least of my worries. I've also launched very high traffic websites using MySQL, where it was my primary source of pain.
Shall I now run around screaming loudly about how badly MySQL sucks? On the surface you might assume so, but with reasonable effort to consider all the facts, it becomes clear that there's more to this than just "this database is better than that one because I hate it."
This post is more of an angry payback rant from someone who got banned from IRC for being abusive to newcomers and greenies. On top of that, it is factually incorrect in some spots, and misleading in others. Not impressed.
That said, NoSQL databases are evolving extremely quickly, and have reached a point of maturity that they can excel in the right scenario. Just like relational databases, they can provide big benefits, given that the user takes the time to learn how to use them, as well as making sure they have a use case that merits the strengths of their chosen tech.
I really enjoy working with MongoDB and Redis, and have been a community cheerleader of sorts for PostgreSQL for years. It is possible to have multiple tools in your toolbox, and use them when appropriate. No tool is perfect, and no tool is perfect for every job.
Complaining bitterly that your shiny new piano makes a lousy boat, on the other hand, simply adds to the noise.
So what is the new solution? Back to relational? Or another type of document store?
MongoDB is fine at the conceptual level. The problem is that the architecture and implementation are consistently poor in myriad ways. It is a case study of what can happen when well-meaning individuals with little experience in database architecture and implementation attempt to build a scalable database engine. That said, a competently engineered RDBMS can do everything NoSQL databases can, particularly limited dat…
FTFY.
The difference between using a good competently engineered distributed database and PostgreSQL is that when your prime concerns are horizontal scaling and operations costs, the distributed database can be an order of magnitude simpler and faster than PostgreSQL given the same amount of effort.
"My essage to companies building applications on top of MongoDB: assigned smart people to MongoDB and don't leave the database work to people that can hardly spell their name or that can just count to three. Yes, this paragraph is harsh and does not comply with diversity but it is true and reality. The number of people that should not do any database related work, people without reasonable background, people lacking…