7 ms·

MongoDB 1.0 released

75 points by paulsmith 17y ago

awolf 17y 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 17y ago
  Not officially supported, but someone is working on a C# driver: http://github.com/samus/mongodb-csharp/tree/master http://github.com/samus/mongodb-csharp/tree/master
- tdavis 17y 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 17y ago
  They wrote about MongoDB for logging recently: http://blog.mongodb.org/post/172254834/mongodb-is-fantastic-for-logging 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 http://httpd.apache.org/docs/2.0/logs.html#piped
- jhancock 17y ago
  I'm using it for a new project. I hope it performs well for read-often, write-rarely apps as well.
  - thenduks 17y ago
    So far so good over here :)
anddfej 17y ago
ako mozi odma prajteja
alecco 17y 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 17y 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)
  - alecco 17y 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 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]

75 points by paulsmith 17y ago

awolf 17y 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 17y ago
Not officially supported, but someone is working on a C# driver: http://github.com/samus/mongodb-csharp/tree/master http://github.com/samus/mongodb-csharp/tree/master
tdavis 17y 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 17y ago
They wrote about MongoDB for logging recently: http://blog.mongodb.org/post/172254834/mongodb-is-fantastic-for-logging 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 http://httpd.apache.org/docs/2.0/logs.html#piped
jhancock 17y ago
I'm using it for a new project. I hope it performs well for read-often, write-rarely apps as well.
- thenduks 17y ago
  So far so good over here :)

anddfej 17y ago

ako mozi odma prajteja

alecco 17y 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 17y 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)
- alecco 17y 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 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]