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

21–30 of 69 posts

Re: MongoDB 1.8 (stable) released

#21

Post by dacort »

rch wrote: post #17
dacort wrote: post #10

Earlier quoted context omitted.

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.

Yea, makes sense. That limit almost seems to fall along the lines of "Nobody should need more than 16MB for inline map/reduce results." ;)

Re: MongoDB 1.8 (stable) released

#22

Post by rbranson »

dmytton wrote: post #14
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 a…

RTFM'ing myself in public. While it's a great step forward, the whole thing sounds pretty immature at this point. It'll be a good day when this stuff matures and MongoDB has fsync:true and --journal by default, much to the chagrin of sensationalists everywhere.

They'll really need to add some major smarts into the journaling and group commit if they're going to be able to stack up concurrent I/Os to help feed big disk arrays and even to get the best use out of SSDs which make back-and-forth latency on the I/O pipes even more significant.

Re: MongoDB 1.8 (stable) released

#24

Post by crux_ »

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…

I got excited and looked it up.

> We don't currently handle wrapping at the poles or at the transition from -180° to +180° longitude, however we detect when a search would wrap and raise an error.

generalized grumble

Why does everyone always seem to punt on doing geospatial right? It's not _that_ hard.

Re: MongoDB 1.8 (stable) released

#25

Post by dm_mongodb »

rb2k_ wrote: post #5
suhail wrote: post #3

yay "Tab completion in the shell" and "B-tree index self-compaction" are great. So is --journal.

Do you happen to know details about the B-tree index self-compaction? I can't seem to find it in their changelog on jira ( http://jira.mongodb.org/browse/SERVER?report=com.atlassian.j... )

consolidation of adjacent btree nodes after key deletions when appropriate. arguably should have already done this, but it's there now!

Re: MongoDB 1.8 (stable) released

#26

Post by rch »

rit wrote: post #19
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)

Very nice - worth the reading. I'm particularly interested in seeing how you've implemented 'merge' and 'reduce' output.

You guys do seem to be headed in the right direction technically... I just can't bring myself to say "mongo" out loud.

Re: MongoDB 1.8 (stable) released

#27

Post by rch »

dacort wrote: post #21
rch wrote: post #17

Earlier quoted context omitted.

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.

Yea, makes sense. That limit almost seems to fall along the lines of "Nobody should need more than 16MB for inline map/reduce results." ;)

cheers to that.

Re: MongoDB 1.8 (stable) released

#28

Post by dstorrs »

Could someone with Mongo experience help me gut-check this?

I want my data store to be durable and unsurprising -- barring a hardware failure or such, if I submit data it should either tell me that it failed to commit or it should be stored durably and without surprises (e.g., it should not truncate a long string to fit).

I've read some of the Mongo docco, and it's pretty exciting, but the lack of ACID -- primarily the Durability -- has kept me from really using it.

With a WAL journal, it sounds like maybe the durability issue is fixed. Is it? Could I use Mongo with relatively out-of-the-box settings plus --journal and count on a level of durability equivalent to a traditional RDBMS?

Re: MongoDB 1.8 (stable) released

#29

Post by crux_ »

igrekel wrote: post #20
andrewjshults wrote: post #16

Earlier quoted context omitted.

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?

If by "location data" you have points, and the only location operations you need are distance or bounding-box searches, it may do the trick.

If you're interested in polygons, lines, etc; more physically accurate (and completely implemented) distance queries, spatial joins, aggregation, 3D and surveyor-annotated data, set-theoretic operations ... PostGIS is far and away the way to go. It's far more mature and debugged than any of the NoSQL geospatial stuff I've seen, not only WRT correctness but also performance.

As a point of reference: There's a growing legion of geographers who do all their vector work in SQL using PostGIS.

All that said, for some applications, being tied to the relational model is a deal breaker. Just know that in terms of capability and maturity on the geospatial front, you'll be trading off a Cadillac for a partially assembled rocket sled.

Re: MongoDB 1.8 (stable) released

#30

Post by runevault »

dstorrs wrote: post #28

Could someone with Mongo experience help me gut-check this? I want my data store to be durable and unsurprising -- barring a hardware failure or such, if I submit data it should either tell me that it failed to commit or it should be stored durably and without surprises (e.g., it should not truncate a long string to fit). I've read some of the Mongo docco, and it's pretty exciting, but the lack of ACID -- primarily t…

My understanding is this release is the first stable with single node durability available as an option, which is why I'm considering picking Mongo back up.
Post reply on HN