[Couchdb Wiki] Update of "Faq" by NoahSlater

[Apache Wiki <wi...@apache.org>]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Couchdb Wiki" for change notification.

The following page has been changed by NoahSlater:
http://wiki.apache.org/couchdb/Faq

The comment on the change is:
Copied from original CouchDB wiki

New page:
= FAQ =

A handy FAQ for all your CouchDB related questions.

If you have a question not yet answered in this FAQ please hit the edit button and add your question at the end. Check back in a few days, someone may have provided an answer.

== What is CouchDB? ==

CouchDB is a document-oriented, Non-Relational Database Management Server (NRDBMS). The [wiki:QuickOverview Quick Overview] has a high level overview of the CouchDB system.

== What is the Status of CouchDB? ==

Alpha Release. It is still missing important features, but it's usable enough for testing.

== What Does Couch Mean? ==

It's an acronym, Cluster Of Unreliable Commodity Hardware. This is a statement of Couch's long term goals of massive scalablility and high reliability on fault-prone hardware. The distributed nature and flat address space of the database will enable node partitioning for storage scalabilty (with a map/reduce style query facility) and clustering for reliability and fault tolerance.

== What Language is CouchDB Written in? ==

Erlang, a concurrent, functional programming language with an emphasis on fault tolerance. Early work on CouchDB was started in C but was replaced by Erlang OTP platform. Erlang has so far proven an excellent match for this project.

CouchDB uses Mozilla's Spidermonkey Javscript library which is written in C.

== What Platforms are Supported? ==

Most POSIX systems, this includes GNU/Linux and OS X.

Windows is not officially supported but it should work, please let us know.

== What is the License? ==

Apache 2.

== How Much Stuff can I Store in CouchDB? ==

With node partitioning, virtually unlimited. For a single database instance, the practical scaling limits aren't yet known.

== How Do I Do Sequences? ==

Or, where is my AUTO_INCREMENT?! With replication sequences are hard to realize. Sequences are often used to ensure unique identifiers for each row in a database table. CouchDB generates unique ids from its own and you can specify your own as well, so you don't really need a sequence here. If you use a sequence for something else, you might find a way to express in CouchDB in another way.

== How Do I Configure Replication? ==

To replicate a database from the CouchDB Erlang console (try ''ccouchdb -i''), type:

{{{
couch_rep:replicate("local_database_name_a", "local_database_name_b").
}}}

You can also specify a HTTP URL to a remote database:

{{{
couch_rep:replicate(
    "local_database_name_a"
    "http://remoteserver:8888/remote_database_name_b/").
}}}

Either or both databases can be remote:

{{{
couch_rep:replicate(
    "http://remoteserver:8888/remote_database_name_a/",
    "http://remoteserver:8888/remote_database_name_b/").
}}}

== How Fast are CouchDB Views? ==

It would be quite hard to give out any numbers that make much sense. From the architecture point of view, a view on a table is much like a (multi-column) index on a table in an RDBMS that just performs a quick look-up. So this theoretically should be pretty quick.

The major advantage of the architecture is, however, that it is designed for high traffic. No locking occurs is the storage module (MVCC and all that) allowing any number of parallel readers as well as serialized writes. With replication, you can even set up multiple machines for a horizontal scale-out and data partitioning (in the future) will let you cope with huge volumes of data. (See [http://jan.prima.de/~jan/plok/archives/72-Some-Context.html slide 13 of Jan Lehnardt's essay] for more on the storage module or the whole post for detailed info in general).

== Why Does CouchDB Not Use Mnesia? ==

Several reasons:

  * The first is a storage limitation of 2 gig per file.
  * The second is that it requires a validation and fixup cycle after a crash or power failure, so even if the size limitation is lifted, the fixup time on large files is prohibitive.
  * Mnesia replication is suitable for clustering, but not disconnected, distributed edits. Most of the "cool" features of Mnesia aren't really useful for CouchDB.
  * Also Mnesia isn't really a general-purpose, large scale database. It works best as a configuration type database, the type where the data isn't central to the function of the application, but is necessary for the normal operation of it. Think things like network routers, HTTP proxies and LDAP directories, things that need to be updated, configured and reconfigured often, but that configuration data is rarely very large.