31–40 of 123 posts
This is kind of a strange list of complaints. MongoDB memory management is a legitimate concern... but not because it's hard to control memory usage of a single mongod. "More granular locking" is a temporary, non-scalable solution? I've run out of energy, actually, but really?
Earlier quoted context omitted.
Agreed. I found the mapreduce criticisms to be a little off: > Now instead of fixing a bad implementation or fixing the underlaying architectural issues, MongoDB is moving to Hadoop. I don't think that's accurate. They have a new "aggregation framework" coming that is meant to replace mapreduce. It could be a wrapper around hadoop, but I couldn't find anything documented about that. I completely agree that a blocking…
I don't believe RavenDB blocks. Instead, it returns the results along with a flag to indicate if any of the source data may have been modified while the operation was running.
So what is the new solution? Back to relational? Or another type of document store?
That said, a competently engineered RDBMS can do everything NoSQL databases can, particularly limited databases like MongoDB. The caveat is that you have to learn how to use those databases; they are very feature rich and powerful but that flexibility makes them more complicated. PostgreSQL is a very good choice from the open source world and is just as fast as NoSQL du jour in the hands of someone that knows it.
I currently design extreme-scale real-time analytical database engines, so I have no vested interest in any particular solution (we are not really competing with the current market). If I was going to build a large-scale web app today and needed a backing database, I would go with PostgreSQL -- it is very capable and well-engineered.
Actually, using mmap-ed files is a great idea. It's precisely what Varnish does too.
However, I do feel there is something "wrong" about the approach MongoDB is taking. They need to allocate new files in huge buffers, which completely take up all I/O while being filled with zeroes. There is no logical hierarchy in the files, and it just feels a bit weird.
Perhaps they should've taken the approach PostgreSQL did, which is to simply use files and read from them instead of using mmap. The whole reason they went for a global lock instead of more granular lock is because the whole mmap'ed area is one big blob, and it was the most "obvious" approach.
Earlier quoted context omitted.
Give PostgreSQL a shot if you're still considering databases.
I love Postgres, but I'm building something for OSS use and most unzip-and-deploy devs don't know how to set up Postgres. Any additional information that you might be able to give me that might convince me?
Any more details about the project, or is it under wraps?
There is no single way to control the memory usage using system tools except maintaining mongod instances on dedicated virtual machines without running further services. There are numerous complaints from people about this stupid architectural decision from various side and 10gen is doing nothing to change this brain-dead memory model. Can someone explain to me why this is actually a big issue? Except for really tiny…
I was wondering the same. It's pretty standard for databases to not be very good about sharing with others, memory-wise. That's why having a dedicated server is such a popular best practice for non-puny applications. And MongoDB says it's not designed for puny applications right there in its name.
We run both large (multi-shard clusters) and small memory (500MB - 2GB) use instances of MongoDB and have no problems.
It would be good to have developers acknowledge that, perhaps, they may not have all the information instead of declaring that something can't be done.
Isn't that true for any database? What point are you trying to make? That a large MySQL deployment can be flawlessly be maintained by people that can "hardly spell their name"?
Actually, using mmap-ed files is a great idea. It's precisely what Varnish does too.
That was exactly what my thoughts were too: letting the OS do all the memory management, caching, is a strategy many great projects use, among which PostgreSQL and Varnish. However, I do feel there is something "wrong" about the approach MongoDB is taking. They need to allocate new files in huge buffers, which completely take up all I/O while being filled with zeroes. There is no logical hierarchy in the files, and i…
Earlier quoted context omitted.
Give PostgreSQL a shot if you're still considering databases.
I love Postgres, but I'm building something for OSS use and most unzip-and-deploy devs don't know how to set up Postgres. Any additional information that you might be able to give me that might convince me?
It sounds pretty powerful and I've been told it is rock solid. That being said, don't buy into the anti-mongo hype so easily either. It's been overstated and for a large portion of the middle-ground on scalability and performance mongo is great.
Actually, using mmap-ed files is a great idea. It's precisely what Varnish does too.
mmap() is a good way of doing things but for different reasons than some people assume. Like all tools, you have to learn how to use it well.