You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by robertkowalski <gi...@git.apache.org> on 2015/03/15 23:28:49 UTC
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
GitHub user robertkowalski opened a pull request:
https://github.com/apache/couchdb-mem3/pull/8
change readme for the couchdb project
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/robertkowalski/couchdb-mem3 readme
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/couchdb-mem3/pull/8.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #8
----
commit abb00f0c972217936048a1b8f61baa8b28efe336
Author: Robert Kowalski <ro...@kowalski.gd>
Date: 2015-03-15T22:27:26Z
change readme for the couchdb project
----
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by robertkowalski <gi...@git.apache.org>.
Github user robertkowalski commented on the pull request:
https://github.com/apache/couchdb-mem3/pull/8#issuecomment-81966516
ok second try :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on a diff in the pull request:
https://github.com/apache/couchdb-mem3/pull/8#discussion_r26462801
--- Diff: README.md ---
@@ -1,33 +1,42 @@
## mem3
-Mem3 is the node membership application for clustered [CouchDB][1]. It is used in [BigCouch][2] and tracks two very important things for the cluster:
+Mem3 is the node membership application for clustered [CouchDB][1]. It is used
+in CouchDB since version 2.0 and tracks two very important things for the
+cluster:
1. member nodes
2. node/shards mappings for each database
-Both the nodes and shards are tracked in node-local couch databases. Shards are heavily used, so an ETS cache is also maintained for low-latency lookups. The nodes and shards are synchronized via continuous CouchDB replication, which serves as 'gossip' in Dynamo parlance. The shards ETS cache is kept in sync based on membership and database event listeners.
-
-A very important point to make here is that BigCouch does not necessarily divide up each database into equal shards across the nodes of a cluster. For instance, in a 20-node cluster, you may have the need to create a small database with very few documents. For efficiency reasons, you may create your database with Q=4 and keep the default of N=3. This means you only have 12 shards total, so 8 nodes will hold none of the data for this database. Given this feature, we even shard use out across the cluster by altering the 'start' node for the database's shards.
-
-Splitting and merging shards is an immature feature of the system, and will require attention in the near-term. We believe we can implement both functions and perform them while the database remains online.
+Both the nodes and shards are tracked in node-local couch databases. Shards
+are heavily used, so an ETS cache is also maintained for low-latency lookups.
+The nodes and shards are synchronized via continuous CouchDB replication,
+which serves as 'gossip' in Dynamo parlance. The shards ETS cache is kept in
+sync based on membership and database event listeners.
+
+A very important point to make here is that CouchDB >= 2.0 does not
+necessarily divide up each database into equal shards across the nodes of a
+cluster. For instance, in a 20-node cluster, you may have the need to create
+a small database with very few documents. For efficiency reasons, you may
+create your database with Q=4 and keep the default of N=3. This means you
+only have 12 shards total, so 8 nodes will hold none of the data for this
+database. Given this feature, we even shard use out across the cluster by
+altering the 'start' node for the database's shards.
+
+Splitting and merging shards is an immature feature of the system, and will
+require attention in the near-term. We believe we can implement both
+functions and perform them while the database remains online.
### Getting Started
-Mem3 requires R13B03 or higher and can be built with [rebar][6], which comes bundled in the repository. Rebar needs to be able to find the `couch_db.hrl` header file; one way to accomplish this is to set ERL_LIBS to point to the apps
-subdirectory of a bigcouch checkout, e.g.
+Mem3 requires R13B03 or higher and can be built with [rebar][2], which comes
+bundled in the repository. Rebar needs to be able to find the `couch_db.hrl`
+header file; one way to accomplish this is to set ERL_LIBS to point to the
+apps subdirectory of a CouchDB checkout, e.g.
- ERL_LIBS="/usr/local/src/bigcouch/apps" ./rebar compile
+ ERL_LIBS="/usr/local/src/couchdb/apps" ./rebar compile
### License
[Apache 2.0][3]
-### Contact
- * [http://cloudant.com][4]
- * [info@cloudant.com][5]
-
-[1]: http://couchdb.apache.org
-[2]: http://github.com/cloudant/bigcouch
-[3]: http://www.apache.org/licenses/LICENSE-2.0.html
-[4]: http://cloudant.com
-[5]: mailto:info@cloudant.com
-[6]: http://github.com/basho/rebar
+[1]: http://couchdb.apache.org [2]: http://github.com/rebar/rebar [3]:
--- End diff --
Oh no! Someone had stole newlines here!
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on a diff in the pull request:
https://github.com/apache/couchdb-mem3/pull/8#discussion_r26453600
--- Diff: README.md ---
@@ -1,33 +1,26 @@
## mem3
-Mem3 is the node membership application for clustered [CouchDB][1]. It is used in [BigCouch][2] and tracks two very important things for the cluster:
+Mem3 is the node membership application for clustered [CouchDB][1]. It is used in CouchDB version >= 2.0 and tracks two very important things for the cluster:
1. member nodes
2. node/shards mappings for each database
Both the nodes and shards are tracked in node-local couch databases. Shards are heavily used, so an ETS cache is also maintained for low-latency lookups. The nodes and shards are synchronized via continuous CouchDB replication, which serves as 'gossip' in Dynamo parlance. The shards ETS cache is kept in sync based on membership and database event listeners.
-A very important point to make here is that BigCouch does not necessarily divide up each database into equal shards across the nodes of a cluster. For instance, in a 20-node cluster, you may have the need to create a small database with very few documents. For efficiency reasons, you may create your database with Q=4 and keep the default of N=3. This means you only have 12 shards total, so 8 nodes will hold none of the data for this database. Given this feature, we even shard use out across the cluster by altering the 'start' node for the database's shards.
+A very important point to make here is that CouchDB >= 2.0 does not necessarily divide up each database into equal shards across the nodes of a cluster. For instance, in a 20-node cluster, you may have the need to create a small database with very few documents. For efficiency reasons, you may create your database with Q=4 and keep the default of N=3. This means you only have 12 shards total, so 8 nodes will hold none of the data for this database. Given this feature, we even shard use out across the cluster by altering the 'start' node for the database's shards.
--- End diff --
How about split long text by right 80 chars margin?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on a diff in the pull request:
https://github.com/apache/couchdb-mem3/pull/8#discussion_r26453597
--- Diff: README.md ---
@@ -1,33 +1,26 @@
## mem3
-Mem3 is the node membership application for clustered [CouchDB][1]. It is used in [BigCouch][2] and tracks two very important things for the cluster:
+Mem3 is the node membership application for clustered [CouchDB][1]. It is used in CouchDB version >= 2.0 and tracks two very important things for the cluster:
--- End diff --
May be a little bit human friendly?
"It is used in CouchDB since 2.0 version"
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by robertkowalski <gi...@git.apache.org>.
Github user robertkowalski commented on the pull request:
https://github.com/apache/couchdb-mem3/pull/8#issuecomment-81991755
merged as fb5f56c21a9d855c1eff2e1fdadadd940213bffe and f62d43836972b2317784c397e69082a0850d74f4
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by robertkowalski <gi...@git.apache.org>.
Github user robertkowalski commented on the pull request:
https://github.com/apache/couchdb-mem3/pull/8#issuecomment-81324070
done :)
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by asfgit <gi...@git.apache.org>.
Github user asfgit closed the pull request at:
https://github.com/apache/couchdb-mem3/pull/8
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on a diff in the pull request:
https://github.com/apache/couchdb-mem3/pull/8#discussion_r26462778
--- Diff: README.md ---
@@ -1,33 +1,42 @@
## mem3
-Mem3 is the node membership application for clustered [CouchDB][1]. It is used in [BigCouch][2] and tracks two very important things for the cluster:
+Mem3 is the node membership application for clustered [CouchDB][1]. It is used
+in CouchDB since version 2.0 and tracks two very important things for the
+cluster:
1. member nodes
2. node/shards mappings for each database
-Both the nodes and shards are tracked in node-local couch databases. Shards are heavily used, so an ETS cache is also maintained for low-latency lookups. The nodes and shards are synchronized via continuous CouchDB replication, which serves as 'gossip' in Dynamo parlance. The shards ETS cache is kept in sync based on membership and database event listeners.
-
-A very important point to make here is that BigCouch does not necessarily divide up each database into equal shards across the nodes of a cluster. For instance, in a 20-node cluster, you may have the need to create a small database with very few documents. For efficiency reasons, you may create your database with Q=4 and keep the default of N=3. This means you only have 12 shards total, so 8 nodes will hold none of the data for this database. Given this feature, we even shard use out across the cluster by altering the 'start' node for the database's shards.
-
-Splitting and merging shards is an immature feature of the system, and will require attention in the near-term. We believe we can implement both functions and perform them while the database remains online.
+Both the nodes and shards are tracked in node-local couch databases. Shards
+are heavily used, so an ETS cache is also maintained for low-latency lookups.
+The nodes and shards are synchronized via continuous CouchDB replication,
+which serves as 'gossip' in Dynamo parlance. The shards ETS cache is kept in
+sync based on membership and database event listeners.
+
+A very important point to make here is that CouchDB >= 2.0 does not
--- End diff --
>= (;
However, here no need "since" imho an even version mention. Just CouchDB.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on the pull request:
https://github.com/apache/couchdb-mem3/pull/8#issuecomment-81990105
LGFM
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] couchdb-mem3 pull request: change readme for the couchdb project
Posted by kxepal <gi...@git.apache.org>.
Github user kxepal commented on a diff in the pull request:
https://github.com/apache/couchdb-mem3/pull/8#discussion_r26453604
--- Diff: README.md ---
@@ -1,33 +1,26 @@
## mem3
-Mem3 is the node membership application for clustered [CouchDB][1]. It is used in [BigCouch][2] and tracks two very important things for the cluster:
+Mem3 is the node membership application for clustered [CouchDB][1]. It is used in CouchDB version >= 2.0 and tracks two very important things for the cluster:
1. member nodes
2. node/shards mappings for each database
Both the nodes and shards are tracked in node-local couch databases. Shards are heavily used, so an ETS cache is also maintained for low-latency lookups. The nodes and shards are synchronized via continuous CouchDB replication, which serves as 'gossip' in Dynamo parlance. The shards ETS cache is kept in sync based on membership and database event listeners.
-A very important point to make here is that BigCouch does not necessarily divide up each database into equal shards across the nodes of a cluster. For instance, in a 20-node cluster, you may have the need to create a small database with very few documents. For efficiency reasons, you may create your database with Q=4 and keep the default of N=3. This means you only have 12 shards total, so 8 nodes will hold none of the data for this database. Given this feature, we even shard use out across the cluster by altering the 'start' node for the database's shards.
+A very important point to make here is that CouchDB >= 2.0 does not necessarily divide up each database into equal shards across the nodes of a cluster. For instance, in a 20-node cluster, you may have the need to create a small database with very few documents. For efficiency reasons, you may create your database with Q=4 and keep the default of N=3. This means you only have 12 shards total, so 8 nodes will hold none of the data for this database. Given this feature, we even shard use out across the cluster by altering the 'start' node for the database's shards.
Splitting and merging shards is an immature feature of the system, and will require attention in the near-term. We believe we can implement both functions and perform them while the database remains online.
### Getting Started
-Mem3 requires R13B03 or higher and can be built with [rebar][6], which comes bundled in the repository. Rebar needs to be able to find the `couch_db.hrl` header file; one way to accomplish this is to set ERL_LIBS to point to the apps
-subdirectory of a bigcouch checkout, e.g.
+Mem3 requires R13B03 or higher and can be built with [rebar][2], which comes bundled in the repository. Rebar needs to be able to find the `couch_db.hrl` header file; one way to accomplish this is to set ERL_LIBS to point to the apps
+subdirectory of a CouchDB checkout, e.g.
- ERL_LIBS="/usr/local/src/bigcouch/apps" ./rebar compile
+ ERL_LIBS="/usr/local/src/couchdb/apps" ./rebar compile
### License
[Apache 2.0][3]
-### Contact
- * [http://cloudant.com][4]
- * [info@cloudant.com][5]
-
[1]: http://couchdb.apache.org
-[2]: http://github.com/cloudant/bigcouch
+[2]: http://github.com/basho/rebar
--- End diff --
basho/rebar is not a official rebar repo. Use rebar/rebar instead.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastructure@apache.org or file a JIRA ticket
with INFRA.
---