Sharding: Implement suggestions by CodeRabbit

Author: amotl

docs/admin/sharding-partitioning.md

@@ -103,9 +103,9 @@ for a benchmark.
 - Identify the record size
 - Calculate the throughput
 
-Then, to calculate the number of shards, you should consider that the size of each
-shard should roughly be between 10 - 50 GB, and that each node can only manage
-up to 1000 shards.
+Then, to calculate the number of shards, consider that each shard should
+roughly be between 10 – 50 GB, and that each node can manage
+up to 1_000 shards by default.
 
 :::{caution}
 **Over-sharding and over-partitioning**

docs/performance/sharding.md

@@ -29,7 +29,7 @@ If you are looking for an intro to sharding, see also the
 To avoid running your clusters with too many shards or too large shards,
 implement the following guidelines as a rule of thumb:
 
-- Use shard sizes between 10GB and 50GB.
+- Use shard sizes between 10 GB and 50 GB.
 
 - Keep the number of records on each shard below 200 million.
 
@@ -50,7 +50,7 @@ the type of hardware you are using.
 
 ## Sizing considerations
 
-General principles requires careful consideration for cluster
+General principles require careful consideration of cluster
 sizing and architecture.
 Keep the following things in mind when building your sharding strategy.
 Each shard incurs overhead in terms of open files, RAM allocation, and CPU cycles
@@ -59,7 +59,7 @@ for maintenance operations.
 ### Shard size vs. number of shards
 
 The optimal approach balances shard count with shard size. Individual shards should
-typically contain 10-50 GB of data, being the sweet spot for most
+typically contain 10-50 GB of data, being the sweet spot for most
 workloads. In large clusters, this often means fewer shards than total CPU cores,
 as larger shards can still be processed efficiently by multiple CPU cores during
 query execution.