Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MongoDB 1.8 (stable) released

blog.mongodb.org

Post reply on HN
Print view View original

11–20 of 69 posts

Re: MongoDB 1.8 (stable) released

#11

Post by yawniek »

davidw wrote: post #9

MongoDB is not something I have a good handle on yet. What's its sweet spot? Where should I consider using it instead of Postgres?

some of the sweet spots where it _might_ be better in than postgres are:

- horizontal scalability

- flexible datastructures

- map/reduce

Re: MongoDB 1.8 (stable) released

#13

Post by mathias_10gen »

rbranson wrote: post #2

Starting to get excited once again about MongoDB. I was kind of down about it after having some issues with real world implementations. Considering journaling is something I would never have thought would have made it in, I wonder if they will come around on the memory mapped I/O like everyone else eventually does. EDIT: Also... does the group commit mean that ALL write transactions will be un-acknowledged to the cli…

Clients are able to wait for the next group commit by adding fsync:true to getLastError calls (some drivers allow you to add this to WriteConcern). We already have some enhancements to this planned for the 1.9 series.

Re: MongoDB 1.8 (stable) released

#14

Post by dmytton »

rbranson wrote: post #2

Starting to get excited once again about MongoDB. I was kind of down about it after having some issues with real world implementations. Considering journaling is something I would never have thought would have made it in, I wonder if they will come around on the memory mapped I/O like everyone else eventually does. EDIT: Also... does the group commit mean that ALL write transactions will be un-acknowledged to the cli…

"You can wait for group commit acknowledgement with the getLastError command. When running with --journal, the fsync:true option returns after the data is physically written to the journal (rather than actually fsync'ing all the data files). Note that the group commit interval (see above) is considerable: you may prefer to call getLastError without fsync, or with a w: parameter instead with replication. In releases after 1.8.0 the delay for commit acknowledgement will be shorter."

http://www.mongodb.org/display/DOCS/Journaling

Re: MongoDB 1.8 (stable) released

#15

Post by kchodorow »

davidw wrote: post #9

MongoDB is not something I have a good handle on yet. What's its sweet spot? Where should I consider using it instead of Postgres?

A lot of people like it because it makes development faster. It's like the scripting language of databases: you can get stuff out the door really fast (with the obvious power/responsibility caveats).

Re: MongoDB 1.8 (stable) released

#16

Post by andrewjshults »

davidw wrote: post #9

MongoDB is not something I have a good handle on yet. What's its sweet spot? Where should I consider using it instead of Postgres?

If you are working with location data, Mongo has built in geospatial indexing built in since 1.4 (earlier in the unstable builds) - http://www.mongodb.org/display/DOCS/Geospatial+Indexing which has been a big draw for a number of people I know using it (it looks like 1.8 brings spherical distances to the stable branch which makes the geo lookups a lot more useful if you need accurate distances and not just near by lookups).

Re: MongoDB 1.8 (stable) released

#17

Post by rch »

dacort wrote: post #10
rch wrote: post #7

This is exciting: db.users.mapReduce(map, reduce, {out: { inline : 1}}); This is Not exciting: "Note that this option is possible only when the result set fits within the 16MB limit of a single document."

Not really a big deal to just output to a new collection and query that.

Sure - I'm just pointing out something that could be a big deal (streaming results through an ordered structure in memory, that may or may not be backed by a lazy disk store) is actually not a big deal, due to a current implementation constraint.

But you're right too, of course.

Re: MongoDB 1.8 (stable) released

#18

Post by DonnyV »

kchodorow wrote: post #15
davidw wrote: post #9

MongoDB is not something I have a good handle on yet. What's its sweet spot? Where should I consider using it instead of Postgres?

A lot of people like it because it makes development faster. It's like the scripting language of databases: you can get stuff out the door really fast (with the obvious power/responsibility caveats).

This was the main reason why I picked it for a project. Its just sick the amount of code you DON'T have to write to use this database. I literally have 1 class called GenericCRUD with 5 functions that do all my database functions for all my models. Plus not having to worry about stored procedures anymore is a heavy weight lifted off your shoulders.

Re: MongoDB 1.8 (stable) released

#19

Post by rit »

rch wrote: post #7

This is exciting: db.users.mapReduce(map, reduce, {out: { inline : 1}}); This is Not exciting: "Note that this option is possible only when the result set fits within the 16MB limit of a single document."

I did a writeup, for what it's worth, on the new MapReduce output options:

http://blog.evilmonkeylabs.com/2011/01/27/MongoDB-1_8-MapRed...

(Disclaimer, I work for 10gen / MongoDB)

Re: MongoDB 1.8 (stable) released

#20

Post by igrekel »

andrewjshults wrote: post #16
davidw wrote: post #9

MongoDB is not something I have a good handle on yet. What's its sweet spot? Where should I consider using it instead of Postgres?

If you are working with location data, Mongo has built in geospatial indexing built in since 1.4 (earlier in the unstable builds) - http://www.mongodb.org/display/DOCS/Geospatial+Indexing which has been a big draw for a number of people I know using it (it looks like 1.8 brings spherical distances to the stable branch which makes the geo lookups a lot more useful if you need accurate distances and not just near by lo…

Interesting I was planning to toy with location data, do you know how it compares with Postgresql extension PostGIS?
Post reply on HN