4 ms·

You should think of CouchDB as the Web2.0 equivalent of Microsoft Access. It's good for running a simple web-app off, because you can store the HTML, JS and the

by Maro 17y ago

You should think of CouchDB as the Web2.0 equivalent of Microsoft Access. It's good for running a simple web-app off, because you can store the HTML, JS and the data all in CouchDB (I think). So one use-case may be a simple billing system for your local surf shop that is sure as hell not going to store a lot of data or handle a lot of load. I got this impression from a Damien Katz talk. (I think the use-case they use is a recipe app.)

peregrine 17y ago
Well with the load balancer, and continuous replication you could theoretically scale to any level easily.
- jbellis 17y ago
  No. CouchDB doesn't support partitioning, so all your replicas need to be able to handle the full write volume.
  - boorad 17y ago
    It will soon. We have an 8-node cluster running in PROD right now. A Dynamo-like layer provides consistent hashing, partitioning, read/write quorum constants and the like.
- Maro 17y ago
  You've got something that is inherently an order of magnitude slower than other solutions. Why would you bother to try to scale it? It's not the right tool for the job.
AndrewO 17y ago
> you can store the HTML, JS and the data all in CouchDB I think you're talking of CouchApp, which allows you to create apps like that on top of CouchDB. Of course, if that was the maximum of what one was trying to do, one could get similar functionality from an RDBMS, some simple routing rules, and a CGI script that served content straight from the DB. I guess my point is that there's not really anything intrinsic to CouchDB that makes this possible: it's a pretty short and inviting conceptual leap from "this DB does everything through an HTTP interface" to "I can run my entire application from this DB". My worry (and I'm not accusing the parent of this) is that that misses out on all of the other things that CouchDB offers (especially the ability to merge DBs that have been disconnected for long periods, which often gets lost behind the HTTP interface and MapReduce hand-waving).
logicalmind 17y ago
The difference being that if you want to answer a question like "what hour of the day is my store busiest?" you would have to write a MapReduce function in Erlang for couchdb. Where alternatively, anyone with minimal knowledge can figure out that query in SQL.
- tumult 17y ago
  You mean, they would have to write a simple JavaScript function. No Erlang involved in writing CouchDB views.

by Maro 17y ago

peregrine 17y ago

Well with the load balancer, and continuous replication you could theoretically scale to any level easily.

jbellis 17y ago
No. CouchDB doesn't support partitioning, so all your replicas need to be able to handle the full write volume.
- boorad 17y ago
  It will soon. We have an 8-node cluster running in PROD right now. A Dynamo-like layer provides consistent hashing, partitioning, read/write quorum constants and the like.
Maro 17y ago
You've got something that is inherently an order of magnitude slower than other solutions. Why would you bother to try to scale it? It's not the right tool for the job.

AndrewO 17y ago

> you can store the HTML, JS and the data all in CouchDB I think you're talking of CouchApp, which allows you to create apps like that on top of CouchDB. Of course, if that was the maximum of what one was trying to do, one could get similar functionality from an RDBMS, some simple routing rules, and a CGI script that served content straight from the DB. I guess my point is that there's not really anything intrinsic to CouchDB that makes this possible: it's a pretty short and inviting conceptual leap from "this DB does everything through an HTTP interface" to "I can run my entire application from this DB". My worry (and I'm not accusing the parent of this) is that that misses out on all of the other things that CouchDB offers (especially the ability to merge DBs that have been disconnected for long periods, which often gets lost behind the HTTP interface and MapReduce hand-waving).

logicalmind 17y ago

The difference being that if you want to answer a question like "what hour of the day is my store busiest?" you would have to write a MapReduce function in Erlang for couchdb. Where alternatively, anyone with minimal knowledge can figure out that query in SQL.

tumult 17y ago
You mean, they would have to write a simple JavaScript function. No Erlang involved in writing CouchDB views.