MongoDB應用案例：使用 MongoDB 存儲商品分類資訊

上述問題使用傳統的關系型資料庫也可以解決，比如以下幾種方案

比如音樂專輯、電影這2種商品，有一部分共同的屬性，但也有很多自身特有的屬性，可以建立2個不同的表，擁有不同的schema。

這種做法的主要問題在于

針對每個新的商品分類，都需要建立新的表

應用程式開發者必須顯式的将請求分發到對應的表上來查詢，一次查詢多種商品實作起來比較麻煩

将所有的商品存儲到一張表，這張表包含所有商品需要的屬性，不同的商品根據需要設定不同的屬性，這種方法使得商品查詢比較簡單，并且允許一個查詢跨多種商品，但缺點是浪費的空間比較多。

上述方案将所有商品公共的屬性提取出來，将公共屬性存儲到一張表裡，每種商品根據自身的需要建立新的表，新表裡隻存儲該商品特有的資訊。

所有的資料按照<商品sku， 屬性、值> 的3元組的形式存儲，這個方案實際上是把關系型資料庫當kv存儲使用，模型簡單，但應對複雜的查詢不是很友善。

entity

attribute

values

sku_00e8da9b

type

audio album

title

a love supreme

...

artist

john coltrane

genre

jazz

general

mognodb 與關系型資料庫不同，其無schema，文檔内容可以非常靈活的定制，能很好的使用上述商品分類存儲的需求; 将商品資訊存儲在一個集合裡，集合裡不同的商品可以自定義文檔内容。

比如一個音樂專輯可以類似如下的文檔結構

而一部電影則可以存儲為

所有商品都擁有一些共同的基本資訊，特定的商品可以根據需要擴充獨有的内容，非常友善； 基于上述模型，mongodb 也能很好的服務各類查詢。

上述查詢也可以通過建立索引來加速

可建立如下索引來加速查詢

當單個節點無法滿足海量商品資訊存儲的需求時，就需要使用mongodb sharding來擴充，假定大量的查詢都是都會基于商品類型，那麼就可以使用商品類型字段來進行分片。

分片時，盡量使用複合的索引字段，這樣能滿足更多的查詢需求，比如基于商品類型之後，還會經常根據商品的風格标簽來查詢，則可以把商品的标簽字段作為第二分片key。

如果某種類型的商品，擁有相同标簽的特别多，則會出現jumbo chunk的問題，導緻無法遷移，可以進一步的優化分片key，以避免這種情況。

加入第3分片key之後，即使類型、風格标簽都相同，但其sku資訊肯定不同，就肯定不會出現超大的chunk。