MongoDB 1.0 released

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

by paulsmith • 17 years ago

75 10 17 years ago

blog.mongodb.org

awolf• 17 years ago

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.

felixmar• 17 years ago

Not officially supported, but someone is working on a C# driver: http://github.com/samus/mongodb-csharp/tree/master

tdavis• 17 years ago

no brainer for write-often read-rarely types of applications (logging, metrics

I'll probably be re-writing some logging functionality in it, actually. I love asynchronous operations. AKA, "YAY! NEW TOYS!"

simonw• 17 years ago

They wrote about MongoDB for logging recently: http://blog.mongodb.org/post/172254834/mongodb-is-fantastic-... - capped collections sound ideal for short lived logs.

It would be interesting to write a command line script for piping Apache logs in to MongoDB, using Apache's "piped logs" feature: http://httpd.apache.org/docs/2.0/logs.html#piped

jhancock• 17 years ago

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

thenduks• 17 years ago

So far so good over here :)

alecco2• 17 years ago

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• 17 years ago

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)

alecco2• 17 years ago

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]

wheels• 17 years ago

Nitpick:

> and with os file caches, it'll cache the 4k anyway

Usually in a high-end database direct I/O is used on Linux.

MongoDB 1.0 released

Related Stories