First off, sorry if it reads overly negative. The reason for my post was I got sucked into the hype around the project and ended up wasting a few days for something that didn't work out. It's not the MongoDB team's fault, of course. But I started to read comments here without any counter-balance. > At least on my 64-bit linux box, mmap page size is 4k. So if you have to read
> 100 bytes vs 4k, in the end I don't think its a big difference. From the
> drives point of view, 100 bytes and 4k are basically the same, and with os file
> caches, it'll cache the 4k anyway most likely
I beg to differ. 4k is 40 times 100 bytes and that's a lot. I could understand a 512 byte sector cache but not full 8 sectors per every disk read. Especially for metadata. > The JavaScript support is very optional (only db.eval and $where). When it used
> it uses very little memory because nothing is really stored in it. Its
> basically processing 1 record at a time and we've written a very efficient
> wrapper.
My bad. I'm very wrong on this point, then. > Also, v8 actually just released a 64-bit version, so we may look into
> switching back to that as well if it turns out to be a lot faster than
> trace monkey.
Yes, and V8 will probably come soon in other architectures, too. This sounds good.BTW, I couldn't find a stable release of Spidermonkey with Tracemonkey. But it could be my fault entirely. > Why do you think its green and small? Its actually been used in production
> for over 18 months (www.businessinsider.com for example)
It's just a personal impression based on who is using it (http://www.mongodb.org/display/DOCS/Production+Deployments) and recent bugs. Requiring 64-bit mode for files over 3.3-4GB is a bit strange for a database.Again, I think it has all the potential and has a fantastic team. And maybe a bit of hard testing and some presentations could dispel [my opinion on] memory usage. As I said in my previous comment, take my opinion with a grain of salt! [Edit: formatting, little rephrasing] |