## 路由文檔到分片 當你索引一個文檔，它被存儲在單獨一個主分片上。Elasticsearch是如何知道文檔屬于哪個分片的呢？當你創建一個新文檔，它是如何知道是應該存儲在分片1還是分片2上的呢？ 進程不能是隨機的，因為我們將來要檢索文檔。事實上，它根據一個簡單的算法決定： shard = hash(routing) % number_of_primary_shards `routing`值是一個任意字符串，它默認是`_id`但也可以自定義。這個`routing`字符串通過哈希函數生成一個數字，然后除以主切片的數量得到一個**余數(remainder)**，余數的范圍永遠是`0`到`number_of_primary_shards - 1`，這個數字就是特定文檔所在的分片。 這也解釋了為什么主分片的數量只能在創建索引時定義且不能修改：如果主分片的數量在未來改變了，所有先前的路由值就失效了，文檔也就永遠找不到了。 > 有時用戶認為固定數量的主分片會讓之后的擴展變得很困難。現實中，有些技術會在你需要的時候讓擴展變得容易。我們將在《擴展》章節討論。 所有的文檔API（`get`、`index`、`delete`、`bulk`、`update`、`mget`）都接收一個`routing`參數，它用來自定義文檔到分片的映射。自定義路由值可以確保所有相關文檔——例如屬于同一個人的文檔——被保存在同一分片上。我們將在《擴展》章節說明你為什么需要這么做。