6 ms·

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, bu

by nawitus 13y ago

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

deleted 13y ago
[deleted]
egeozcan 13y ago
RethinkDB[1], perhaps. [1]: http://www.rethinkdb.com/ http://www.rethinkdb.com/
bpicolo 13y ago
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 13y ago
  [deleted]
Touche 13y ago
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.
patrickod 13y ago
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)
- nawitus 13y ago
  I tried to say 'no NoSQL alternatives'. And I noticed that while there's node middleware for most libraries, the ease of use is different for each database.
jackowayed 13y ago
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.
nostrademons 13y ago
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.
- rsynnott 13y ago
  > 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? That works for some things. However, it's no more a foolproof magical solution than MySQL or MongoDB or Cassandra or Oracle or... It just has different tradeoffs (non-primary key queries will tend to be a problem, you'll have to make your own replication, sharding will be a problem, etc etc).
  - nostrademons 13y ago
    Well, that's of course true. All engineering systems face trade-offs. The nice thing about doing the dead simple solutions first is that they give you time to focus on the things all startups have to do (getting users, building product) and then fall down at the the things that very few startups have the luxury of needing to deal with (scaling, fault tolerance, reporting, alternative views of data). Throughout the lifetime of my first startup, I was obsessed with the question of "What are we going to do when we need to scale?" It failed because it had a daily userbase measured in the dozens. Then I went to Google to learn how to scale things. And it turned out the biggest lesson I learned at Google was not how to scale things (though I did learn that too), but that you shouldn't scale things, not until you need to. Because the process of designing for scale slows you down significantly, and makes it much harder to develop a system that's usable and performs well under small workloads. Google products take forever to launch, because they have to scale to millions of users from day 1. As a result, their product decisions are very often questionable in early versions. Most startups don't have the luxury of Google's brand name and billions in cash to tide them over that learning process, and need to hit the ground running. Focus on the problems you have, not the problems you hope to have in the future.
rsynnott 13y ago
> 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.
yummyfajitas 13y ago
One viable option: CREATE TABLE mongodb ( key VARCHAR(256) PRIMARY KEY, value JSON );
- mkhattab 13y ago
  I think you're onto something here.
- joevandyk 13y ago
  I'd use a uuid for the key. Also, see https://github.com/umitanuki/mongres https://github.com/umitanuki/mongres Postgresql speaking the mongodb protocol.
  - tzury 13y ago
    from the github page mentioned above: This is currently a prototype. The following operations are supported. db.collection.find() db.collection.insert() Two methods only, well, that's too little.
- meowface 13y ago
  Mongo (and other document stores) let you do pretty complex querying within JSON objects. Postgres unfortunately doesn't let you do so; that's really the only thing keeping me with Mongo at the moment.
  - yummyfajitas 13y ago
    It does with plv8. Just like in mongodb, you get to write javascript functions and use them for queries. https://postgres.heroku.com/blog/past/2013/6/5/javascript_in_your_postgres/ https://postgres.heroku.com/blog/past/2013/6/5/javascript_in... I don't know how stable/performant it is (I've never needed to use it), however...
  - joevandyk 13y ago
    Postgresql 9.3 added json functions.
Lazare 13y ago
Well, the obvious answer to your question is: CouchDB! It's a brilliant, underrated database, and hey, it backs NPM! On the other hand, Redis, Cassandra, Riak, and many more are also excellent NoSQL databases. But none of them, including CouchDB, are excellent at everything. What are you planning on making? You can write a lot of different things in node.js. If you're writing, say, a blogging engine you probably should look into flat files, or maybe Postgres, and forget the NoSQL kool-aid. :)
- dodyg 13y ago
  Actually if you are making a blog engine or CMS, a document database is an obvious choice.
  - Lazare 13y ago
    I'm a huge fan of NoSQL in general, and document databases in particular. However, I think this is nuts. :) NoSQL is about making tradeoffs; you give up some of the strengths of a traditional RDBMS but in return you get some unique advantages. The problem is, you aren't taking advantage of any of those advantages with a blog...are you? I really don't see how MongoDB beats Postgres for running a basic blog. And while it doesn't prove anything, I note that Ghost (which has been getting a lot of press as a new, shiny, node.js based blogging platform) is backed by SQLite of all things. Why is it obvious that they should have used a document database instead? What advantages do you think that would have given them? Because of the top of my head I can't think of one.
    - dodyg 13y ago
      How about this list for a start? 1. If you are doing multi lingual site, you can store your multiple language content in a single document instead of futzing around with {lang, content} tables 2. If you want to do custom form/content, it is trivial to do it in a document database instead of relying on key,attribute tables. 3. Just store your theme in a single document, which can include various html templates, css, etc. To export or import a theme is also easy - just stuff the whole document into the db. 4. If you want to add plugins to enhance the capability of your blog/cms, they can have their own nested document inside their target document. Everything is contained.
the1 13y ago
ejdb or solr.

by nawitus 13y ago

deleted 13y ago

[deleted]

egeozcan 13y ago

RethinkDB[1], perhaps. [1]: http://www.rethinkdb.com/ http://www.rethinkdb.com/

bpicolo 13y ago

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 13y ago
[deleted]

Touche 13y ago

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.

patrickod 13y ago

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)

nawitus 13y ago
I tried to say 'no NoSQL alternatives'. And I noticed that while there's node middleware for most libraries, the ease of use is different for each database.

jackowayed 13y ago

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.

nostrademons 13y ago

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.

rsynnott 13y ago
> 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? That works for some things. However, it's no more a foolproof magical solution than MySQL or MongoDB or Cassandra or Oracle or... It just has different tradeoffs (non-primary key queries will tend to be a problem, you'll have to make your own replication, sharding will be a problem, etc etc).
- nostrademons 13y ago
  Well, that's of course true. All engineering systems face trade-offs. The nice thing about doing the dead simple solutions first is that they give you time to focus on the things all startups have to do (getting users, building product) and then fall down at the the things that very few startups have the luxury of needing to deal with (scaling, fault tolerance, reporting, alternative views of data). Throughout the lifetime of my first startup, I was obsessed with the question of "What are we going to do when we need to scale?" It failed because it had a daily userbase measured in the dozens. Then I went to Google to learn how to scale things. And it turned out the biggest lesson I learned at Google was not how to scale things (though I did learn that too), but that you shouldn't scale things, not until you need to. Because the process of designing for scale slows you down significantly, and makes it much harder to develop a system that's usable and performs well under small workloads. Google products take forever to launch, because they have to scale to millions of users from day 1. As a result, their product decisions are very often questionable in early versions. Most startups don't have the luxury of Google's brand name and billions in cash to tide them over that learning process, and need to hit the ground running. Focus on the problems you have, not the problems you hope to have in the future.

rsynnott 13y ago

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

yummyfajitas 13y ago

One viable option: CREATE TABLE mongodb ( key VARCHAR(256) PRIMARY KEY, value JSON );

mkhattab 13y ago
I think you're onto something here.
joevandyk 13y ago
I'd use a uuid for the key. Also, see https://github.com/umitanuki/mongres https://github.com/umitanuki/mongres Postgresql speaking the mongodb protocol.
- tzury 13y ago
  from the github page mentioned above: This is currently a prototype. The following operations are supported. db.collection.find() db.collection.insert() Two methods only, well, that's too little.
meowface 13y ago
Mongo (and other document stores) let you do pretty complex querying within JSON objects. Postgres unfortunately doesn't let you do so; that's really the only thing keeping me with Mongo at the moment.
- yummyfajitas 13y ago
  It does with plv8. Just like in mongodb, you get to write javascript functions and use them for queries. https://postgres.heroku.com/blog/past/2013/6/5/javascript_in_your_postgres/ https://postgres.heroku.com/blog/past/2013/6/5/javascript_in... I don't know how stable/performant it is (I've never needed to use it), however...
- joevandyk 13y ago
  Postgresql 9.3 added json functions.

Lazare 13y ago

Well, the obvious answer to your question is: CouchDB! It's a brilliant, underrated database, and hey, it backs NPM! On the other hand, Redis, Cassandra, Riak, and many more are also excellent NoSQL databases. But none of them, including CouchDB, are excellent at everything. What are you planning on making? You can write a lot of different things in node.js. If you're writing, say, a blogging engine you probably should look into flat files, or maybe Postgres, and forget the NoSQL kool-aid. :)

dodyg 13y ago
Actually if you are making a blog engine or CMS, a document database is an obvious choice.
- Lazare 13y ago
  I'm a huge fan of NoSQL in general, and document databases in particular. However, I think this is nuts. :) NoSQL is about making tradeoffs; you give up some of the strengths of a traditional RDBMS but in return you get some unique advantages. The problem is, you aren't taking advantage of any of those advantages with a blog...are you? I really don't see how MongoDB beats Postgres for running a basic blog. And while it doesn't prove anything, I note that Ghost (which has been getting a lot of press as a new, shiny, node.js based blogging platform) is backed by SQLite of all things. Why is it obvious that they should have used a document database instead? What advantages do you think that would have given them? Because of the top of my head I can't think of one.
  - dodyg 13y ago
    How about this list for a start? 1. If you are doing multi lingual site, you can store your multiple language content in a single document instead of futzing around with {lang, content} tables 2. If you want to do custom form/content, it is trivial to do it in a document database instead of relying on key,attribute tables. 3. Just store your theme in a single document, which can include various html templates, css, etc. To export or import a theme is also easy - just stuff the whole document into the db. 4. If you want to add plugins to enhance the capability of your blog/cms, they can have their own nested document inside their target document. Everything is contained.

the1 13y ago

ejdb or solr.