Mongo vs. Couch vs. LevelDB ?

[Dylan Hassinger]

Hi everybody - I am a Node newb building my first app, and trying to figure out which database system to use. Can anybody shed some light on what the major differences are between Mongo, Couch and LevelDB - and when is the right time to to use them?

Specifically, is the syntax similar between them / is it easy to switch after-the-fact?

Also wondering if anybody has suggestions for hosted database-as-a-service options? I've heard good things about MongoHQ, but not sure if there's hosted options for Couch or LevelDB. Thanks for any help!!

dylan

[Adam Reynolds]

Might want to consider FoundationDB as well while you're at it :)

--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nod...@googlegroups.com
To unsubscribe from this group, send email to
nodejs+un...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
 
---
You received this message because you are subscribed to the Google Groups "nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nodejs+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Rob Ashton]

This is a very broad question to be asking, and sounds dangerously like "please do all my research and make my decisions for me".

They are all rather different things, and spending 30 minutes looking at each would tell you that and narrow your question down to something more reasonably answerable.

On Wed, Aug 28, 2013 at 2:35 PM, Dylan Hassinger <d...@dylanized.com> wrote:

--

[Jerome Hwang]

This was very helpful for me when I first looking for DB:

http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis

I would recommend MongoLab when you're doing development since it's free:

https://mongolab.com/welcome/

I might eventually create an EC2 instance to maintain it myself when I go to production though.

--
University of Illinois at Urbana-Champaign
College of Engineering | BS in Computer Science
Tel: (517)203-9077 | E-mail: jhwa...@gmail.com

[vladimir....@gmail.com]

LevelDB it's not really a dbms, but a library for storing key-value pairs, so there there is no such thing as hosted LevelDB (it's like hosted sqlite, makes no sense). As for Mongo and Couch, I advise you to stick with Mongo unless you no that Couch fits your need. Mongo is muсh more general-purpose solution, like rdbms. You can play with Couch at iriscouch.com or cloudant.com (it's a sort of Couch on steroids option) and see what it is capable off.

[rtweed]

You might also want to look at GT.M or GlobalsDB - see EWD Lite, which projects them as native JSON databases:

http://gradvs1.mgateway.com/download/EWDLite.pdf

Rob

[Gary Katsevman]

Personally, I'd probably opt for couch. It has a nice restful interface that you can interact with.

Gary Katsevman
gkatsev.com

--

[Dylan Hassinger]

Thanks for the great thoughts everybody. I had tried to look this stuff up prior to posting, but figured my research would be incomplete without testing the waters here :) also I lot of the blog posts went over my head, this thread was very helpful.

I have also been recommended RethinkDB and ElasticSearch. Anybody have opinions on those, or thoughts on how they compare to the others?

Thanks again!!

On Wed, Aug 28, 2013 at 1:02 PM, Dylan Hassinger <dylanha...@gmail.com> wrote:

Thanks for the great thoughts everybody. I had tried to look this stuff up prior to posting, but figured my research would be incomplete without testing the waters here :) also I lot of the blog posts went over my head, this thread was very helpful.

I have also been recommended RethinkDB and ElasticSearch. Anybody have any thoughts on those, or how they compare to the others?

Thanks again!!

[Mikeal Rogers]

CouchDB, MongoDB and every other database you've listened other than LevelDB are traditional "big black box" databases.

They store data in a predetermined format, they give you an API to get it out and to index it in a declarative manor.

LevelDB is a database engine, very small, and in the node community when we talk about LevelDB we're really talking about levelup which is the higher level API we all bind to, and the community that is growing on top of it.

Levelup can bind to LevelDB as an engine but it also supports several forks of LevelDB and IndexedDatabase in the browser as well as some new upcoming storage layers optimized for different work loads.

The level ecosystem in node looks very much like other node ecosystems, lots of small modules plugging together to create bigger things and avoiding the complexity that comes with bigger projects, like traditional databases. This ecosystem is young and still has a lot of room to grow but it is the most promising future for datastorage I know of.

With level you're going to write your own database, don't think of it as "using a database." This is similar to how you may have "used Apache" prior to node but now you write an http server because node has made it simple, fast, and because writing logic in code is significantly more flexible than declarative DSL's and config files.

-Mikeal 

[Mikeal Rogers]

I would phrase this differently. As you write your own database using node.js and LevelDB you can host it pretty much anywhere that you can run a node.js program. Its deployment and management is identical to how you manage your node.js application. This means that you avoid most of the pain that goes with running infrastructure, like traditional databases, and it means you don't really need/want specialized "database hosting."

[Dylan Hassinger]

These posts really cleared it up for me. Cool stuff. Thank you so much!!

[Tom Ashworth]

When picking a database, I think it's a bad idea to start by looking at all the databases available to you and comparing their features. That's like comparing all the vehicles available to you for a trap, picking a supersonic jet because of its speed, when all you needed was a bike to cycle 5 minutes down the road.

All these databases, key-value stores and search engines are built to solve different problems, and without a problem to solve you can't make an informed decision. Working from the problem to a tools that can fix it is the only way to find the right data store.

Here's some examples...

You're building a javascript-heavy website that needs to work offline and on mobile.

This problem suggests that you need the following attributes:

  - good syncing & conflict resolution support, because changes can be made offline;

  - if possible, a client-side version so that you can use the same data storage API whether online or offline;

  - real-time event support, so that you can, for example, show notification to your users when another user makes a change to some data.

What might you pick in this scenario? CouchDB is the obvious choice, as at its core it's about syncing and replication, and you can transparently support offline usage with the client-side implementation, PouchDB.

You're building a web application where user's interactions are minimal but you serve alot of data, and the data you provide has a clear hierarchy:

This suggests:

  - good support for relations between data, to allow you to turn raw data into data structures on the database side

  - transaction support, where you can batch together a set of operations to make sure you can rollback if something goes wrong

  - redundancy, where every write you make can also be made in other places so that, if you master database falls over, you can quickly restore access

In this case, you could pick something like PostgreSQL or MySQL (yep, still a good option). Mongo also wouldn't be a bad option, although its (lack of) transaction support has had me quite frustrated recently.

To quickly cover some other things you mention:

ElasticSearch isn't a database as such – it's an engine for searching your data. If you need to provide search over a ton of data, take a look at it.

MongoDB is a document storage engine, and is generally useful, reliable and easy to set up.

Redis, LevelDB and other key-value data stores do not offer, natively, support for storing and manipulating data structures because they are just key and value stores. But, as Mikeal said, there's a community around Level (and probably Redis) that's adding these things on top – and in that sense you can 'build your own database'. 

I don't know anything about RethinkDB - at a cursory glance, it doesn't look like they've rethought much, and it's a young platform so don't expect every problem you come up with to be Googleable. You only get that with mature systems like MySQL, Postgres - but Mongo and Couch are catching up in this area. Both have active and helpful communities, like Node does.

On the hosted/self-hosted question – I personally go for hosted databases where the problem suggests it. I'm not an operations guy and I don't know about database system administration. I'm a developer, and I'm concerned with the application logic – keeping a database running, and running fast, is just a distraction. However, if you're working in a team and have servers (& ops people) available, there are good reasons to go for a self-hosted option.

As you can tell, there's a lot to picking a data store – but I think one thing's for sure: you have to base a decision on your particular problem.

Cheers,

Tom

[Stewart Mckinney]

+1

[Luke Arduini]

 Redis, LevelDB and other key-value data stores do not offer, natively, support for storing and manipulating data structures because they are just key and value stores. 

You should probably read the levelup docs dude.   

[Forrest L Norvell]

Not to mention the Redis docs.

F

On Friday, August 30, 2013, Luke Arduini wrote:

 Redis, LevelDB and other key-value data stores do not offer, natively, support for storing and manipulating data structures because they are just key and value stores. 

You should probably read the levelup docs dude.   

--

[Alexey Petrushin]

MongoDB similar to traditional RDBMS in terms that it's also an universal database applicable to lots of use cases.

CouchDB has some unique features, but, it's a specialised database, it may be a good fit for some special use cases, but it's not universal DB, and it's not a good fit for general web app. 

LevelDB - also specialised and high performant low-level DB, not for general usage.

[Alexey Petrushin]

If you want to use specialised things like CouchDB or LevelDB - you need to know how it works and why you choose it.

[phidelta]

Hi,

each option in the database space is good at different things and have very different usage profiles. The most important question you have to answer before you even think of which DB system to use or whether you even want to use one at all is:

What is my data and access profile.

For example:

 * If you never search for data, because you always have a unique identifier (primary key), then maybe you don't need a DB system, but are better off with a Key Value store.

 * If you never modify data once it has been stored, but simply write once read often, then you have a different need than if you modify your data. (Example: CouchDB gives you strong version enforcement, which you don't need in that case then at the cost of speed and complexity).

 * How much data are you expecting? Does it even need to be persisted at all? For example if you are only doing session storage, you might be better of just doing a memcached cluster, because if you calculate your data-size, you might be able to handle multiple million users with a few gigs of ram.

So the question you have asked is like: "I want to move an object, what kind of vehicle should I use"

Well first you need to think about: "What kind of object? Over what kind of terrain? Across Oceans? Off planet? At what speed? …"

So before you consider what DB to use, first consider your data, then your access patterns, then research the options, and then decide ;)

[Samora Dake]

var Newbie = require('mongodb');

I do not see any reason to use any other, especially as a newbie. You will get a lot more answers when you need them and it is the most mature no-sql db.

[Alexey Petrushin]

I wrote small article with my subjective view about how CouchDB differs from MongoDB

http://petrush.in/blog/2013/a-little-about-cochudb-and-comparison-with-mongodb/show

On Wednesday, August 28, 2013 5:35:40 PM UTC+4, Dylan Hassinger wrote:

[victorkane]

Since this is turning into a general "check out the object store and document database NoSQL options, Riak http://basho.com/riak/ should definitely be included in the discussion,

Victor Kane

http://awebfactory.com

[obastemur]

Please note that LevelDB is per process only. If this restriction doesn't suit your scenario, using one of the hosted solutions (mongo, riak, redis...) might be better.

[jmartins]

Riak +1

[Benoit Chesneau]

On Tue, Sep 17, 2013 at 4:10 AM, Alexey Petrushin <alexey.p...@gmail.com> wrote:

I wrote small article with my subjective view about how CouchDB differs from MongoDB

http://petrush.in/blog/2013/a-little-about-cochudb-and-comparison-with-mongodb/show

subjective indeed.

Saying it's harder because of using M/R in secondary indexes is subjective. Most people will see maps as a way to match documents and emit values they need to query later / keys. Which at the end especially for javascript is user give a lot of flexibility. (some should also ask himself why mpngodb added this feature later).

M/R chaining: there are some nodejs project that does that. Waiting for this feature in couchdb that will probably come soon in a way or another.

no in/place update. Well such things could be done using _update functions if you really need it while still having an append-only database. If you really care about your data you don't want to update in place except in a cache database maybe.

no sharding/scale: true for now. But actually the code coming fonm cloudant.con is actually in the process to be merged.

Popularity. true . This is true for all db backed with a lot of money anyway:

http://db-engines.com/en/ranking

Poor support  I don't see why not using Github as an authority means poor user support. You can use Jira, you can use the mailing-lists open to every one. You have an open documentation that you can patch. And support of PR from github has been considerably improved. Couchdb is also backed by one of the oldest organisation in the world.

About the  "high-availability", "scalability", "high-load" , you're saying they are not here. It all depends
what you mean when using these terms. It all depends on your usage. also. A lot of usages around will contradict your feeling.

- benoit

 

On Wednesday, August 28, 2013 5:35:40 PM UTC+4, Dylan Hassinger wrote:

Hi everybody - I am a Node newb building my first app, and trying to figure out which database system to use. Can anybody shed some light on what the major differences are between Mongo, Couch and LevelDB - and when is the right time to to use them?

Specifically, is the syntax similar between them / is it easy to switch after-the-fact?

Also wondering if anybody has suggestions for hosted database-as-a-service options? I've heard good things about MongoHQ, but not sure if there's hosted options for Couch or LevelDB. Thanks for any help!!

dylan

--

[Alexey Petrushin]

Didn't know about _update, thanks. Yea, would be nice to have sharding merged.

> Poor support  I don't see why not using Github as an authority means poor user support.

On GitHub users are just a click away (everyone have a GitHub account now) - it's easy, users will participate and report bugs and suggestions.