

Ask HN: What to use instead of MongoDB? - nikon

If MongoDB is regarded as a poor product[1,2,3] then what should one use instead?<p>I feed a document database is the correct decision for my domain, so would prefer to choose a superior product now rather than regret it later.<p>[1] http:&#x2F;&#x2F;pastebin.com&#x2F;raw.php?i=FD3xe6Jt
[2] http:&#x2F;&#x2F;mcfunley.com&#x2F;why-mongodb-never-worked-out-at-etsy
[3] http:&#x2F;&#x2F;www.sarahmei.com&#x2F;blog&#x2F;2013&#x2F;11&#x2F;11&#x2F;why-you-should-never-use-mongodb&#x2F;
======
aceetum
Your "poor product" examples are really poor.

[1] [http://pastebin.com/FD3xe6Jt](http://pastebin.com/FD3xe6Jt) was debunked
in 2011 when it first appeared.

[2] The Etsy article from 2012 had the major point "if you are considering
Mongo plus another database like MySQL, then in all likelihood you shouldn't
do it [...] Keep in mind that almost none of this is specific to MongoDB. I
wouldn't discourage anyone from trying Mongo out if they're starting a new
site"

[3] As one commentator stated, "don't use a non-relational store when you have
relational data."

The most important thing you need to do is probably confirm your feeling
regarding a document database being the correct decision for your domain. [2]
and [3] concluded by using MySQL rather than MongoDB, but for different
reasons. Why do you think a not-MongoDB, but not-SQL database is correct for
you?

------
nmc
How can you expect an answer about a storage system without giving us a
detailed use-case?

One of the main reasons MongoDB is regarded as a poor product is because
people try to use it in completely inappropriate situations. OK, MongoDB has
some bad design choices, but it can be an interesting system in some cases.

------
wilsonfiifi
Honestly Mongodb is as good as it gets if you want to query your JSON data.
Yes it might have a few challenges when it comes to scalability and disk usage
but I don't think its anything that can't be addressed with a carefully
thought out architecture. I believe Tokutek with TokuMX is addressing some of
the shortcomings of Mongodb. Though I'm a bit surprised that 10gen hasn't
officially commented on Tokutek's contribution.

The other NoSQL solutions that would come close are CouchDB and RavenDB. I
haven't tried the latter but CouchDB doesn't allow easy adhoc querying and you
really have to give some thought to your Map/Reduce Views/Scripts.

CouchDB is great because it also allows you to attach binary content to your
JSON documents so it's great as a CMS backend but as I mentioned before,
querying your data isn't as pleasant as with Mongodb.

Now Mongodb does have GridFS for binary data storage but it isn't IMHO as
simple to use compared to CouchDB's 'Attachments'.

------
nikon
The product is an aggregator of sorts, very flat domain. The only thing apart
from the items being collected are categories which are denormalized on
aggregation - they have a short lifespan anyway.

RE: Write/Read/Update heavy, it's going to be a mixture. Once users are
present it will be read heavy. The backend is constantly collecting new data
and updating if changes are spotted.

I'm 99% certain a document database/ non-relational approach is suitable here.
I have nothing against MongoDB - I just want to make these decisions now. I've
enjoyed using it so far.

Thanks for feedback!

------
vijucat
Write-heavy, read-heavy, update-heavy, or all?

Consistent world-view or quick answers?

Gigabytes per day or terabytes per day?

Is the Time axis important? Do you need to go back in time and query the state
of the world? Do you need queries that relate the state of the world in two
different points of time?

Hmm, I should probably be charging you for this! :-) I'm distilling years down
the rabbit hole into these paragraphs + saving you months of discovery.

------
ddorian43
Better is to say these are my requirements and ask for what should i use ?

------
mattwritescode
CouchDb?

