
MongoDB 1.6 stable released - pierrefar
http://www.mongodb.org/display/DOCS/1.6+Release+Notes
======
kylemathews
Many people expect MongoDB to be the standard datastore for high-performance
Drupal sites come the Drupal 7 release. See this session at the last
drupalcon: [http://sf2010.drupal.org/conference/sessions/mongodb-
humongo...](http://sf2010.drupal.org/conference/sessions/mongodb-humongous-
drupal)

examiner.com is switching to Drupal soonish and has funded most of the work to
write the Drupal/MongoDB integration.

------
barmstrong
Mongo looks like its emerging as the preferred NoSQL platform on Rails at
least.

As an admittedly rough measure, check out the number of "watchers" on github
for each project's leading plugin:

1106 - MongoMapper <http://github.com/jnunemaker/mongomapper>

536 - CouchREST <http://github.com/jchris/couchrest>

312 - Cassandra <http://github.com/fauna/cassandra>

I've only built one rails app with nosql in it, but at first glance at least
Mongo seemed the most fully baked of the group.

~~~
ruperp
Don't forget:

695 - Mongoid <http://github.com/durran/mongoid>

seems to be the Rails/Mongo project to watch. They got a slick looking
homepage too: <http://mongoid.org>

Hoping to try using it on my next project.

~~~
ekidd
We've used both MongoMapper and Mongoid, and are very happy with Mongoid. It
has nice ActiveModel integration, so it works quite well with Rails 3.

~~~
bkudria
Seconded, using Mongoid over MM here too. It rocks.

------
rb2k_
As soon as they feature document level locking (maybe MVCC), I'll happily use
it. But locking all databases when a write is occurring is a bit of a downer
for large apps that require concurrency.

~~~
masomenos
<http://www.mongodb.org/display/DOCS/Atomic+Operations> says:

"MongoDB supports atomic operations on single documents. MongoDB does not
support traditional locking and complex transactions for a number of reasons.
. ."

What made you think that it was "locking all databases when a write is
occurring"?

~~~
rb2k_
basically what robotadam said (<http://news.ycombinator.com/item?id=1579212>).
To clarify: the database lock is actually for the whole process (-> all
databases). I had an especially bad experience with it before they introduced
the yielding for long running operations. But even with the yielding, write
heavy parallel things still suffer. Especially if your indexes ever get too
big and the the system decides to swap in/out part of the index. I've seen 5-6
second inserts with hundreds of writes and reads piling up in the mean time
(even without the swap part).

If only they had an equivalent of innodb as a storage engine, it would be
awesome

~~~
mjs
This is also pertinent:

[http://www.mongodb.org/display/DOCS/How+does+concurrency+wor...](http://www.mongodb.org/display/DOCS/How+does+concurrency+work)

Note that whilst a write blocks all other writes, the time you need to wait is
the time it takes for the in-memory data structure to be modified; you don't
have to wait for the write to hit disk. (Writes are only persisted to disk
every so often.)

~~~
rb2k_
Unless you actually don't have enough RAM and that data structure has to be
paged in... that's a painfully long wait

------
StavrosK
Nobody seems to like my opinion, but MongoDB kept eating my data regularly and
silently. My writeups are here:

<http://www.korokithakis.net/node/116> <http://www.korokithakis.net/node/119>

I would love to answer questions if I could figure out how to easily see my
replies on HN :/

~~~
steveklabnik
You can see replies by hitting the "threads" link at the top of the page.

Reasons (from my understanding) that you had a bad experience:

    
    
        1. You used a development, unstable version of software in production.
        2. 32 bit Mongo cannot store more than 2GB of data, this is a very public, known admission.
    

The reason that 'nobody seems to like your opinion' is that your post got real
famous, and while mistakes happen, the internet was in a bit of a frenzy at
the time over the whole NoSQL thing, and so you became sort of a poster child
for various sides that people had chosen. Sucks, but it happens. I had a
similar experience with my first blog post ever, so I feel your pain...

~~~
StavrosK
Thanks for the "threads" tip, it's really handy. About your points:

1\. This is true (there was no warning that I saw when I was downloading it,
although one was added later, or maybe I didn't notice it). However, I
upgraded to the stable version when it came out to give MongoDB a second
chance, because it sounds very good in theory, and I had the same (if not
bigger) problems.

2\. I hadn't known about it, and, no matter how pubilc it is, the server could
just refuse to store more data. Silently corrupting two documents for every
document inserted is inexcusable, even if your database was forged in the pits
of hell.

I think your point about the poster child thing is true. While I meant my post
as a sort of "MongoDB didn't look too production-ready to me, but I hope it
gets there eventually", people became really polarized and took it either as
"this guy is right, MongoDB _sucks_ " or "this guy is an idiot, silently
corrupting data is perfectly acceptable if there's a notice on the website"...

------
zefhous
Some great improvements and one step closer to full-text search, which is
slated for 1.7.x.

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

~~~
mumrah
You can do pretty neat things with indexes and regexp queries. The mongo-
search project is also pretty cool (does Porter stemming, indexing, etc).

That said, if you need powerful "full-text searching" I would look to
something like Lucene or Xapian.

------
jpcx01
Replica sets look awesome. Can't wait to get them set up in production.
Replacing a master/slave setup with this means automatic failover.

Looking forward to single server durability in the next one (1.8). Should
enable me to convince more clients to add mongo as part of the deployment
stack.

~~~
hdeshev
I got a replica pair. Wonder how easy I can migrate it to a replica set.

~~~
patrickaljord
Upgrading From Replica Pairs or Master/Slave:

[http://www.mongodb.org/display/DOCS/Upgrading+to+Replica+Set...](http://www.mongodb.org/display/DOCS/Upgrading+to+Replica+Sets)

------
mark_l_watson
I installed 1.6 on my laptop today, but I will wait a week before starting to
update servers. Anyway, I have never had data collections large enough to need
sharding, but replica sets look like a much better alternative to frequent
snapshots to S3.

A year ago I was equally enthusiastic about MongoDB, CouchDB, and Cassandra.
However, at least for the modest scale work that I do I don't really need
Cassandra, and MongoDB is so easy to work with. I still really like CouchDB
but I have never had a customer request its use, so my experience is limited
to just using it for my own stuff.

------
zaph0d
Yay! Great news, just in time for my startup launch. Kudos to MongoDB.

~~~
ritonlajoie
Hi pune :) I was in I2IT some years ago.. nice place !

------
samratjp
Definitely getting huMongous - looks like it's used by justin.tv and
foursquare - good enough for me. By the way, there is a MongoDB shell on the
homepage for tryruby.org like mini tutorials => <http://www.mongodb.org/>
Convinced me enough to get interested and download mongoid as well :-)

Hmm, now all there's left is an online hosting solution like Couch.io

~~~
detst
There's <https://mongohq.com>

~~~
malyk
And there's a Heroku add-on that supports it as well.

~~~
thibaut_barrere
You can also use MongoHQ directly if you want, from Heroku.

I described the steps here:

[http://blog.logeek.fr/2010/6/29/sinatra-heroku-mongodb-
mongo...](http://blog.logeek.fr/2010/6/29/sinatra-heroku-mongodb-mongohq-
notes)

------
chuhnk
I was excited to see a new movement in database schemes that provide a
different way of storing data outside a relational database model however a
couple things bother me. Firstly calling it nosql, its just complete
disrespect of sql and relational databases, could there not have been a more
mature response and have it termed as something relevant?

Secondly what scares me and I find hilarious is people who so quickly jump
onto this movement, moving the entirety of their critical data without
understanding the potential downfalls, such as data loss with no warning. As a
key value store for non critical data, this kind of thing is brilliant, and
data loss can be managed, maybe not tolerated in a high throughput environment
where "cache misses" are a concern but otherwise yea its great. Still look at
facebook, twitter, friendfeed, who are all still using mysql and scaling out
in their own way.

------
lelele
Already commented about Debian here:
<http://news.ycombinator.com/item?id=1581231>

------
leej
i dont get why do they still stick with agpl. there are a lot more _companies_
built on products with licenses other than agpl, such as, wildly popular
apache projects. even microsoft releasing code with apache license but not
mongodb guys!

~~~
arst
There are successful companies built around all sorts of licensing schemes,
but that doesn't mean that you are in a position to say what's best for
10gen's specific situation.

Also, all of the official client libraries for mongo are Apache licensed, it's
only the core server that is AGPL (which means that you can use mongo in
closed source applications - only if you make changes to the actual core
database do you have to give those changes back to the community, and even
then you still don't have to open source the rest of your application).

~~~
leej
you're in no position to tell me what i say! it's simply awkard to use a
license like that. also you, yourself, admitted the conflict of client vs
server licensing. why this is so? because they want widest usage. they release
open source software not because they love developers but because they have
to. returning to the point apache or gpl projects have strong commercial
backing from big companies to start-ups and knowing this i'm asking there must
be a real reason why they did choose agpl over gpl or apache. btw, it's their
choice i respect that as well.

