You are viewing a plain text version of this content. The canonical link for it is here.
Posted to notifications@couchdb.apache.org by GitBox <gi...@apache.org> on 2019/11/19 17:28:22 UTC

[GitHub] [couchdb-documentation] nickva commented on a change in pull request #457: [RFC] Introduce CouchDB node types

nickva commented on a change in pull request #457: [RFC] Introduce CouchDB node types
URL: https://github.com/apache/couchdb-documentation/pull/457#discussion_r348064337
 
 

 ##########
 File path: rfcs/013-node-types.md
 ##########
 @@ -0,0 +1,145 @@
+---
+name: Node Types
+about: Introduce heterogeneous node types to CouchDB 4
+title: 'Node Types'
+labels: rfc, discussion
+assignees: ''
+
+---
+
+# Introduction
+
+This RFC proposes the ability to have different node types in CouchDB 4+. This
+would improve performance and allow for a more efficient use of resources.
+
+## Abstract
+
+Previously, in CouchDB 2 and 3, cluster functionality was uniformly distributed
+amongst the nodes. Any node could accept HTTP requests, run replication jobs
+and build secondary indices. With the FDB-based topology, CRUD operations have
+lower resource needs and so it could be useful to have a heterogeneous
+topology, where for example, CRUD operations run on lower capacity nodes, and a
+few higher capacity nodes handle replication or indexing jobs.
+
+
+## Requirements Language
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
+document are to be interpreted as described in
+[RFC 2119](https://www.rfc-editor.org/rfc/rfc2119.txt).
+
+## Terminology
+
+*node type* : A label used to designate a subset of CouchDB functionality.
+
+---
+
+# Detailed Description
+
+## Node Types
+
+A node type is a string description of a some internal CouchDB
+functionality. These are the initially defined node types:
+
+ * "api_frontend" : Indicates this node can accept HTTP API requests.
+ * "view_indexing" : Indicates this node can build map/reduce view indices.
+ * "search_indexing": Indicates this node can build search indices.
+ * "replication" : Indicates this node can run replication jobs.
+
+Users can configure CouchDB nodes with any combination of those types.
+
+## Configuration
+
+Configuration MAY be specified in the standard `.ini` files or via environment
+variables. Environment variables have a higher priority, and override the
+`.ini` based settings. By default, if not configured either via `.ini` files or
+environment variable, a node type is considered enabled i.e. the value defaults
+to `true`.
+
+### Configuration Files
+
+Configuration MUST be specified in the `[node_types]` section. Each type label,
+if specified, MUST be on a separate line and have a boolean value.
+
+Example:
+
+```
+[node_types]
+
+api_frontend = true
+view_indexing = false
+search_indexing = false
+replication = false
+
+```
+
+### Environment Variables
+
+Since in some cases it is easier to set environment variables than tweak `.ini`
+files, node types MAY be set via environment variables using the
+`COUCHDB_NODE_TYPE_` prefix. The prefix SHOULD be followed by the type label.
+If the value of the variable is `"false"` the functionality indicated will be
+disabled on that node. Any other value, indicates `true`.
+
+Example:
+
+`COUCHDB_NODE_TYPE_API_FRONTEND=false COUCHDB_NODE_TYPE_VIEW_INDEXING=true ...`
+
+## Implementation
+
+Implementation should be minimally invasive, at least for the node types listed
+above.
+
+ * `"api_frontend"` would disable `chttpd` application or its top supervisor.
+
+ * All background tasks in FDB are executed via the `couch_jobs` framework. The
+top level application supervisors typically have a separate `gen_server` in
+charge of accepting jobs and executing them. The implementation then would be
+as simple as having a `case` statement around the worker's `start_link()`
+function, such that if that background job type is `"false"`, that `gen_server`
+would return the `ignore` value to the supervisor.
+
+# Advantages and Disadvantages
+
+## Disadvantages
+
+ - More configuration-state complexity
+
+## Advantages
+
+ - Ability to utilize hardware resources better
+ - Possibly better security and isolation by running indexing and replication
+   jobs in an isolated environment inaccessible from the outside
+
+# Key Changes
+
+ - Heterogeneous node types
+ - New configuration section
+ - New configuration environment variables
+
+## Applications and Modules Affected
+
+ - chttpd
+ - fabric
+ - couch_views
 
 Review comment:
   Good call

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
users@infra.apache.org


With regards,
Apache Git Services