2013-12-09 68 views
2

我正在創建一個使用MongoDB存儲JSON對象的集合。我被困在Sharding部分。 我有一個案例ID,客戶ID和位置集合中的每個記錄MongoDB-使用三個值的複合分片鍵

案例ID是一個10位數字(只有數字和沒有字母)。

CustomerID是客戶名稱和案例ID的組合。

該位置是一個2dsphere值,我期待的位置有不同的值。

除此之外,我還有記錄的客戶名稱和案例描述。 我所有的搜索查詢都具有案例ID,客戶ID或位置的搜索條件。

鑑於此場景,我可以基於所有這三個值(CaseID,CustomerID和位置)創建複合關鍵字。我相信這給出了高基數和容易檢索記錄。

任何人都可以請建議我,如果這是一個好方法,因爲我沒有找到包含三個值的複合分片密鑰。

感謝您的時間,讓我知道,如果你需要的任何信息

+0

你可以只發布你的文檔的例子。這將是好得多然後巨大的解釋如何每個領域看起來像 –

+0

當然。給我一個時間 –

+0

這是如何構建{「_id」:ObjectId(「4c2210f9f3924d31102bd85a」),「名稱」:「timothyr」,「caseID」 :「3457712344」,「customerID」:「AB345ti」,「location」:「144.34,-37.14」,「Description」:「我無法登錄到我的電腦」 } –

回答

12

要考慮的是是否有必要碎片的第一件事。如果您的數據集適合單個服務器,那麼從一個未分發的部署開始。如果需要,將其稍後轉換爲分片羣集非常簡單且無縫。

假設你確實需要分片,你的片鍵的選擇應根據以​​下標準:

  1. 基數 - 選擇不侷限於少數可能值的碎片關鍵,這樣MongoDB可以在集羣中的分片之間均勻分配數據。
  2. 寫分佈 - 選擇在集羣中的分片之間均勻分配寫入操作的分片密鑰,以防止任何單個分片成爲瓶頸。
  3. 查詢隔離 - 選擇包含在最頻繁查詢中的分片密鑰,以便這些查詢可以高效地路由到保存數據的單個目標分片,而不是廣播給所有分片。

您提到所有查詢都包含案例ID,客戶ID或位置,但尚未描述您的使用案例。通過實例的方式,讓我們假設你的最頻繁的查詢到:

  • 檢索客戶案例
  • 檢索所有情況下,給定客戶

在這種情況下,一個良好的碎片關鍵候選會按順序(和相應的複合索引)作爲(name,caseID)上的複合分片鍵。考慮這是否符合上述標準:

  1. 基數 - 每個文檔都有不同的分片值,因此基數非常好。
  2. 寫分佈 - 所有客戶的案例分佈在所有分片中。
  3. 查詢隔離:
    • 要檢索特定的大小寫,名稱和caseID應該包含在查詢中。該查詢將被路由到保存文檔的特定分片。
    • 要檢索給定客戶的所有個案,請在查詢中包含姓名。因此,此查詢包含分片鍵的前綴,因此也只能有效地路由到保存與查詢匹配的文檔的特定分片。

請注意,您不能使用地理空間索引作爲片鍵指數(如記錄here)的一部分。但是,如果使用分片鍵的其他字段,仍然可以在分片集合上創建和使用地理空間索引。例如,使用上面的分片鍵:

  • 包含客戶名稱的地理空間查詢將定位到相關的分片。
  • 不包含客戶名稱的地理空間查詢將廣播到所有分片(「分散/聚集」查詢)。

有關分片鍵考慮的其他文檔可以找到here