couchdb-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From vatam...@apache.org
Subject [1/3] documentation commit: updated refs/heads/master to a05f028
Date Wed, 08 Mar 2017 01:59:09 GMT
Repository: couchdb-documentation
Updated Branches:
  refs/heads/master fbbc40f3c -> a05f0289a


Fix Shard documentation: typos, minor clarification on ASCII codes


Project: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/repo
Commit: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/commit/6edb6ea1
Tree: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/tree/6edb6ea1
Diff: http://git-wip-us.apache.org/repos/asf/couchdb-documentation/diff/6edb6ea1

Branch: refs/heads/master
Commit: 6edb6ea19788ae929553c2220ca591af2c8fa2ce
Parents: fbbc40f
Author: Rob Porter <rob@weeverapps.com>
Authored: Wed Feb 22 13:28:08 2017 -0500
Committer: Nick Vatamaniuc <vatamane@apache.org>
Committed: Tue Mar 7 20:44:02 2017 -0500

----------------------------------------------------------------------
 src/cluster/sharding.rst | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/couchdb-documentation/blob/6edb6ea1/src/cluster/sharding.rst
----------------------------------------------------------------------
diff --git a/src/cluster/sharding.rst b/src/cluster/sharding.rst
index 568eb7e..7747617 100644
--- a/src/cluster/sharding.rst
+++ b/src/cluster/sharding.rst
@@ -106,10 +106,10 @@ small there. Let us look in it. Yes, you can get it with curl too:
 * ``_id`` The name of the database.
 * ``_rev`` The current revision of the metadata.
 * ``shard_suffix`` The numbers after small and before .couch. The number of
-  seconds after UNIX epoch that the database was created. Stored in ASCII.
+  seconds after UNIX epoch that the database was created. This is stored as an array of ASCII
codes.
 * ``changelog`` Self explaining. Only for admins to read.
 * ``by_node`` Which shards each node have.
-* ``by_rage`` On which nodes each shard is.
+* ``by_range`` On which nodes each shard is.
 
 Nothing here, nothing there, a shard in my sleeve
 -------------------------------------------------
@@ -208,7 +208,7 @@ illusion of moving. If you try to uphold this illusion with a database
that have
 #. Delete the shard on the old node.
 #. Lose all writes made between 1 and 2.
 
-As the realty "I added a new replica of the shard X on node Y and then I waited
+As the reality "I added a new replica of the shard X on node Y and then I waited
 for them to sync, before I removed the replica of shard X from node Z." is a bit
 tedious, people and this documentation tend to use the illusion of moving.
 
@@ -291,7 +291,7 @@ you need to create a new cluster and migrate over.
 
 Creating more shards than you need and then move the shards around is called
 presharding. The number of shards you need depends on how much data you are
-going to store. But creating to many shards increases the complexity without any
+going to store. But, creating to many shards increases the complexity without any
 real gain. You might even get lower performance. As an example of this, we can
 take the author's (15 year) old lab server. It gets noticeably slower with more
 than one shard and high load, as the hard drive must seek more.


Mime
View raw message