Better example of low-cardinality dist column

citusdata · Jan 19, 2017 · 2347678 · 2347678
1 parent 8a8c23b
commit 2347678
Show file tree

Hide file tree

Showing 2 changed files with 1 addition and 1 deletion.
diff --git a/images/sharding-poorly-distributed.png b/images/sharding-poorly-distributed.png
diff --git a/sharding/data_modeling.rst b/sharding/data_modeling.rst
@@ -37,7 +37,7 @@ While the multi-tenant architecture introduces a hierarchical structure and uses
 
 Real-time queries typically ask for numeric aggregates grouped by date or category. Citus sends these queries to each shard for partial results and assembles the final answer on the coordinator node. Queries run fastest when as many nodes contribute as possible, and when no individual node bottlenecks.
 
-The more evenly a choice of entity id distributes data to shards the better. At the least the column should have a high cardinality. For comparison, a binary gender field is a poor choice because it assumes at most two values. These values will not be able to take advantage of a cluster with many shards. The row placement will skew into only two shards:
+The more evenly a choice of entity id distributes data to shards the better. At the least the column should have a high cardinality. For comparison, a "status" field on an order table is a poor choice of distribution column because it assumes at most a few values. These values will not be able to take advantage of a cluster with many shards. The row placement will skew into a small handful of shards:
 
 .. image:: ../images/sharding-poorly-distributed.png