
Announcing MongoDB 3.0 - meghan
https://www.mongodb.com/blog/post/announcing-mongodb-30
======
davidw
> a database so powerful, flexible, and easy to manage that it can be the new
> DBMS standard for any team, in any industry.

It's good to see they haven't sacrificed the hype while working on other
features :-/

~~~
stingraycharles
As much as I agree with your sentiment, it still remains one of the most
popular databases out there. All us techies can learn something from the hype
they managed to create.

~~~
jsjohnst
Source needed. Can't make outlandish claims like that without supporting
evidence.

Here's a couple disproving your claim:

[https://www.scalebase.com/the-state-of-the-open-source-
datab...](https://www.scalebase.com/the-state-of-the-open-source-database-
market-mysql-leads-the-way/)

[http://db-engines.com/en/ranking](http://db-engines.com/en/ranking)

~~~
morsch
So grandparent claims it's one of the most popular databases out there; your
first links claims it's in 4th place of all open-source databases; the second
link says it's 4th place overall. Sounds fine to me (of course, who knows how
those sites came up with those statistics). Maybe he ninja-edited and
originally said _the_ most popular, I guess that'd explain the rage.

~~~
jsjohnst
I'm pretty sure it said it was "the" most popular before, hence the replies,
but I could be wrong.

~~~
stingraycharles
No it was not, because that would be very easy to disprove (I can imagine
MySQL and PostgreSQL being far more popular).

------
harel
OK, I'll provide a user's perspective as we are invested in Mongo as a storage
system for statistical data and have been using it for a good few years now.
MongoDb has been, so far, very good to us. I did not experience any of the
problems people sometimes cry so very vocally about. My main concern about
Mongo is actually one that is addressed by this release so I'm quite excited
to try it out - data compression. Mongo is generally quite irresponsible about
disk space usage. Yes disks are cheap but I rather not have a 2TB dataset if I
can have half the size, thank you very much.

As a side note, the hype from MongoDb the company equals the anti-hype you get
on places like HN, so I guess they even out.

~~~
functional_test
You may also really like TokuMX. It has the same API as Mongo (even works with
Mongo drivers) but way lower disk use, faster indices, and better query
semantics (e.g. updates don't affect the cursor you're iterating right now).

After using MongoDB for years (very happily too, I'm not one of the anti-Mongo
crowd), I ended up switching and it's been great.

~~~
harel
Thanks for the tip. I'll be sure to check it out.

------
jimbokun
"We will continue to push the envelope in data interaction semantics, by
implementing a transaction system for the distributed document model."

So...Mongo "can be the new DBMS standard for any team, in any industry", and
they don't even support transactions yet?

~~~
gaius
I am old enough to remember MySQL in the 90s, those guys sneered at anyone who
said they needed transactions, just do it in your application. Same with
enforcing relational integrity, just do it in your application. We all know
how that turned out.

~~~
frik
MySQL is one of the top 3 databases, it is used as main database in Facebook,
Wikipedia and many other high traffic we sites. There are forks like MariaDB
and alternatives with more features like Postgres. MySQL with its several
different db engines is unique and with the default InnoDB engine it is on par
with its competitors.

~~~
gaius
Yes, the InnoDB engine adds transactions, foreign keys, and all the other
traditional RDBMS features that the original authors of MySQL didn't think
anyone needed.

InnoDB by the way is an Oracle product.

~~~
Xorlev
InnoDB wasn't always an Oracle product. It was bought in 2005.

~~~
lafar6502
Like many other Oracle 'products'

------
nevi-me
I'm excited to see 3.0, but from what I've seen on JIRA, there might still be
some issues with WiredTiger (fair considering how they moved from RocksDB to
WT in a short period). Will be interesting to see if they'll close out those
issues before they drop 3.0 in March.

A few months ago they closed up some of JIRA (comments and a bit
epics/sprints), so some issues would be created and have no comments exposed.
I thought they were working on transactions in this release (while they were
still around 2.7.3 or so), but I guess that's not the case.

Lastly, I wonder how this will impact TokuMX, both positively and negatively?
Really whether they'll be making their crown improvements into a pluggable
storage type/engine, and if users would be able to take that and plug it into
Mongo without patent issues on their fractal tree indexing.

Nonetheless, exciting news for some of us who are building on web-scale,
MVCCABCD databases which operate at the speed of hype and web-scale :)

EDIT: saw that Tokutek has created TokuMXse, only after my post

------
james33
I feel like the vast majority of people that bash on MongoDB didn't fully
understand it and what it was good for when they tried it. We've been using it
in production for nearly 3 years in online games and have had nothing but good
experiences with it. This 3.0 release will be yet another big step forward and
we are excited to reap the continued benefits.

~~~
nemo44x
That's mainly correct. Or they used for it something it simply isn't suitable
for.

You can't just throw random data into it and expect it to work. Proper
document modeling and understanding write concern solve almost all the
problems people have with MongoDB.

It still has a ways to go but so many of the comments here are issues from way
back in v2.0.

Regardless, it's still very popular and only gaining popularity. And
improving.

~~~
vkjv
Agreed. I've also been using it in production for years and the hate is often
misguided. My issues are almost never with lack of features, but almost always
with the cavalier attitude towards bugs, even catastrophic ones.

------
kosma
> Reduces operational overhead up to 95%

And 40% more hip. Gotta love those numbers. Also, don't forget about the new
WiredTiger storage engine - sounds way cooler than, say, InnoDB! Hype is
strong with this one.

~~~
lclarkmichalek
Eh, Wired Tiger was built outside of Mongo
([http://www.wiredtiger.com/](http://www.wiredtiger.com/)), and does seem to
be legitimately decent.

~~~
kosma
...and their most important improvement isn't even their own.

I'm not a fan of bashing any product, but after using MongoDB in several
projects, in legitimate document database use cases, I just can't find any
bright side.

~~~
lclarkmichalek
Oh, I can't stand Mongo. But I have nothing but respect for the Wild Tiger
guys, and wouldn't want to see them slandered ;)

------
vegabook
I'm writing 20000 financial ticks per second into Mongo on commodity hardware,
namely a bog-standard i7 with 32 gig costing less than 2k. I don't have a big
budget. I don't have a lot of time to mess with ACID. There is _no way_
postgres will do this for under 10-20k, without twice the work. I just need to
keep up with the firehose of data I get from my financial application. I'm
talking about my own big-data issue and even if a few records were ever to get
lost, I don't care, because that's what big data is about: statistical
sampling. And that does not require 100% in 100% of cases safety of every data
point. That by the way, is the truth of big data. Who cares if a few records
theoretically can be lost? I just need to capture as much as possible as fast
as possible. Mongo fits perfectly. Redis would work, but I'd need 512 gig of
RAM.....

I don't understand all the angst against this technology. If you need
rollback-able transaction-guaranteed, exactly-once consistency, normalised
schema with triggers left right and centre, you knew long ago that this wasn't
the tech for you. Why is everyone so negative? I for one cannot wait to be
able to store 4x more data on the same SSD, and using less RAM. In my view,
Mongo is a massive enabling technology for startups on limited budget.

------
Kiro
Am I the only one using MongoDB who think it works great? I'm really happy
with it.

~~~
127001brewer
I have been developing with MongoDB for about the past year. (Briefly, I have
developed, and continue to support, an ASP.NET MVC C# Web Application that's
used by a few thousand people daily. For my personal projects that use
MongoDB, I develop with PHP and Python.)

Overall, I enjoy working with MongoDB, because it ( _generally_ ) maps
directly to your object - there is no need for an additional layer (such as an
Object Relational Mapper (ORM)).

However, you have to be _more careful_ with your data structure. For example,
having sub-arrays in sub-arrays is probably not a good idea.

I will be happy to share more, so feel free to look up my profile.

~~~
msandford
I ran a website and operations for a company that did over 1mm a year in
revenue. Everything was done off of a single machine that was the webserver,
database server and media server. Had 10k customers all of whom were active
daily. Postgres and Python/Django and I never saw load averages much over 10%.
Unless you have a substantial fraction of a million daily users you probably
don't need mongo.

~~~
127001brewer
I agree with that MongoDB may have been overkill, but my web application's
architecture was chosen before I joined the team.

------
lesingerouge
Somebody at MongoDB must have read the early Oracle story. Start with one
consumer niche (in mongo's case I think it's the common building-cms-based-
websites web developer), improve the product, market ruthlessly.

Granted, their product is not excellent and it has major flaws and lacks some
common DB features, but they have the advantage of developer-ease-of-use and
low barrier to use.

I think this product is simply not yet "DONE".

------
ericingram
We've been using TokuMX for a while and I highly recommend others take a
serious look there. It already contains the benefits cited for MongoDB 3 and
more. Toku also has a release candidate for the new Mongo storage engine API
named TokuMXse, though it's interesting to see that TokuMX proper still
outperforms it: [http://www.tokutek.com/2015/01/first-tokumxse-performance-
nu...](http://www.tokutek.com/2015/01/first-tokumxse-performance-numbers/)

~~~
nemo44x
Problem is where it is branched. I don't think they will be able to keep up
well. Plus, the new MongoDB storage engine (wire tiger) takes care of its
biggest issue which Toku addresses.

Plus, I think you'll be able to just buy Toku's storage engine if you want it
when they make it pluggable with the new MonogDB storage engine API.

------
mlschmitt23
I agree this announcement is dripping with hype, but all the same I'm excited
to get my hands on this. Seems like they're trying to address (some) common
pain points.

------
jungleg
I'll add to what @harel says below. If it wasn't for MongoDB, my last company
would have probably not survived. Sure, our usecase was very specific (very
write-heavy app) but MongoDB delivered and still delivers without any
problems. I think there can be usecases where MongoDB is not the best fit, but
for wide number of applications, MongoDB is the perfect fit.

~~~
disbelief
I'm actually surprised that MongoDB saved your write-heavy app. In my
experience, it's Mongo's poor write throughput that causes the most headaches.
This 3.0 release finally begins to address that with collection and document
level concurrency control (locking).

------
alexgaribay
Can some people who have used Mongo in production elaborate on their
experiences where Mongo worked well or didn't work well? I see a lot of more
hate than I do love for Mongo on HN and I'm curious why.

~~~
disbelief
I've used Mongo in two large projects and have mixed feelings about it.

Pros: It's great for building your MVP. Super easy to get up and running,
super easy to work with at a superficial level (I'm talking about storing data
and querying here more than ops and administration), dataset can grow to a
fairly large size without you having to think about your database at all,
freeing you to think about your business. Mongo was my first brush with
"schemaless" and that's a big advantage particularly for early-stage projects
where things are in flux. I also enjoy using JS as the query language, because
I like JS, but YMMV.

Also for certain use cases, particularly the single document case, it's
probably one of the best solutions available. However, in my experience, this
ends up being a limitation if your data doesn't fit nicely into a single
document, and the types of data that do fit this use case are rare.

The cons you've probably heard before: no transactions, no joins, not ACID
compliant, until very recently writes locked the entire database,
scaling/sharding _just works_ until it doesn't.

------
jimbokun
The differences between mongodb.com and mongodb.org are striking.

I was confused about why there was no links to documentation on the .com,
until I stumbled onto the .org, which lists actual features right on the home
page.

Also striking: no mention of 3.0 on the .org home page at all, and on the
downloads page, you have to scroll down to "Development Releases (unstable)"
to find any reference to the 3.0 builds.

[https://www.mongodb.org/downloads](https://www.mongodb.org/downloads)

Quite the split personality between the two sites.

~~~
nemo44x
The .com is the corporation behind MongoDB. .org is the open source project.
Yes, they are intertwined heavily at this point (but it wasn't always this
case back in the day) but I can understand why they try and keep their
separation of concerns here.

------
ddorian43
You can build a slow product and when you make it normal-speed you say 5x
faster!

------
vkjv
Am I the only person that things the sheer number of people that have had
scaling issues with mongo is a GOOD thing? I think it speaks to changing
technology landscape and attitude towards data.

Many more people are collecting and working on larger data sets than they
would have ever dreamed of years ago. I credit MongoDB, in part, to allowing
developers to do this and encourage them to try. Sure it has it's limitations
and may not be as great in areas as other databases, but, wow have a lot of
people tried and succeeded.

tl;dr, If reverse survivor-ship bias is a thing, I think mongodb has it.

~~~
tracker1
I've been pretty happy with mongodb overall for a few years now. It isn't
always the best fit... but it's a very good fit for a lot of scenarios.
Replication and sharding in mongodb is way easier to get started with than
most databases, and the failover for replication is very good as well. Though
understanding how it works is still advised. Such as not having more than X
nodes voting for electing a leader in case of failover, etc.

That said, there are situations I'd be more inclined to reach for
ElasticSearch, Cassandra or others. As soon as RethinkDB has it's automatic
failover story in place, I'd put it above MongoDB though, slightly nicer
developer interface, and admin is much nicer than others.

Then again, if PostgreSQL got replication with failover in the box, I'd
probably use that far more.

------
endijs
"MongoDB 3.0 will be generally available in March, when we finish putting it
through its paces. Stay tuned for our latest release candidate, we would love
it if you would try it out and give us feedback." So... no 3.0 final yet.
That's disappointing. However - I'm really excited about 3.0. Initial tests
show way better performance than 2.6. Plus data takes just 1/4th of disk
space. That's amazing. I hope this is just beginning and each next release
will add more and more features based on what WT can deliver.

------
cheald
I'm actually fairly interested in the WiredTiger integration. I switched from
MongoDB to TokuMX about a year ago because of disk space and atomicity
concerns, and Toku's been really good to me. Mongo 3.0 promises to catch up in
many respects; if it does, then it might actually solve the vast majority of
the complaints that people have historically had with it.

The marketing copy still pretends that TokuMX doesn't exist, though - it's had
these features and more (including transactions) for quite some time now.

------
tankerdude
The announcement, to me, was way over the top. There was so much noise in the
announcement with very little in terms of signal. It reads almost like
vaporware, even though it probably was not.

Just give us facts, plain and simple. What it improves and how it improves it.
When there are that many adjectives about the project, it just causes me to
tune out a bit.

Was this supposed to be part of a sales deck or something? (An as aside, I use
mongo and know its pluses and minuses so reading all that hoopla is just
unseemly.)

------
fasteo
MongoDB seems to be a love/hate relation. I haven't used it myself, but I
found this article[1] very useful. My conclusion is that MongoDB works, but
you need to understand it and take some time to plan the deployment.

[1] [https://blog.serverdensity.com/does-everyone-hate-
mongodb/](https://blog.serverdensity.com/does-everyone-hate-mongodb/)

------
nnain
Slightly off topic: I prepared this MongoDB Quick Reference Card last year;
never put it online before. Hope it'll be useful to someone looking for a
quick peek into how mongo db commands work -
[https://dl.dropboxusercontent.com/u/58502821/mongodb_qrc.pdf](https://dl.dropboxusercontent.com/u/58502821/mongodb_qrc.pdf)

------
astral303
Comment threads like these help me learn how different the HN
groupthink/prevailing thought is from the reality on the ground.

In reality, MongoDB works well enough to be where they are, armed with the
money they have.

~~~
nemo44x
That's the point so many here fail to address. Lots of businesses are using
MongoDB at large scale (2PB clusters) and willing to talk about it too.

MongoDB gets a bad rep, some of it their own fault for sure, but it's not as
lousy as some people here make it out to be. Careful object modeling goes a
long ways. Wired Tiger will be a massive improvement on their current storage
engine, which is pretty awful for write-heavy loads to be sure.

------
je42
Anybody knows how FoundationDB compares to MongoDB 3.0 ?

------
jedberg
Do they still value speed over durability? If so, thanks but no thanks. I
prefer my database to be durable. If I want speed, I use RAM.

~~~
nemo44x
You've always been able to control this with write concern on a per-write
basis. If you can handle an instance where and acknowledged write may not get
replicated and possibly lost (logging use case - fast writes) then use that
level of write concern. If you require extreme durability (slower writes but
more durable) then use that level. In many applications you have both
requirements and MongoDB lets you choose at write time the level of durability
you want.

~~~
jedberg
Does version 3 fix the issue where the database lies to you and says the write
was complete once it hits the network socket and doesn't wait for the ack?

[http://hackingdistributed.com/2013/01/29/mongo-
ft/](http://hackingdistributed.com/2013/01/29/mongo-ft/)

~~~
nemo44x
He was using v2.0 in that article. A version that is years old and pretty
awful. The default then was that a write was fired from the client and that's
it - fire and forget. A stupid default.

The default since is to get an ack from the server. You can control this on
each write and make it more durable (make sure it is replicated to 1, majority
or all replicas) or faster (just get to the server). The default is to be
written to the primary server and put into the transaction log so if it
doesn't get committed to disk (possibly 60 seconds by default) it can recover.
The transaction log is flushed (fsync) every 100ms by default and is
configurable. You can also specify that the write is only acknowledged after
the transaction log is synced. Anyways the default is it is put into the
transaction log and then acknowledged.

~~~
jedberg
Ok, fair enough. Then the answer is yes, they did fix it. :)

I guess I'll give it another look then.

But I'm still a little wary of a database built by people who ever thought
that such behavior was acceptable for a database...

~~~
nemo44x
I'd make sure you use the new storage engine, wiredtiger too if you give them
another shot. The standard one works well on read heavy use cases but
saturates I/O pretty quickly if you're doing a lot of updates that make
documents grow if you don't take some precautions.

I also agree, having a setting of "fire and forget", although useful in some
(limited!) use cases, is not a sane default.

------
iagooar
You got your chance, Mongo, and you screwed it up.

I tried getting the most out of you. I treated you like a princess, I indulged
you, your wishes became my wishes and your thoughts were my thoughts. I
stopped listening to all that criticism around you and thought of you as of a
misunderstood child, even as you would refuse to do even the easiest tasks one
could imagine.

I gave you everything there is to give, but you broke my heart. You left me in
the most critical moments. I trusted you, but you would go your own way. Tears
were shed and countless sleepless nights were to follow.

Remember that night you disappeared without leaving a sign? I sent you
messages which got a response only after many hours. You didn't give a damn
about my needs. One you told me: "it's not me, it's you". And I believed you,
I truly did.

It's over now. It's been some time without you, and I'm getting better. I have
discovered, that not everyone is like you. Some DBs care, they really do. You
can trust them, they give you their everything.

I'm still struggling falling in love again, but it's getting better. Don't
write me back. Goodbye.

~~~
bhouston
How is a non factual comment like this being up voted? Just because it aligns
with hn prejudices?

Edit: I guess for the same reasons I am being down voted without comment.

~~~
krenoten
Because it alludes to problems many people have experienced with this product.
All verbal communication is indirect to a degree. This is no exception.

~~~
xtrumanx
You have to admit that it feels very out of place here on HN.

I wouldn't have minded it as much if it wasn't so long and including some
detailed issues OP faced with Mongo.

------
slantview
So I heard this means it's webscale now?

