摘要：在這些系統中，單個店鋪維護他們各自的庫存，然后在某個特定的時間間隔之后通常是晚上將數據返回關系型數據庫管理系統中心。接著，關系型數據庫管理系統將當天接收到的所有數據整合和分類之后，用于分析報表等操作，并且將其提供給外部及內部應用。

本文源地址：http://www.mongoing.com/blog/retail-reference-architecture-part-2-appr...

在電商參考架構系列的第一部分中，我們介紹了一個大數據量電商如何使用MongoDB作為一個龐大產品目錄持久層的一些最佳實踐。第一部分中包括了索引、模式以及查詢優化以保證我們的目錄能夠支持類似于搜索、單店價格以及在高效率方式下多方面檢索及瀏覽等特性。在接下來的兩篇博客中，我們將介紹相似類型的優化方法，并且將其應用到一個電商業務中完全不同的方面——庫存。

一個可以通過電商的店鋪及應用訪問到的、可靠的、集中的庫存系統是提高和豐富用戶體驗中一個非常龐大的基礎部分。下面列舉了一個電商或許想要得到的一些特性：

可靠地檢查產品的實時庫存

提供用戶在某個指定實體店提貨的選項

在某個商品有促銷的情況下，判斷每日補給的需求

上面這些都是一些看似基礎的特性，但是實際上也是目前大多數電商普遍使用的傳統庫存系統類型所面臨的真實問題。在這些系統中，單個店鋪維護他們各自的庫存，然后在某個特定的時間間隔之后（通常是晚上）將數據返回關系型數據庫管理系統中心。接著，關系型數據庫管理系統將當天接收到的所有數據整合和分類之后，用于分析、報表等操作，并且將其提供給外部及內部應用。在關系型數據庫管理系統和其它應用之間，通常會有一個緩存層，因為在很多情況下，關系型數據庫并不是很適合處理該客戶端請求的事務數量，特別是面向用戶的移動或者網頁應用。

因此，現在的問題非常清晰了。這些系統基礎的創建并不適用于針對我們擁有多少庫存以及庫存位置提供一個連續精確的映射關系。此外，還可能帶來維護多個系統而導致的復雜性上升的情況，例如：緩存以及持久性等等。而MongoDB則是對這些場景的最好選擇 -即使在電商店鋪在地理上分布很散，MongoDB仍然可以實現到產品信息的高精確度和系統的高可靠性。

首先，我們確定好在電商參考架構中的庫存系統應該要做的事情：

提供一個庫存的360°視圖，可以在任何時間被任何客戶端訪問

能夠被任何需要庫存數據的系統使用

解決大數據量、以讀取為主的工作負載，例如：庫存檢查

解決大數據量的實時寫操作，例如：庫存更新

支持批量寫入操作以更新系統記錄

地理上分離

伴隨著庫存中店鋪數量或者商品數量的增多，保持水平擴展

簡而言之，我們需要的是構建一個高性能、可水平擴展的系統，在一個龐大的、地理分布的區域中的店鋪和用戶都能夠與MongoDB進行實時交互來查看和更新目錄。

用戶案例的一個基本需求是為每個店鋪維護一個關于所有庫存的、集中的、實時的視圖。我們首先需要為店鋪集合創建視圖，從而將我們的庫存與地理位置相聯系起來。結果是：每個店鋪都使用一個相當直接的文檔。

{

“_id”:ObjectId(“78s89453d8chw28h428f2423”),

“className”:”catalog.Store”,

“storeId”:”store100”,

“name”:”Bessemer Store”,

“address”:{

“addr1”:”1 Main St.”,

“city”:”Bessemer”,

“state”:”AL”,

“zip”:”12345”,

“country”:”USA”

},

“location”:[-86.95444, 33.40178],

…

}

然后，我們可以創建下列的索引來優化在店鋪數據中最經常使用讀取類型：

{“storeId”:1},{“unique”:true}: 獲取某個特定商店的庫存

{“name”:1}:根據名字獲取商店名稱

{“address.zip”:1}: 獲取一個郵編內的所有店鋪，例如：店鋪定位程序
-{“location”: 2dsphere}:獲取某一個特定地理位置周圍的所有商店

在上面所有的索引中，位置索引對我們來說非常有用，因為它允許我們基于某個位置近似查詢商店。例如，一個用戶尋找某個產品有現貨的最近商店。為了在分片環境中利用這個優勢，我們使用一條geoNear的命令來檢索得到那些“位置”屬性在給定點一定距離之內的文檔，然后對最近的店鋪進行排序：

db.runCommand({
geoNear:“stores”,
near:{
type:”Point”,
coordinates:[-82.8006,40.0908], //GeoJSON or coordinate pair
maxDistance:10000.0, //in meters
spherical:true //required for 2dsphere indexes
}
})

這種模式給了我們定位對象的能力，但是同時也給在這些店鋪中追蹤和管理庫存帶來了更大的挑戰。

既然我們已經將商品和店鋪聯系了起來，我們需要創建一個庫存集合來跟蹤每一個商品以及它們所有商品系列的真實庫存量。然而，我們需要在其中進行一定的取舍。為了同時最小化對數據庫的來回讀取數目，同時降低應用級的連接，我們決定將數據從店鋪集合復制到庫存集合。我們提出的文檔是這樣的：

{
“_id”:”902372093572409542jbf42r2f2432”,
“storeId”:”store100”,
“location”:[-86.95444, 33.40178],
“productId”:”20034”,
“vars”:[
{“sku”:”sku1”, “quantity”:”5”},
{“sku”:”sku2”, “quantity”:”23”},
{“sku”:”sku3”, “quantity”:”2”},
…
]
}

首先注意到：我們在庫存文檔中同時包括了storeId和location屬性。很明顯，storeId對于我們知道哪個商店有什么商品是非常必要的，但是——當我們查詢離用戶附近的庫存時會發生什么呢？需要同時使用到庫存數據以及店鋪位置數據才能完成這個請求。通過在庫存文檔中添加地理位置數據，我們消除了在店鋪集合中執行一個多帶帶查詢的需求，也減少了店鋪集合和庫存集合的一個連接操作。

此外，在我們的模式中，我們還決定在商品級別文檔中表示庫存。正如我們在電商參考架構系列第一部分中提到的，每個產品可能會擁有成百上千的商品系列/型號，包括尺寸、顏色、風格等等，所有這些系列必須在我們的庫存中表示出來。那么，問題就是：我們是否應該支持包含一個更大系列集合的更大文檔，還是在具體商品型號上表示庫存的更多文檔呢？在這種情況下，我們比較傾向于更大的文檔以降低數據冗余度，這樣做也可以減少在庫存集合中需要查詢或者更新的文檔總數。

接下來，我們創建索引：

{storeId:1}: 得到某一個指定商店庫存中的所有商品

{productId:1},{storeId:1}: 獲取一個指定店鋪中某個產品的庫存

{productId:1},{location:”2dsphere”}:獲取在一定距離之內的某個產品的所有庫存

值得注意的是：我們并沒有選擇創建一個包含vars.sku 的索引。沒有這樣做的原因是：這并不會給我們帶來非常多的好處，因為我們已經可以基于productID查詢我們的庫存了:

db.inventory.find(
{
“storeId”:”store100”,
“productId”:“20034”,
“vars.sku”:”sku11736”
},
{“vars.$”:1}
)

實際上，我們并不會從vars.sku索引上受益多少。在這種情況下，在productID上的索引已經可以得到文檔了，因此在該變量上的索引是不必要的。此外，由于系列數組有可能有成千上萬的條目，在上面的索引可能會占用一大塊內存，從而減少在內存中存儲的文檔數目，這就意味著會降低查詢速度。考慮所有的事情，在給定目標的前提下，這是一個不中意的取舍。

那么是什么使得我們的模式如此合適呢？我們將在下一篇博客中討論這個方法為庫存系統提供的一些特色。

為了進一步了解如何使用MongoDB重新開啟你的零售商之旅，請閱讀我們的白皮書。在這篇文章中，你將會了解新的零售挑戰以及MongoDB如何解決它們。

本文譯自：https://www.mongodb.com/blog/post/retail-reference-architecture-part-2...

翻譯：周穎敏
審稿：TJ

閱讀第一部分

快速啟動你的應用