Live data from Hacker News

The genius and folly of MongoDB

nyeggen.com

41–50 of 280 posts

Re: The genius and folly of MongoDB

#41
post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

You know, if you like it with node, ignore the haters and use it anyway. It's not some atrocious mess. I love mongoose in addition to it, use it all the time.

Re: The genius and folly of MongoDB

#42
post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

Couch is a great choice. So is Redis. I would go with Redis if you can afford the cost of ram and you know you'll always be looking stuff up by key. Otherwise I'd with Couch since the queries are just map/reduce functions and the api is just rest.

Re: The genius and folly of MongoDB

#43
post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

I'm unsure why you say there are no other alternatives. Surely the choice of database should preference your data and what you want to do with it over the language you'll use? There are node libraries for any database I've ever wanted to use (SQL and NoSQL alike)

Re: The genius and folly of MongoDB

#44
post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

Node.js isn't really a usecase that dictates what datastore you should use, it's just a certain way of writing a totally different piece of your app.

In most node.js apps, the best answer is probably a SQL database. Sorry.

If you're working with timelines or other cases where Redis's data models can help you, consider it, though beware that if your data is large, things will get more expensive fast since you're keeping everything in RAM.

HBase, Cassandra, and Riak are all reasonable in similar cases and have their own tradeoffs.

And yes, Couch fits a similar niche as Mongo. You might even be able to use something simpler like BerkeleyDB (quite mature) if you think you want a document store.

RethinkDB may be a nice choice too. It's fairly young but looks like it's going good places.

But your choice should be mostly dependent on what kind of data you're storing and what kind of guarantees and access models you need.

It should not be based on someone on HN telling you "Riak is the best NoSQL database for Node.js" because their idea of what most Node apps need may not be what yours needs.

Re: The genius and folly of MongoDB

#45
post #41
post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

You know, if you like it with node, ignore the haters and use it anyway. It's not some atrocious mess. I love mongoose in addition to it, use it all the time.

[deleted]

Re: The genius and folly of MongoDB

#46
post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

What's wrong with the Viaweb/Arc/HackerNews/Mailinator approach of just using in-memory datastructures (hashtables, linked lists) and then journaling out changes to the filesystem as records that are read in on startup? It's incredibly simple and blindingly fast as long as you stay on one server, and you can get several thousand QPS of capacity on that one server (vs. like 10 with a Django/Rails + SQL database solution).

Another highly underrated solution is using MySQL/PostGres as a key-value store. Just create one table for each entity type, with the primary key as the key and a JSON or protobuf blob as the value. You're using completely battle-tested solutions, you've got bindings in basically every language, you're doing basically the same work (at the same speed) as your NoSQL solutions, but you have a lot more flexibility to add additional indices and can rely more on pre-existing functionality than a MongoDB or CouchDB solution.

Re: The genius and folly of MongoDB

#47
post #22

Earlier quoted context omitted.

For what use cases is Mongo the right tool?

From what I've seen, the data model has a lot of utility as long as you don't need super high concurrent performance. Basically, the same area as where rails is the right tool - we want easy features and rapid development, will worry about scaling later.

What does mongodb offer above and beyond using postgres or redis for this use case?

Re: The genius and folly of MongoDB

#48

Earlier quoted context omitted.

For what use cases is Mongo the right tool?

You have a smallish number of documents where some particular field of fixed size gets overwritten a lot, the old values are uninteresting, and it wouldn't really be a tragedy if your data got trashed. For example, it's the player's score. You want a fixed-size, rolling backlog of time series data such as logs.

Is it better than a relational database for that?

Re: The genius and folly of MongoDB

#49
post #31

So, what's a good NoSQL database for e.g. node.js use? The only alternative I know of is CouchDB. (Yes, I should give more parameters about the intended use, but I really don't know any alternatives).

> So, what's a good NoSQL database for e.g. node.js use?

Well, this is the thing; 'NoSQL' is really a pretty unhelpful term. It tends to just mean "not relational", and covers a vast number of things.

So, for instance, you might be okay with having to have your data set fit in RAM (with MongoDB you'll suffer if it doesn't, anyway), and not care too much about availability. In that case, Redis might be good. Or maybe you care deeply about availability; in that case, one of the Dynamo paper databases might be good, if you're willing to put in the work dealing with the consistency issues. Or...

I could go on for a bit. 'NoSQL' is verging on a meaningless term.

Re: The genius and folly of MongoDB

#50
post #22

Earlier quoted context omitted.

From what I've seen, the data model has a lot of utility as long as you don't need super high concurrent performance. Basically, the same area as where rails is the right tool - we want easy features and rapid development, will worry about scaling later.

What does mongodb offer above and beyond using postgres or redis for this use case?

I've barely used it, but the json document thing with a lot of random convenience functions in the query language seem to lend themselves well to rapid development.

For postgres you'd be mapping to a relational schema, and for redis you'd be storing the json yourself as a blob, without any server-side manipulation capabilities (or using redis maps/sets/etc, which are awesome, but aren't as general as json).

I haven't been doing very much web dev the last few years though so it's possible that my first impressions are wrong. I'm just repeating what I've been told, basically.

Post reply on HN