couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <>
Subject [Couchdb Wiki] Update of "Partitioning proposal" by DavidVanCouvering
Date Fri, 27 Feb 2009 23:17:40 GMT
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 DavidVanCouvering:

   * Increase total storage capacity by spreading the storage across multiple machines
   * Make the partitioned database appear as a single database via the HTTP API, keeping compatibility
with existing client implementations
   * Allow the partition topology to be configurable to support different performance needs
+ == Scenarios/Use Cases ==
+ Here are the initial use cases we want to support, and then subsequent use cases we want
to target.
+ I am using the "CouchDB system" to describe the overall server system, as this may involve
both a server and some kind of proxy that knows how to route requests to the proper node,
plus any other moving parts that may need to be introduced (hopefully not too many).
+ === Initial Use Cases ===
+  * A user finds that a single machine is not big enough to hold all of their data or does
not give them the performance they need, and wants to split the database across two or more
machines.  '''While the system is still running''', the user configures the CouchDB system
to specify the machines to be used, and the CouchDB system automatically splits the data across
the new nodes.  All client requests to the server continue to work as before.  
+  * A user finds that the current cluster configuration is not sufficient and wants to grow
the cluster.  '''While the system is still running''', the user reconfigures the CouchDB system
to include more machines, and the CouchDB system automatically repartitions the data as needed
while continuing to service incoming client requests.
+ === Later Use Cases ===
+  * A node in the cluster goes down (either by accident or for planned maintenance), but
the CouchDB system (and all data it serves) continues to be available.
+  * A user wants to upgrade their CouchDB system without having to bring the system down.
 The user follows a reasonably easy procedure to upgrade each node in the cluster, and the
system continues servicing requests.
+  * A node comes back up, and the CouchDB system automatically brings that node back into
the cluster.
+  * A user decides to reduce the size of the cluster.  The user reconfigures the system,
and the system automatically repartitions the data to the smaller cluster while continuing
to service requests.
+  * The CouchDB system is running out of space or other resources.  The system warns the
user that space is becoming scarce
+  * If a CouchDB system is running out of a resource, it degrades gracefully rather than
failing suddenly or catastrophically
  == Initial Implementation Thoughts ==

View raw message