You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by sjtirtha <sj...@gmail.com> on 2009/08/20 22:05:25 UTC
CouchDB vs. SQL
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?
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.
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.
4. Can I build a View based from other View?
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 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.
regards,
Steve
Re: CouchDB vs. SQL
Posted by Nicholas Orr <ni...@zxgen.net>.
On Fri, Aug 21, 2009 at 7:22 AM, sjtirtha <sj...@gmail.com> 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.
>
John Wood of TextMe kept notes on his migration to CouchDB from MySQL.
I think it would interest you:
"The wall was quickly approaching. After only a few short years, several of
our database tables had over a million rows, a handful had over 10 million,
and a few had over 30 million." Read More:
http://johnpwood.net/2009/06/15/couchdb-a-case-study/
Nick
Re: CouchDB vs. SQL
Posted by Robert Koberg <ro...@gmail.com>.
On Aug 20, 2009, at 2:22 PM, sjtirtha wrote:
>
> 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.
This is false. XPath (usually through XQuery) operates directly/
natively on the DB similar to how couch run javascript runs on it. You
were doing it wrong.
Re: CouchDB vs. SQL
Posted by Chris Anderson <jc...@apache.org>.
On Thu, Aug 20, 2009 at 2:22 PM, sjtirtha<sj...@gmail.com> 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:
http://www.cmlenz.net/archives/2007/10/couchdb-joins
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,
Chris
>
> 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 <ni...@borwankar.com>wrote:
>
>> Hi Steve see my comments below
>> 37% of all statistics are made up on the spot
>>
>> -------------------------------------------------------------------------------------
>> Nitin Borwankar
>> nborwankar@gmail.com
>>
>>
>> On Thu, Aug 20, 2009 at 4:05 PM, sjtirtha <sj...@gmail.com> 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
http://jchrisa.net
http://couch.io
Re: CouchDB vs. SQL
Posted by sjtirtha <sj...@gmail.com>.
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?
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 <ni...@borwankar.com>wrote:
> Hi Steve see my comments below
> 37% of all statistics are made up on the spot
>
> -------------------------------------------------------------------------------------
> Nitin Borwankar
> nborwankar@gmail.com
>
>
> On Thu, Aug 20, 2009 at 4:05 PM, sjtirtha <sj...@gmail.com> 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
> >
>
Re: CouchDB vs. SQL
Posted by Nitin Borwankar <ni...@borwankar.com>.
Hi Steve see my comments below
37% of all statistics are made up on the spot
-------------------------------------------------------------------------------------
Nitin Borwankar
nborwankar@gmail.com
On Thu, Aug 20, 2009 at 4:05 PM, sjtirtha <sj...@gmail.com> 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
>