使用 Magento 2 處理大量歸因
已發表: 2022-08-30使用 Magento 2 處理大量歸因
擴展 Magento 2 的功能以支持大量總屬性(超過 10,000 個)和每個屬性集的大量屬性(每組超過 1000 個)
介紹
2021 年,在線市場佔全球電子商務的 67%。全球排名前 100 的在線市場花費了 3.23 萬億美元。 沃爾瑪的市場擁有超過 100,000 名賣家,而亞馬遜在其市場上銷售近 3.5 億種產品。 傳統電子商務平台必須非常快速地擴展以處理他們現在需要處理的海量數據。
隨著越來越多的賣家加入市場,提供的產品種類也越來越多。 這在不影響整體性能和易用性的情況下對這些產品進行分類帶來了獨特的挑戰。 McFadyen Digital 團隊在最近的市場實施過程中面臨的一個挑戰是處理賣家產品附帶的眾多產品屬性。
我們在 Magento 和 Webkul 上為我們在美國銷售工業緊固產品的一位客戶實施了 B2B 市場。 隨著越來越多的賣家加入,產品種類增加了,每個帶來的獨特產品屬性的數量也增加了。 屬性數量超出了 Magento 的建議,我們面臨著嚴重的性能問題。 我們的技術專家對問題進行了詳細分析,並提出了一些變通辦法來處理這種情況。 我們將在本博客中討論其中的幾個。
.
產品進口:
Magento 建議將許多屬性劃分為多個屬性集。 但是,如果屬性集的數量也變得很大,則會對產品和屬性導入的性能產生不利影響。 這是因為 Magento 將所有屬性和屬性集預加載到內存中。 例如,假設有 1000 個屬性集,我們只導入產品的一個子集。 在這種情況下,Magento 仍然會加載所有可用的屬性和屬性集,這會增加內存消耗,從而增加導入處理時間。 導入產品時,會調用AbstractType init方法,該方法會加載產品數據庫中所有可用的屬性。 首先,加載所有屬性,然後加載屬性集,然後根據屬性 id 排列這些屬性。
供應商/magento/module-catalog-import-export/Model/Import/Product/Type/AbstractType

解決方案:
此問題的簡單解決方法是僅從默認 CSV 文件加載所需的屬性集 /products,而不是嘗試進行完全導入。 例如,假設我們正在嘗試導入單一類別的產品。 在這種情況下,我們僅從該類別加載屬性,而不是將其餘屬性 /attributes 集加載到內存中。
為此,我們重寫了 Simple Import 類型的init方法,如下所示:

這幫助我們顯著提高了性能,導入時間減少了近 30%。
產品清單:
在訪問任何類別頁面時,Magento 將所有屬性數據傳遞給 Elastic Search 以檢索類別和聚合詳細信息。 許多屬性導致高內存消耗,導致性能下降。
FilterableAttributeList 類將加載一個類別中的所有屬性和屬性集,即使我們只需要過濾特定類別的屬性子集。
供應商/magento/module-catalog/Model/Layer/Category/FilterableAttributeList
當我們使用 Elastic Search 連接時,請求必須使用兩個參數構建,就像我們在 MySQL 中創建查詢時所做的那樣,
- 匹配參數
- 聚合,帶來我們需要的所有數據
Magento 使用聚合作為圖層導航並返回所有數據,因此當我們有大量數據時,聚合計數會增加。 當我們嘗試在單個查詢中獲取更多聚合數據時,這將影響 Elastic Search。

這也可能導致平面實體表中的索引出現問題。 平面實體表不是每個屬性集,因此是所有屬性的聚合,可以運行到 MySQL 最大列限制。
從 MySQL 5.6.9 開始,最大列數為 1017,這將使 admin 產品編輯頁面成為無法使用的爬網,從而嚴重影響前端產品的渲染。

Magento 的工作原理:
Magento 加載屬性元數據,然後加載該屬性的值。 實體必須將此信息存儲在內存中。 但是,由於屬性元數據存儲在 Magento 緩存中,因此在第一頁加載時會看到最壞的影響。

同樣,KnockoutJS 不是為高性能而設計的。
解決方案:
由於 Magento 嘗試傳遞單個類別的所有屬性,因此覆蓋請求構建器,縮小到與該類別相關的特定屬性,並為該類別提供映射功能。 因此,每當加載類別頁面時,我們只加載該類別的屬性。
必須重寫 create() 函數以創建基於類別搜索頁面的動態請求,傳遞類別 ID 或品牌 ID 或賣家 ID。

根據 Magento 文檔,產品屬性的限制為 2000 個,可過濾的為 500 個。 超過 500 或超過 10k 的產品屬性會在店面和 Magento 管理員中引入若干性能下降(包括報告的問題)。
綜上所述,在處理大量產品屬性時應牢記以下最佳實踐:
- 對不同的產品使用不同的產品模板(屬性集)。
- 在 Magento Admin 中,有一個“在產品列表中使用”字段。 僅啟用我們計劃在類別頁面上啟用的那些屬性
- 利用自定義選項和復雜產品進行變化管理
- 最小化可搜索屬性的數量
- 刪除未使用的產品屬性。
- 在外部 PMS 系統中存儲和管理與商務無關的屬性
雖然這些解決方案是作為解決實際問題的解決方案而引入的,但從長遠來看,電子商務平台將不得不擴大規模,以應對在線市場帶來的不斷增加的產品數據量所帶來的這些挑戰。
在 McFadyen Digital,我們已經開發在線市場超過 15 年,並且不斷接觸可用平台。 我們為市場運營商提供的技術服務包括架構審查、供應商分析、實施等。 要了解更多信息,請訪問我們的市場技術解決方案。 有關構建和管理定制 Commerce 商店所需的一切的更多信息。 訪問 https://devdocs.magento.com/
關於作者
Sharada Rao 是 McFadyen Digital 的高級軟件工程師。 她喜歡學習和實施新技術。 Sharada 是一名狂熱的旅行者和美食家,喜歡探索新的地方。 她與丈夫和 11 個月大的兒子住在班加羅爾。 在 McFadyen Digital 任職期間,她參與了一些大型電子商務/市場實施項目。