Questions[couchdb](server)

I'm hosting CouchDB databases on Amazon EC2, and I was wondering if I can have better I/O performance (and better disk utilization, of course) if I use a filesystem that supports compression. I remember reading somewhere that the future versions of CouchDB would support data compression and I was wondering if I could get that feature now if I just compress my filesystem. I am looking at using small instances, but large ones aren't out of the question either. I am afraid the compression would kill the CPU on those instances, but I can't tell until I test that.

Do I sound too crazy? Someone tried that already?

I have done multiple installs of CouchDB using sudo aptitude install couchdb sudo ap-get install couchdb

and more recently based on the instructions found at L http://wiki.apache.org/couchdb/Installing_on_Ubuntu

May I know how do I uninstall or remove all the above installations?

Best Regards. +++++++++++++++++++UPDATE++++++++++++++++++++++++

I've tried running the following commands:

apt-get remove couchdb
apt-get purge couchdb

but received the following errors:

(Reading database ... 39814 files and directories currently installed.)
Removing couchdb ...
invoke-rc.d: initscript couchdb, action "stop" failed.
dpkg: error processing couchdb (--remove):
 subprocess installed pre-removal script returned error exit status 1
invoke-rc.d: initscript couchdb, action "start" failed.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 couchdb
E: Sub-process /usr/bin/dpkg returned an error code (1)

May I know how do i fix this?

ON issuing the command : dpkg -l | grep couchdb I received the following response:

rF  couchdb                          0.10.0-1ubuntu2                            RESTful document oriented database, system D
iF  couchdb-bin                      0.10.0-1ubuntu2                            RESTful document oriented database, programs

How do i uninstall CouchDB ? I think there's some file corruption?

Currently, web application need to offer some kind of cross-domain HTTP header to access data on other domain: http://openfontlibrary.org/wiki/Web_Font_linking_and_Cross-Origin_Resource_Sharing

Is there any way to configure CouchDB to support unlimited cross-domain access? I'm using the db in-house purpose only.

I'm running a localhost CouchDB instance using CouchDBX on my Mac, proxied behind Apache 2 using the ProxyPass directive:

<VirtualHost *:80>
    ServerName playlick # points to localhost in /etc/hosts
    DocumentRoot "/Users/james/Sites/playlick"
    ProxyPass /data http://localhost:5984
    ProxyPassReverse /data http://localhost:5984
</VirtualHost>

If I try to hit my Couch instance at http://playlick/data while it's not running I get a 503 Service Temporarily Unavailable error, as would be expected.

I then start up the Couch server and hit the same URL, but I still get the error until I restart the Apache proxy.

If on the other hand, I start up the Couch instance before hitting that URL, everything works fine without having to touch Apache.

So it seems as though the 503 error is cached until the Apache process is restarted. How do I stop this from happening?

OR, if that's not possible, how do I force Apache to restart when I start up the Couch instance in the CouchDBX GUI app?

I want to migrate an existing application that has approx. 10 million records stored in a relational database to CouchDB. The thing that I love about CouchDB is easy replication and fast cached views. The thing I don't like is the write and view creation speeds which will be very slow with 10 million documents.

One idea I have to get around these potential bottlenecks is to have three CouchDB instances:

1. Write only instance: This is the master instance. Our single point of truth. Only updates, inserts and deletes allowed here. There are no reads and no views on this instance.
2. View creation only instance: Only used to create and cache views. There are no reads or writes on this instance.
3. Read only instance: Read access via replicated views.

Instance 2 is replicated from instance 1. Since there will not be any applications that use instance 2, it makes it feasible to create new views without affecting production applications.

Instance 3 is replicated from instance 2 which includes all the cached views.

Is this a feasible solution?