I hear a lot about couchdb, but after reading some documents about it, I still don't get why to use it and how.
Could you clarify this mystery for me?
+12
A:
It's a non-relational database, open-source, distributed (incremental, bidirectional replication), schema-free. A CouchDB database is a collection of documents; each document is a bunch of string "keys" and corresponding "values" (which can be numbers, strings, lists, dates, ...). You can have indices, queries, views.
If a relational DB feels confining to you (you find schemas too rigid, can't spread the DB engine work around a very large numbers of servers, etc), CouchDB is worth considering (it's one of the most interesting of the many non-relational DBs that are emerging these days).
But if all of your work happily fits in a relational database, that's what you probably want to continue using for production work (even though "playing around" with some non-relational DB is still well worth your time, just for personal growth and edification, that's quite different from transferring huge production systems over from a relational DB!-).
Alex Martelli
2009-10-12 02:47:05
Also note that CouchDB is versionned : every version of every document is kept and you can revert to a previous version easily.
Pierre Bourdon
2009-10-12 02:50:34
@delroth, You are wrong about reverting to previous versions. From couchdb API Reference: "You cannot rely on document revisions for any other purpose than concurrency control.Due to compaction, revisions may disappear at any time. You cannot use them for a client revision system. "
abbot
2009-10-12 08:39:43
+1
A:
To quote from wikipedia
It is not a relational database management system. Instead of storing data in rows and columns, the database manages a collection of JSON documents. The documents in a collection need not share a schema, but retain query abilities via views.
CouchDB provides a different model for data storage than a traditional relational database in that it does not represent data as rows within tables, instead it stores data as "documents" in JSON format.
This difference in data storage model is what differenciates CouchDB from products like MySQL and SQL Server.
In terms of programatic access to CouchDB, it exposes a REST API which you can access by sending HTTP requests from your code
I hope this has been somewhat helpful, though I acknowlege it may not be given my minimal familiarity with the product
Crippledsmurf
2009-10-12 03:00:35
+1
A:
I'm far from an expert(all I've done is play around with it some...) but here's how I'm thinking of using it:
Usually when I'm designing an app I've got a bunch of app servers behind a load balancer. Often times, I've got sticky sessions so that each user will go back to the same app server during that session. What I'm thinking of doing is have a couchdb instance tied to each app server.
That way you can use that local couchdb to access user preferences, product data...whatever data you've got that doesn't have to be perfectly up to date.
So...now you've got data on these local CouchDBs. CouchDB allows replication. So, every fixed time period, merge the data back(every X seconds?) into it's peers to keep them up to date.
As a whole you shouldn't have to worry about conflicts b/c each appserver has it's own CouchDB and users are attached to the appserver, and you've got eventual consistency because you've got replication.
Does that answer your question?
Michael Kohout
2009-10-12 08:05:56
If I understand well, CouchDB is build inside Apache ? So as soon as you get a connexion to an apache server, you are sure to be connected to the good CouchDB server ? Why is it more difficult to do that with an SQL server ?
Natim
2009-10-12 08:45:10
1) No, couchDB isn't built inside apache...but what I'm thinking of is tying one couchdb to one appserver instance. Since couchDB nodes will, in theory, be replicated, we want to prevent any conflicts. Load balancers and sticky sessions are one way to make sure data changes stay in one node until it's propagated to the rest of the nodes. 2) Well, in my mind, yes. I wouldn't expose couchDB to outside your firewall because at present there is no security preventing any person from going through and messing with couchdb data.3) It's not more difficult...I'd say they are both easy.
Michael Kohout
2009-10-13 05:22:21
+1
A:
A good example is when you say have to deal with people data in either a website or application. If you set off wishing to design the data and keep the individuals' information seperate, that makes a good case for CouchDB, which stores data in documents rather than relational tables. In a production deployment, my users may end up adding adhoc data about 10% of the people and some other funny details for another selected 5%. In a relational context, this could add up to loads of redundancy but not for CouchDB.
And it's not just about the fact that CouchDB is non-relational: if you're too focus on that, you're missing the point. CouchDB is plugged into the web, all you need to start with is HTTP for creating and making queries (GET/PUT/POST/DELETE...), and it's RESTful, plus the fact that it's portable and great for peer to peer sharing. It can also serve up web applications in what is termed as 'CouchApps', where CouchDB totally holds the images, CSS, markup as data stored under special documents called design documents.
Check out this collection of videos introducing non-relational databases, the one on CouchDB should give you a better idea: http://tinyurl.com/yztdkor
Pydroid
2009-11-17 18:17:25