

MongoDB 1.0 released - paulsmith
http://blog.mongodb.org/post/173107215/1-0-ga-released

======
awolf
This is a great project.

Anyone who is looking for an alternate to SQL should check MongoDB out. Now
that they have reached a stable milestone it seems like a no brainer for
write-often read-rarely types of applications (logging, metrics). It's
lightning fast.

Setup is a breeze now that they have distributable packages for
Mac/Linux/Windows in both 32 and 64 bit versions available.

I do wish they would create an officially supported C# driver. I think it
would really give their adoption rate a boost.

~~~
jhancock
I'm using it for a new project. I hope it performs well for read-often, write-
rarely apps as well.

~~~
thenduks
So far so good over here :)

------
alecco
They have very good goals but their new approach to have database files
memory-mapped gave me the chills.

Ups:

    
    
      * No in-process cache required.
      * Very clean design.
    

Downs:

    
    
      * Every read from disk would bring a lot more data than required.
      * 64-bit process required to support large files.
        * Since they use a JavaScript VM this would consume 40-60% more memory
          because of double pointer size.
        * V8 is x86 only so they switched to SpiderMonkey
          (slower, even with upcomming tracing.)
    

The project looks very promising and the developers are top-notch but IMHO
it's very green and small for my project. Maybe the next major release will be
a killer.

I am not any kind of authority in this area so please take this comment with a
grain of salt.

~~~
ehwizard
Just some thoughts on your downs (i'm a dev, so opinionated in 1 direction :)
)

* 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

* 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. 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.

Why do you think its green and small? Its actually been used in production for
over 18 months (www.businessinsider.com for example)

~~~
alecco
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]

