node.js database
node.jsMongodbCouchdbRedisnode.js Problem Overview
I'm looking for a database to pair with a node.js app. I'm assuming a json/nosql db would be preferable to a relational DB [I can do without any json/sql impedance mismatch]. I'm considering:
- couchdb
- mongodb
- redis
Anyone have any views / war stories re compatiability/deployability of the above with node.js? Any clear favorites?
node.js Solutions
Solution 1 - node.js
I'm the developer of the mongodb driver for node.js. I'm using mongodb for my own projects and have been very happy with the performance of mongodb.
(Shameless plug) Feel free to ask any questions about the driver at
Google group for the mongodb driver
or here at Stackoverflow
Have fun with node.js. I absolutely love the platform :D
Solution 2 - node.js
Although your choice very much depends on the features you are going for, I really appreciate CouchDB for its native JavaScript environment. Both data and views are written in JavaScript so it fits very well to node.js in my opinion.
There are also different client libraries available, some are rather low level, other really very abstracted.
But as I said, you should also think about the features that you require for your database.
Solution 3 - node.js
Redis is a popular choice. What you're after is a database driver that doesn't block.
The databases you listed are all very different. Redis takes the idea of key-value storages and runs with it, adding a variety of data types and ways of querying data. People often note that redis scales down very well too; meaning that it has very low overhead despite having the ability to perform.
Here is a list of available database modules: http://wiki.github.com/ry/node/modules#database
Solution 4 - node.js
I really like CouchDB. It's a bit of a learning curve, but views are really powerful once you understand how to use them. There is a module called cradle on github and npm that is really easy to work with. I haven't been able to test how fast it is, but it is really flexible (you can access your data in a browser too if you'd like).
The major issue here is which database design makes sense for your application. Do you have data that is largely key-value in nature? If so, use Redis. Do you have data where not all documents necessarily have the same fields? If so, use a NoSQL database like CouchDB.
The next worse thing to using a blocking database is using the wrong database for your data. CouchDB is managed by Apache, so you know that it's good quality, but it doesn't make sense to use it if your data would make more sense in an SQL table or a simple key-value store.
Think of your use case. Will you be more likely to want to do a full-text search, just get data by key, or get ranges of documents that have similar attributes?
Solution 5 - node.js
Might want to check out Persistence, high level persistance/database system for node.js.
from thechangelog.com:
> Persistence is a project to allow a > high level API for persisting data > between process runs. The goal is to > support backends that are easy to use, > powerful, flexible, or all of the > above if possible. > > Supported databases include: > > * PostgreSQL - An enterprise level > relational database. The driver is > implemented in pure JavaScript and > communicates over TCP using the > PostgreSQL wire protocol. > * Sqlite3 - > A simple, fast, server-less relational > database. This driver is a wrapper > around the command-line sqlite3 > program. It requires sqlite3 to be in > the path. The communication is > extremely fast, but types aren’t very > precise. There are only strings and > nulls returned. > * MongoDB - A > scalable, high-performance, open > source, schema-free, document-oriented > database. This driver also implements > the wire protocol in JavaScript and > communicated with the server over TCP. > * JSON-DB - A homegrown system schema-free, document-oriented > database that uses simple flat files > containing JSON objects. This has no > requirements at all except node and a > filesystem. Performance is to be > determined once it’s implemented > fully.
Solution 6 - node.js
Disclaimer: I'm the author.
Perhaps have a look at BarricaneDB announced here.
Solution 7 - node.js
I'm not sure the correct solution is to solely focus on mapping a database to your web stack, but rather also considering application-specific requirements.
Are you analyzing twitter feeds or other high-volume data for patterns, but don't need transactional support? Then pick something really fast.
Do you just want to store some really basic info in a few tables and its currently not an "enterprise focused" app? Then pick something cool to learn.
Maybe you are going to store data thats really important to a client, robust, needs to be transactional, and have live replication to remote hosting facilities, etc. Then maybe look at something like postgresql. It wouldn't mirror as well, but the node.js driver works pretty well and if you aren't deathly afraid of sql it gets what you want in/out pretty easily.
As for my own opinion, I think going with a newer stack like node.js (vs traditional frameworks in php/java) is adding enough "new" complexity that one shouldn't add extra layers all at once. This is a good article that discusses that:
Solution 8 - node.js
I'll speak from my experience: CouchDB comes with a definite learning curve, whereas MongoDB I found to be very easy to learn and set up. I have never used redis. I suggest MongoDB - but that maybe shameless fanboyism - I have no numbers, heh, only claims of ease of use.
Solution 9 - node.js
dirty is yet another flat-file key-value store. As the name suggests, it's a quick and dirty but performant solution for simple cases. I'm not the author :)
Solution 10 - node.js
Some more to consider:
Globals: http://globalsdb.org
GT.M (see https://github.com/robtweed/node-mwire for a starting point)
M/DB (an open source clone of SimpleDB): https://github.com/robtweed/node-mdb and you can use the Node.js SimpleDB client to access it: https://github.com/rjrodger/simpledb