Earlier quoted context omitted.
I don't understand how you would switch from mongodb to redis. They don't do the same thing, at all.
I think your second sentence answered your first.
Goodbye, MongoDB
121–123 of 123 posts
Re: Goodbye, MongoDB
#122Earlier quoted context omitted.
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…
Thanks for the insight on the global write lock. I've searched and searched and wasn't able to find anything on why they have the global lock. Out of curiosity, is there a simple way to explain why someone would mmap instead of just reading files directly (I've never done any programming with mmap, so I'm a bit ignorant of its use cases)?
Re: Goodbye, MongoDB
#123> Leaving memory management to the operating is nice idea - in reality it does not scale and does not play very well. This is why I think that Linus's tirade against O_DIRECT is misguided: https://lkml.org/lkml/2007/1/10/233 Here's the thing: the kernel is a library. It took me a long time to fully understand this deep idea. The kernel is just a library that has a different and more expensive calling convention (sysc…
This is why most DBMS products do their own memory management. They just suck up as much memory as you will allow and use it for their own devices. Specialized, tunable, application-level memory management will probably always beat a general-purpose, application-ignorant OS-based scheme. But, there's something to be said for the simplicity - for most folks you don't need to manage the memory yourself. When you need i…