couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: CouchDB vs. SQL
Date Fri, 21 Aug 2009 01:39:34 GMT
On Thu, Aug 20, 2009 at 2:22 PM, sjtirtha<> wrote:
> Hi Nitin,
> thanks for the explanation. I meant by SQL, for example MySQL/PostgreSQL.
> But as you told me, this should not be a show-stopper. Is CouchDB able to
> handle some huge application like Flicker/Facebook?
> Although, I will never come to develop such a huge application.
> Regarding your comment to the document model normalization is because, is
> because I looked what happens with OODBMS, where there is no clear modeling
> normalization and it ends up that they can/could not beat RDBMS, in term of
> modeling.  The same happens also for XML DB. Both of them were only hype,
> but I don't really see they can compete with RDBMS.
> I've worked for a while with one of the best XML DB. Since there is no clear
> modelling normalization, some projects that I know and also my own project
> did not work very well. Either some data are modeled in a huge XML document
> or some of them are chunked into several small XML documents. And also the
> Query language XPath does not perform at all and it uses also HTTP. The
> performance was bad, compare to RDBMS.
> Since CouchDB is a document-oriented DB, can somebody defines what is
> document?
> Is user data (username, password, mobile, room, etc) is document?
> Is there any case where we use better RDBMS for storing some data and store
> other document-oriented data in CouchDB?

There are two main kinds of documents, in my experience. The first
kind is like something a word processor would save, or a user profile.
With that sort of data, you want to denormalize "until it hurts".
Basically you want to be able to load the document in one request, and
get something that makes sense enough to display.

There is a technique for creating "virtual" documents by using views
to collate data together. You could use this to store each attribute
of your user profiles in a different document, but I wouldn't
recommend it. Virtual documents are useful in cases where the
presented view will be created by merging the work of different
authors - for instance the reference example, a blog post and it's
comments in one query:

This "virtual document" idea takes us to the other kind of document -
the event log. Use this is cases where you don't trust user input, or
need to trigger an asynchronous job. This records the user action as
an event, so only minimal validation needs to occur at save-time. It's
when you load the doc for further work that you'd check for complex
relational-style constraints.

You can treat documents as state machines, with a combination of user
input and background processing managing document state. You'd use a
view by state to pull out the relevant document - changing it's state
would move it in the view.

This approach is also useful for logging - combined with the batch=ok
performance hint, CouchDB should make a fine log store, and reduce
views are ideal for finding things like average response time or
highly-active users.

Hope that clears things up a little,

> Is CouchDB going to release a standard API for different programming
> languages?
> Currently, I'm playing with python, where there are three open source API in
> the internet, that I can use.
> And I assume non of them are standard API from CouchDB it self.
> I just compared it with MySQL, where they have a standard API to access
> MySQL DB using different languages.
> I hope, people here are not angry with me, because I'm always arguing the
> CouchDB. But from the roughly perspective I like couchDB very well. I just
> want to share some of my thought and get some answers for my questions.
> Steve
> On Thu, Aug 20, 2009 at 10:36 PM, Nitin Borwankar <>wrote:
>> Hi Steve see my comments below
>> 37% of all statistics are made up on the spot
>> -------------------------------------------------------------------------------------
>> Nitin Borwankar
>> On Thu, Aug 20, 2009 at 4:05 PM, sjtirtha <> wrote:
>> > Hi people,
>> >
>> > I'm new in CouchDB. Before I looked into CouchDB, I was kind of
>> > investigating what other no-SQL DB exists in the world.
>> > There are MongoDB, Hadoop, Hypertable, Cassandra (correct me if I
>> > misspelled
>> > any names).
>> > And I found out the two big no-SQL DBs are Hadoop and CouchDB. Hadoop is
>> > very interesting, but it is very big and complicated.
>> > On the other hand, from some presentation I have the impression, Hadoop
>> > should not use for a normal web application.
>> > It is more for analytics data like Google and Yahoo do.
>> >
>> > So I came to  CouchDB, which is also very interesting from the design and
>> > implementing language(Erlang) point of view.
>> > But somehow, it still does not 100% convince me to replace SQL with
>> > CouchDB.
>> >
>> > One of the reason I like CouchDB very much is the  schemaless thing.
>> >
>> > But I'm still not sure regarding following points:
>> > 1. performance. It is faster or same fast as SQL?
>> Faster than which database on what machine - SQL is a language.
>> So this is not a well formed question.  However if your overal question is
>> does CouchDB performance suck - the answer is
>> no performance will not be  the show-stopper amongst all the other concerns
>> you have listed.
>> >
>> > 2. how can I reduce the data tranfer between my application and CouchDB,
>> > when CouchDB always sends the whole document, although I only need a part
>> > of
>> > it.
>> >    This can be done very easy in SQL by selecting which columns should be
>> > retreived from DB.
>> CouchDB has views which alow you to select which "columns" or attributes to
>> send back - it is not true that CouchDB sends back the whole document in
>> general.
>> >
>> > 3. CouchDB support MVCC which is very good. But how is it, if I really
>> want
>> > to lock a document and other people should not be able to write.
>> There is currently no concept of a lock  that can be associated with a user
>> - in general though this may be two different questions
>> - do oyu not want to allow anyone else to write ever? This is then a
>> permissions issue. Couch does not currenty have a full featured permissions
>> system so you will need to layer this on with middle tier logic.
>> If you want to not have the other person clobber your writes, MVCC takes
>> care of this and will append the other persons edits which you will not see
>> until later.
>> >
>> > 4. Can I build a View based from other View?
>> Not strictly but if you want to use a View to do rendering in other code
>> look for "show and list" on the wiki.
>> >
>> > 5. Is there any Document Model Normalization as we all know in relational
>> > DB? Because the Model Normalization from relational DB is a basic theory
>> > how
>> > the relational model should look like. In CouchDB, it looks like that I
>> can
>> > do everything I want, but it may be a drawback for me in the future, if
>> I'm
>> > not design the document model very well.
>> >
>> CouchDB is a document db so it doesn't have a built in normalization model
>> just as an RDBMS doesn't have a built in document model.  However it is
>> possible to mimic foreign keys, many-many relations etc in limited ways -
>> again look on the wiki.
>> >
>> > CouchDB always put HTTP and Restfull as a very important things. But I
>> > don't
>> > thing it is really complicated for SQL DB vendor to build a HTTP/RESTful
>> > communication layer to their DB.
>> >
>> In theory this is true - and RDBMS's have been around for many years, but
>> they don't seem to have managed to do it - so in practice this appears not
>> be simple or maybe they just don't think it is important.
>> Good Luck with CouchDB - hope you find it useful,
>> Nitin
>> >
>> > regards,
>> > Steve
>> >

Chris Anderson

View raw message