摘要：在這些系統(tǒng)中，單個(gè)店鋪維護(hù)他們各自的庫存，然后在某個(gè)特定的時(shí)間間隔之后通常是晚上將數(shù)據(jù)返回關(guān)系型數(shù)據(jù)庫管理系統(tǒng)中心。接著，關(guān)系型數(shù)據(jù)庫管理系統(tǒng)將當(dāng)天接收到的所有數(shù)據(jù)整合和分類之后，用于分析報(bào)表等操作，并且將其提供給外部及內(nèi)部應(yīng)用。

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

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

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

可靠地檢查產(chǎn)品的實(shí)時(shí)庫存

提供用戶在某個(gè)指定實(shí)體店提貨的選項(xiàng)

在某個(gè)商品有促銷的情況下，判斷每日補(bǔ)給的需求

上面這些都是一些看似基礎(chǔ)的特性，但是實(shí)際上也是目前大多數(shù)電商普遍使用的傳統(tǒng)庫存系統(tǒng)類型所面臨的真實(shí)問題。在這些系統(tǒng)中，單個(gè)店鋪維護(hù)他們各自的庫存，然后在某個(gè)特定的時(shí)間間隔之后（通常是晚上）將數(shù)據(jù)返回關(guān)系型數(shù)據(jù)庫管理系統(tǒng)中心。接著，關(guān)系型數(shù)據(jù)庫管理系統(tǒng)將當(dāng)天接收到的所有數(shù)據(jù)整合和分類之后，用于分析、報(bào)表等操作，并且將其提供給外部及內(nèi)部應(yīng)用。在關(guān)系型數(shù)據(jù)庫管理系統(tǒng)和其它應(yīng)用之間，通常會有一個(gè)緩存層，因?yàn)樵诤芏嗲闆r下，關(guān)系型數(shù)據(jù)庫并不是很適合處理該客戶端請求的事務(wù)數(shù)量，特別是面向用戶的移動(dòng)或者網(wǎng)頁應(yīng)用。

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

首先，我們確定好在電商參考架構(gòu)中的庫存系統(tǒng)應(yīng)該要做的事情：

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

能夠被任何需要庫存數(shù)據(jù)的系統(tǒng)使用

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

解決大數(shù)據(jù)量的實(shí)時(shí)寫操作，例如：庫存更新

支持批量寫入操作以更新系統(tǒng)記錄

地理上分離

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

簡而言之，我們需要的是構(gòu)建一個(gè)高性能、可水平擴(kuò)展的系統(tǒng)，在一個(gè)龐大的、地理分布的區(qū)域中的店鋪和用戶都能夠與MongoDB進(jìn)行實(shí)時(shí)交互來查看和更新目錄。

用戶案例的一個(gè)基本需求是為每個(gè)店鋪維護(hù)一個(gè)關(guān)于所有庫存的、集中的、實(shí)時(shí)的視圖。我們首先需要為店鋪集合創(chuàng)建視圖，從而將我們的庫存與地理位置相聯(lián)系起來。結(jié)果是：每個(gè)店鋪都使用一個(gè)相當(dāng)直接的文檔。

{

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

“className”:”catalog.Store”,

“storeId”:”store100”,

“name”:”Bessemer Store”,

“address”:{

“addr1”:”1 Main St.”,

“city”:”Bessemer”,

“state”:”AL”,

“zip”:”12345”,

“country”:”USA”

},

“l(fā)ocation”:[-86.95444, 33.40178],

…

}

然后，我們可以創(chuàng)建下列的索引來優(yōu)化在店鋪數(shù)據(jù)中最經(jīng)常使用讀取類型：

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

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

{“address.zip”:1}: 獲取一個(gè)郵編內(nèi)的所有店鋪，例如：店鋪定位程序
-{“l(fā)ocation”: 2dsphere}:獲取某一個(gè)特定地理位置周圍的所有商店

在上面所有的索引中，位置索引對我們來說非常有用，因?yàn)樗试S我們基于某個(gè)位置近似查詢商店。例如，一個(gè)用戶尋找某個(gè)產(chǎn)品有現(xiàn)貨的最近商店。為了在分片環(huán)境中利用這個(gè)優(yōu)勢，我們使用一條geoNear的命令來檢索得到那些“位置”屬性在給定點(diǎn)一定距離之內(nèi)的文檔，然后對最近的店鋪進(jìn)行排序：

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
}
})

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

既然我們已經(jīng)將商品和店鋪聯(lián)系了起來，我們需要?jiǎng)?chuàng)建一個(gè)庫存集合來跟蹤每一個(gè)商品以及它們所有商品系列的真實(shí)庫存量。然而，我們需要在其中進(jìn)行一定的取舍。為了同時(shí)最小化對數(shù)據(jù)庫的來回讀取數(shù)目，同時(shí)降低應(yīng)用級的連接，我們決定將數(shù)據(jù)從店鋪集合復(fù)制到庫存集合。我們提出的文檔是這樣的：

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

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

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

接下來，我們創(chuàng)建索引：

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

{productId:1},{storeId:1}: 獲取一個(gè)指定店鋪中某個(gè)產(chǎn)品的庫存

{productId:1},{location:”2dsphere”}:獲取在一定距離之內(nèi)的某個(gè)產(chǎn)品的所有庫存

值得注意的是：我們并沒有選擇創(chuàng)建一個(gè)包含vars.sku 的索引。沒有這樣做的原因是：這并不會給我們帶來非常多的好處，因?yàn)槲覀円呀?jīng)可以基于productID查詢我們的庫存了:

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

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

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

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

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

翻譯：周穎敏
審稿：TJ

閱讀第一部分

快速啟動(dòng)你的應(yīng)用