mongoDB的讀書筆記(via3.0)(05)_【Sharding】(03)_關於Shard Keys與Hash的理論知識小絮叨，mongodbsharding

mongoDB的讀書筆記(via3.0)(05)_【Sharding】(03)_關於Shard Keys與Hash的理論知識小絮叨，mongodbsharding

緊急出個差，但是又不能不繼續寫，少寫點，先把Shard key和Hash的一些小概念繼續寫一寫。

Shard Keys

mongoDB的Sharding最重要的就是Shard Key。用Shard Key進行分區，並且按照指定的Chunk的大小進行Chunk的分割和移動(後面細說)。Shard Key的一些特點：

Shard Key不可以是multikey index

何為mutikey index？途中的addr[]這個數組就是所謂的mutikey index。Shard key可以是複數個欄位，但是不可以是一個數組形的multikey類型的index。

Hash Shard Key

任何帶有hash字樣的東東就為一個目的：平均打散，高度彙總。
通過hash演算法進行散裝分配，通過key再迅速找回value。

對於寫的橫向擴充

Shard key有兩個比較重要的指標，一個是分布的基數要廣，即每一個collection中都要有；另外一個是要保持“單調性”，比如timestamp，比如mongoDB自己的ObjectId等等。假設我們使用的是一個timestamp來作為Shard Key，可能保證了單調性和基數廣，但是這種連續儲存的Shard Key很有可能使得所有的資料都是連續儲存在同一個Chunk，也就是同一個Shard中，我們可能會有10個Shard節點，但是結果就是可著第一個節點一直在儲存，而其餘的節點都在休息。
所以，Shard Key還應該有一定的隨機性，也就是說在寫操作的時候應該能夠發揮所有的Shard一起動作，進行類似LB一樣的負載。

關於Shard中的查詢

對於查詢來講，mongos是提供interface供application進行調用的。程式進行調用後，mongo會在config Server中尋找相應的metadata來定位Shard，然後進行尋找的工作。所以我們的Shard Key會直接影響到查詢的效果和速度。

關於Shard中的獨立尋找

一般來講，最快的查詢操作是讓mongos尋找一個Shard。如果一個查詢中沒有包含Shard Key，那麼mongos就會遍曆所有的Shards。和我們普通的RDB中沒有索引的全表掃描一個效果。而且因為Shard有很多，所以這個查詢類似於一個分散操作後再次進行彙總操作的過程，非常費時間。而如果你的Shard Key在檢索條件中有體現，那麼即便是需要分散尋找幾個Shard，因為mongos有直接性，會知道到哪裡去找，效果也會好得多。所以為collection選定一個Shard key的話，首先要確定尋找的時候會經常用到哪些項目，找到這些操作中最有效依賴關係，比如一個項目可能不是那種很好識別不是可以單獨利用充分簡單能把資料pick up出來的，那麼是否可以增加另一個公事包起來來擴大可選性，擴大其作為“key”的純度等等。

關於排序

Shards中的排序其實是有一個merge後的sort的過程。其實很好想，各個Shards返回結果後，merge到一起再進行一個sort。

不可分的Chunk

後面還會細說，有些Chunk可能出現不可進行分解的情況，這很大程度上是是由於Shard key的選定的粒度不好所造成的。

明天要坐高鐵。(-｡-;) 。。。 後面繼續寫繼續寫。
ps，今天給mongo的jira又提Bug了。。
之前傻了吧唧的搞錯了一個命令給人家提了人家還挺客氣回複說是我搞錯了，但是今天看文檔看到一個文檔的簡單miss，哈哈，這次我不會錯了。

つづく・・・