

MongoDB 1.8 (stable) released - luigi
http://blog.mongodb.org/post/3903149313/mongodb-1-8-released

======
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?

~~~
joelhaasnoot
Don't know, I'm going to be testing this tomorrow, but came to work today to a
server that was grinding to a halt due to wild running node.js processes.
Restarted the server, but that doesn't cleanly shutdown Mongo, and spent an
hour repairing everything and setting permissions right (somehow they had
gotten reset). This exact problem, so hope the --journal switch in the init
file makes the difference.

~~~
joelhaasnoot
Added "journal = true" to the config and it certainly stops and starts the
service nicely now. No more repairs and such, my data is currently query only,
so it's mainly "optical", cleaning up locks and such.

------
rb2k_
Can't wait until they start implementing filtered indexes (
<http://jira.mongodb.org/browse/SERVER-785> ). Sparse indexes are a step in
the right direction, but filtered ones would be just a bit cooler :)

"New map/reduce options for incremental updates" would also be really cool if
they had a way to do something like couchDBs incremental views. This would
require keeping track of changes or a "trigger" functionality that runs the
m/r task after every x inserts

------
rbranson
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 client until the group commit finishes?

~~~
dmytton
"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>

~~~
rbranson
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.

------
davidw
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?

~~~
andrewjshults
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).

~~~
crux_
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.

~~~
gt384u
Why not go ahead and help them? I'm sure they'd be happy to have the
assistance. Fork mongo from github at <https://github.com/mongodb/mongo> .
Happy hacking!

~~~
crux_
You know, nobody ever replies to these comments with an "I will", but I'm
seriously considering it.

(It's a nice opportunity to publicly show off a specialty/core competency and
brush up a bit on C++ a the same time. I'm not that easily provoked into
action by internet commentary! ;) )

But, looking at the source, I think I will be probably a Bad Contributor and
end up with a gigantic pull request and a (mostly) full re-implementation...

------
rch
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."

~~~
rit
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...](http://blog.evilmonkeylabs.com/2011/01/27/MongoDB-1_8-MapReduce/)

(Disclaimer, I work for 10gen / MongoDB)

~~~
rch
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.

------
mike_esspe
Warning for those, who want to use MongoDB on FreeBSD: there is a known,
unfixed bug, which locks database a lot:

[http://groups.google.com/group/mongodb-
user/browse_thread/th...](http://groups.google.com/group/mongodb-
user/browse_thread/thread/95f9386cd57003e4)

<http://jira.mongodb.org/browse/SERVER-663>

------
emef
I was really hoping for full-text search support, but I understand the team is
busy :/

~~~
rabidsnail
All you need for full-text search is to add a multikey of tokens to the
documents you want indexed. Tokenizers and stemmers are actually really easy
to write, and there are libraries you can use to do that for you.

------
phsr
As a newb to non-relational databases, but planning on learning one soon, what
is the advantage of MongoDB vs Redis? I'm planning to use ruby with either,
but was interested if there was a reason to pick one over the other.

~~~
A1kmm
I don't think you should just learn one; they are all used for different
niches. It depends how your app trades off different things (consistency,
reliability of reads, reliability of writes, speed of reads, speed of writes,
efficiency of hardware use, and so on).

See <http://news.ycombinator.com/item?id=2052852> for a comparison.

~~~
phsr
I'm not planning on just learning one, just trying to pick one to learn
_first_

------
eldenbishop
Wow. I knew about the durability changes but I had no idea that sparse and
covered indexes where coming. These three changes where the biggest drawbacks
to mongo for me.

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

~~~
rb2k_
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...](http://jira.mongodb.org/browse/SERVER?report=com.atlassian.jira.plugin.system.project:changelog-
panel) )

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

------
vegai
The clustrix guy criticized mongodb that it locks the whole database quite
often. Can anyone confirm or deny that?

~~~
vegai
Modded to 0 and never answered. I'll take that as a confirmation.

------
gaius
But is it web scale?

~~~
mrinterweb
I got in so much trouble for a very similar web scale comment. Never shall
trite jokes be used on hacker news. You'll get your head bit off. Personally,
it gives me a giggle, and I guess that means I am much less mature than most
consumers of Hacker News. <http://news.ycombinator.com/item?id=2104276>

~~~
kchodorow
I think it's just an old joke at this point. It's funny the first time you see
it and the second time, but the 50th?

~~~
mrinterweb
I did admit the joke is trite.

