摘要：因?yàn)樗麄兛赡軙?huì)有許多顧客對(duì)相同的商品目錄進(jìn)行多次請(qǐng)求。然而，對(duì)于我們的參考架構(gòu)，我們想完全在中實(shí)現(xiàn)一個(gè)多方面搜索。

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

如今，產(chǎn)品目錄數(shù)據(jù)管理對(duì)零售商而言是一個(gè)非常復(fù)雜的問題。經(jīng)過多年對(duì)多個(gè)龐大、由供應(yīng)商提供的系統(tǒng)的依賴之后，零售商目前正在重新考慮他們的選擇，并且開始展望未來。

在如今供應(yīng)商提供的系統(tǒng)中，產(chǎn)品數(shù)據(jù)必須得頻繁地使用 ETL 工具來回遷移，以保證所有的系統(tǒng)均在相同數(shù)據(jù)集上進(jìn)行操作。這個(gè)方法就開發(fā)和管理而言是非常緩慢、容易出錯(cuò)，并且非常昂貴的。因此，零售商目前正在努力將數(shù)據(jù)服務(wù)多帶帶作為一個(gè)集中的、面向服務(wù)架構(gòu)（SOA）的一部分。

這是我們?cè)贛ongoDB中通?？吹降囊粋€(gè)模式，因此我們開始定義一些最佳實(shí)踐以及專門面向于電商空間的參考架構(gòu)。作為該成果的一部分，今天我們將開始介紹如何使用MongoDB實(shí)現(xiàn)一項(xiàng)目錄服務(wù)，并將其作為在零售商架構(gòu)系列（共三部分）的第一部分。

許多不同的數(shù)據(jù)庫(kù)類型都可以實(shí)現(xiàn)我們的產(chǎn)品目錄用戶案例，那么為什么要選擇MongoDB呢？

文檔靈活性：每個(gè)MongoDB文檔都可以將數(shù)據(jù)存儲(chǔ)為豐富的JSON結(jié)構(gòu)。這就使得MongoDB對(duì)于存儲(chǔ)任何對(duì)象都非常理想，包括擁有每個(gè)商品都有成千上萬系列的龐大目錄。

動(dòng)態(tài)的模式：每個(gè)文檔中的JSON結(jié)構(gòu)可以隨時(shí)進(jìn)行調(diào)整，保證了需要修改時(shí)數(shù)據(jù)的靈活性以及易重構(gòu)性。在MongoDB中，這些多重模式可以存儲(chǔ)于一個(gè)單一的集合中，也可以使用共享索引，保證了新、舊格式的同步高效搜索。

有表現(xiàn)力的查詢語言：能夠在多個(gè)文檔屬性之間進(jìn)行查詢的能力簡(jiǎn)化了許多任務(wù)。這也可以通過減少數(shù)據(jù)庫(kù)必要請(qǐng)求次數(shù)來提高應(yīng)用的性能。

索引：MongoDB從一開始就提供了強(qiáng)大的二級(jí)、復(fù)合及地理索引選項(xiàng)，保證了像排序以及基于位置的查詢之類的特色。

數(shù)據(jù)一致性：默認(rèn)地，所有的讀寫操作都會(huì)被送到一個(gè)MongoDB復(fù)制集的主節(jié)點(diǎn)上。這樣就保證了強(qiáng)一致性——一個(gè)對(duì)零售商而言非常重要的特性。因?yàn)樗麄兛赡軙?huì)有許多顧客對(duì)相同的商品目錄進(jìn)行多次請(qǐng)求。

地理分布的復(fù)制集：由數(shù)據(jù)源與用戶之間的地理距離帶來的網(wǎng)絡(luò)延遲是一個(gè)難題，尤其對(duì)于一個(gè)期望維持大量低延遲讀取的目錄服務(wù)而言。MongoDB的復(fù)制集可以是地理上分離的，因此它們距離用戶非常近，在很多情況下可以保證快速存取、減輕內(nèi)容分發(fā)網(wǎng)絡(luò)的需求。

這些只是MongoDB成為對(duì)電商而言很好的選擇的一些特性。接下來，我們將介紹一下如何將其中的一部分特性運(yùn)用于我們的零售商參考架構(gòu)，來支持許多特色，包括：

對(duì)商品及商品系列的搜索

對(duì)商品在每個(gè)店鋪價(jià)格的檢索

允許目錄的多方面搜索和瀏覽

商品數(shù)據(jù)模型

我們需要考慮的第一件事就是商品的數(shù)據(jù)模型。在下面的例子中，我們只展示了對(duì)每件商品而言最重要的信息，例如類別、品牌以及描述：

{
“_id”: “30671”, //main item ID
“department”: “Shoes”,
“category”: “Shoes/Women/Pumps”,
“brand”: “Calvin Klein”,
“thumbnail”: “http://cdn.../pump.jpg”,
“title”: “Evening Platform Pumps”,
“description”: “Perfect for a casual night out or a formal event.”,
“style”: “Designer”,
…
}

這種簡(jiǎn)單的數(shù)據(jù)模型允許我們非常容易基于最重要原則對(duì)商品進(jìn)行查詢。例如，使用db.collection.findOne，將會(huì)返回一個(gè)滿足一個(gè)查詢的單一文檔：

通過ID得到商品：db.definition.findOne({_id:”301671”})

通過一系列產(chǎn)品ID得到商品：db.definition.findOne({_id:{$in:[”301671”,”452318”]}})

通過類別前綴得到商品：db.definition.findOne({category:/^Shoes/Women/})

注意第二個(gè)和第三個(gè)查詢分別是如何使用$in操作符以及一個(gè)正則表達(dá)式的。當(dāng)在正確索引的文檔中執(zhí)行這些類型的查詢時(shí)，MongoDB可以為這些類型的查詢提供高吞吐量以及低延遲的能力。

對(duì)產(chǎn)品目錄而言另一個(gè)重要的考量是商品系列，例如現(xiàn)有尺寸、顏色以及風(fēng)格。上述的數(shù)據(jù)模型只能獲取到關(guān)于每個(gè)目錄商品一小部分的數(shù)據(jù)。因此，對(duì)于所有現(xiàn)有的、我們也許需要檢索的商品系列（例如大小和顏色）而言又該怎么處理呢？

一個(gè)選擇是在一個(gè)單一文檔中存儲(chǔ)一個(gè)商品以及它所有的系列。這種方法擁有能夠在一個(gè)單一查詢中檢索一個(gè)商品以及其所有系列的優(yōu)點(diǎn)。然而，它并不是在所有情況下都是最好的方法。避免無限制的文檔增長(zhǎng)是一個(gè)非常重要的最佳實(shí)踐。如果產(chǎn)品系列的數(shù)據(jù)以及它們相關(guān)數(shù)據(jù)非常小，在商品文檔中存儲(chǔ)這些數(shù)據(jù)也許會(huì)有意義。

另一個(gè)選擇是創(chuàng)建一個(gè)能夠關(guān)聯(lián)到主商品的、多帶帶的系列數(shù)據(jù)模型:

{
“_id”: ”93284847362823”, //variant sku
“itemId”: “30671”, //references the main item
“size”: 6.0,
“color”: “red”
…
}

這個(gè)數(shù)據(jù)模型允許我們通過它們的商品編號(hào)來快速檢索到特定的商品系列：

db.variation.find({_id:”93284847362823”})

也可以通過對(duì)itemId 屬性的查詢獲得某個(gè)特定商品的所有系列：

db.variation.find({itemId:”30671”}).sort({_id:1})

通過這個(gè)方法，我們同時(shí)維護(hù)了在目錄中展示主商品以及當(dāng)用戶請(qǐng)求一個(gè)更詳細(xì)的產(chǎn)品視圖時(shí)對(duì)每個(gè)系列的快速查詢。我們也可以保證商品以及系列文檔的一個(gè)可預(yù)測(cè)大小。

在定義產(chǎn)品目錄的參考架構(gòu)時(shí)另一個(gè)考慮是價(jià)格。我們已經(jīng)看到了一些方法，能夠結(jié)構(gòu)化我們的商品，以直接或基于特定屬性快速檢索商品。價(jià)格有可能受很多因素影響，例如店鋪的位置。我們需要一個(gè)方法快速檢索出任何一個(gè)給定商品或者商品系列的特定價(jià)格。這對(duì)于大型零售商而言是非常困難的，因?yàn)橐粋€(gè)擁有一百萬商品以及一千個(gè)商店的商品目錄意味著我們必須在一個(gè)十億文檔集合中進(jìn)行查詢以獲得任意一個(gè)給定商品的價(jià)格。

當(dāng)然，我們也可以將每個(gè)系列的價(jià)格作為一個(gè)嵌套文檔在商品文檔中存儲(chǔ)起來，但是一個(gè)更好的解決方法是再次利用MongoDB可以對(duì)_id 進(jìn)行快速查詢的優(yōu)點(diǎn)。例如，如果產(chǎn)品目錄中每個(gè)商品都被一個(gè)商品ID引用，同時(shí)它的每個(gè)系列都被一個(gè)商品編號(hào)（SKU）索引，那么我們就可以將每個(gè)文檔的_id設(shè)置為商品ID或者商品編號(hào)（SKU）的一個(gè)級(jí)聯(lián)，并且將商店ID與價(jià)格變量相關(guān)聯(lián)。通過使用這個(gè)模型，上面提到的每雙單鞋的_id以及它的紅色種類應(yīng)該看起來是這樣的：

商品：30671_store23

某個(gè)特定規(guī)格的商品：93284847362823_store23

這種方法也為處理價(jià)格提供很大的靈活性，因?yàn)樗试S我們?cè)谏唐坊蛘呦盗屑?jí)別對(duì)商品進(jìn)行定價(jià)。我們可以查詢所有價(jià)格或者只是某個(gè)特定店鋪的價(jià)格：

所有價(jià)格：db.prices.find({_id:/^30671/})

某個(gè)特定店鋪的價(jià)格：db.prices.find({_id:/^30671_store23/})

我們甚至可以添加其他組合，例如每個(gè)店鋪群的價(jià)格，然后在單個(gè)查詢中使用$in操作符獲取對(duì)于一個(gè)商品而言所有可能的價(jià)格:

db.prices.find({_id:{$in:[ “30671_store23”,
“30671_sgroup12”,
“93284847362823_store23”,
“93284847362823_sgroup12” ]}})

對(duì)我們的產(chǎn)品目錄而言，最大的一個(gè)挑戰(zhàn)就是能夠提供多方面的搜索和瀏覽。盡管許多用戶想要使用某個(gè)特定商品或者他們正在尋找的條件來搜索我們的產(chǎn)品目錄，但是更多的其他用戶想要的是瀏覽，然后通過一系列屬性來限制返回結(jié)果。因此，給定創(chuàng)建一個(gè)像下面這個(gè)頁面一樣的需求：

我們有許多的挑戰(zhàn)：

響應(yīng)時(shí)間：在用戶瀏覽的同時(shí)，結(jié)果的每個(gè)頁面應(yīng)該在毫秒內(nèi)返回。

多個(gè)屬性：伴隨著用戶選擇不同的方面（例如，品牌、大小、顏色等），新的查詢必須能夠在多個(gè)文檔屬性中運(yùn)行。

系列級(jí)別屬性：一些用戶選擇的屬性將會(huì)在商品級(jí)別進(jìn)行查詢，例如品牌，但是其它的查詢則有可能運(yùn)行于系列級(jí)別上，例如尺寸。

多個(gè)系列：每個(gè)商品都有可能有成千上萬個(gè)系列，但是我們只希望每個(gè)商品只展示一次，因此，結(jié)果必須消除重復(fù)項(xiàng)。

排序：用戶需要能夠在多個(gè)屬性上進(jìn)行排序，例如價(jià)格、尺寸，此外排序操作必須能夠高效運(yùn)行。

分頁：每個(gè)頁面只返回少量結(jié)果，這就要求確定性排序。

許多零售商也許會(huì)想要使用一個(gè)專用的搜索引擎作為這些特色的基礎(chǔ)。MongoDB就提供了一個(gè)開源的連接件項(xiàng)目，它允許MongoDB和Apache Solr 以及Elasticsearch同時(shí)使用。然而，對(duì)于我們的參考架構(gòu)，我們想完全在MongoDB中實(shí)現(xiàn)一個(gè)多方面搜索。

{
“_id”: “30671”,
“title”: “Evening Platform Pumps”,
“department”: “Shoes”,
“Category”: “Women/Shoes/Pumps”,
“price”: 149.95,
“attrs”: [“brand”: “Calvin Klein”, …],
“sattrs”: [“style”: ”Designer”, …],
“vars”: [
{
“sku”: “93284847362823”,
“attrs”: [{“size”: 6.0}, {“color”: “red”}, …],
“sattrs”: [{“width”: 8.0}, {“heelHeight”: 5.0}, …],
}, … //Many more SKUs
]
}

為了實(shí)現(xiàn)這個(gè)功能，我們創(chuàng)建了另一個(gè)集合，用于存儲(chǔ)所謂的摘要文檔。這些文檔包含了我們需要基于多個(gè)搜索方面對(duì)產(chǎn)品目錄中商品進(jìn)行快速檢索的所有信息。

注意：在這個(gè)數(shù)據(jù)模型中，我們定義了屬性以及輔助屬性。盡管一個(gè)用戶也許會(huì)希望能夠在某個(gè)商品或者商品系列的許多不同屬性上進(jìn)行搜索，但是我們只會(huì)保存一個(gè)最經(jīng)常使用的核心集合。例如，給定一雙鞋，對(duì)于一個(gè)用戶而言，基于現(xiàn)有尺寸大小的查詢會(huì)比基于后跟高度查詢更普遍。通過在我們的數(shù)據(jù)模型中同時(shí)使用attr和sattr屬性，我們可以將所有商品屬性提供給搜索，但是也會(huì)帶來只索引最經(jīng)常使用的屬性attr花費(fèi)的提高。

通過使用這個(gè)數(shù)據(jù)模型，我們可以創(chuàng)建以下復(fù)合索引：

部門+屬性+類別+ _id

部門+變量屬性+類別+ _id

部門+類別+ _id

部門+價(jià)格+ _id

部門+評(píng)分+ _id

在這些目錄中，我們經(jīng)常從部門開始，然后我們假設(shè)用戶將會(huì)選擇部門來重新定義他們的搜索結(jié)果。對(duì)于沒有部門的一個(gè)產(chǎn)品目錄，我們可以非常輕易地從另一個(gè)像類別或者類型等比較普遍的方面開始。然后，我們可以執(zhí)行需要進(jìn)行多方面搜索的查詢，并且快速將結(jié)果返回到頁面：

從商品ID獲取摘要 db.variation.find({_id:”30671”})

獲取特定商品系列的摘要 db.variation.find({vars.sku:”93284847362823”},{“vars.$”:1})

通過部門獲取所有商品的摘要 db.variation.find({department:”Shoes”})

使用一系列混合的參數(shù)獲取摘要

db.variation.find({ “department”:”Shoes”,
“vars.attr”: {“color”:”red”},
“category”: “^/Shoes/Women”})

今天我們了解了一些多功能商品目錄系統(tǒng)的建模和索引的最佳實(shí)踐，包括商品及商品系列的查詢、店鋪價(jià)格以及支持多樣化搜索的目錄瀏覽。使用這些方法作為一個(gè)起點(diǎn)，將會(huì)幫助你找到對(duì)于你自己的項(xiàng)目而言最好的設(shè)計(jì)。

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

為了了解MongoDB的咨詢團(tuán)隊(duì)如何可以幫助您的應(yīng)用更快起步，探索我們的開始啟動(dòng)指南。

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

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