[產品設計]電商設計知乎總結

 

想作一個B2B2C的電商平臺，在後臺數據統計搭建的時候須要注意哪些問題？如何設計具體的統計模塊？

 

王於萍：

我認爲在建數據庫前，須要設計好的，是需求和流程，有了這一步的需求，你就知道了在這裏你須要什麼數據；有了流程，你就知道了你能獲得什麼數據，甚至於數據類型。

好比供應商管理，你會獲得供應商的公司地區、電話、類目等，在數據統計中，你能夠對地區、類目統計，再根據C的對應需求推薦等

 

 

PalmWong：

建議先從業務理解開始：

BBC平臺，首先分紅三個後臺

商家門戶+平臺運營門戶+買家我的門戶

 

要作統計的部分一樣是三塊：

1、消費者我的視角出發：我的的消費統計

2、平臺運營的視角出發：整個平臺的運營狀況統計，針對商家的運營狀況統計

3、商家視角出發的統計

 

BBC商城實際上是很是複雜的業務系統，由於角色和功能的變化，致使其中數據交互其實很是多。且對帳、統計、權限管理異常狀況不少。

 

不是看着天貓的模式，就閉着眼睛能夠作的。

 

用 PHP+MySql 架構用戶數和訪問量爲千萬級別的相似淘寶商城那樣的 B2C 網站，如何？

 

Dion：

系統架構很重要！

 

語言：

主流語言都沒什麼問題。PHP、Java什麼的都行。

 

前端服務器：

若是有條件CDN，最好。沒有的話，必定要保證前端的負載性能。通常推薦Nginx。

 

應用服務器：

集羣唄。前端負責負載均衡。集羣的話，Session的問題注意下就行。別的沒什麼。

 

數據存儲：

若是數據量比較大的話（百萬級），用MySQL + Memcached作集羣沒問題。

若是數據量再大的話，考慮NoSQL吧。好比Facebook用Cassandra，Amazon用Dynamo。

 

socici：

你能夠簡單點，從用戶訪問的數據角度看

靜態文件,包括圖片、HTM 、JS、css 這些不常常變的數據。 單獨給個域 如http://static.xxxx.com 由nginx管理

經過先後臺發佈的動態數據，分如下幾種：

讀的數據：

1.須要用戶查詢的大數據，如訂單之類的，能夠去查slaver的數據庫

2.系統公共頁面顯示的數據，如部分商品信息、排行榜之類的能夠去緩存裏取

寫的數據：

要求即時生效的，如修改用戶信息，直接同步寫到master數據庫

即時要求不高或者有併發限制的，如發微博、發私信之類的 先寫到隊列，異步讀取保存到數據庫

 

電商平臺中商品規格設計的問題，拋出，求吐槽？

 

商品表（商品名稱、價格、上下架等一些商品基本的信息）

例如：1、 手機、100

規格表（主鍵、商品ID、規格名稱 ）

例如：1 、1、運營商

商品規格值表（主鍵、規格ID、商品ID、規格值ID、規格值NAME）

例如：1、1、1、0、電信版

2、1、1、1、移動版    

規格庫存表（商品ID、規格值ID組合、規格值NAME組合、庫存量、價格）

例如：1、1/0(運營商、電信版)、運營商/電信版、100個、100塊

 

問題描述：

 

以上方式可實現多規格多庫存可是採用一種約定的規格順序，感受在編寫程序時，系統在後期統計不一樣規格相關的數據就會很痛苦。

而且在實現商品建立時，要先把商品建立好後，才能建立規格，我的參考一些大的電商平臺方式，發現都是一個提交完成商品建立。

 

須要的幫助：

 

須要結合個人問題描述，給一個合理的商品多規格、多價格、多庫存的設計方案，來解決我編程上的複雜度，同時保證我能夠在商品建立的交互設計中簡單。

 

socici：

商品分類 （類型id,類型名稱，父ID）

商品表（商品名稱、價格、上下架等一些商品基本的信息、商品分類）

 

規格表（主鍵、規格名稱 ）

規格值表（規格值ID、規格id、規則值類型、規格默認值）

規格-分類關聯表（商品分類id，規格id)

 

商品-規格關聯表(商品id,規格id,規格值ID,規格實際值）

 

庫存表（商品id,數量,價格)

 

相似淘寶關於產品詳情頁的數據庫存儲是怎麼存儲的呢？

 

1，每一個產品的 圖片數和介紹的段落數都是不固定的,是採用編輯器編輯好以後生成html整個存儲到數據庫麼？不現實吧？

2. 要是以數據庫字段存儲到話,每一個產品的 圖片數和介紹的段落數是不固定的,就算設置一個上限,那也會浪費不少字段啊

3.在查詢的時候,若是圖片和介紹文字是分開存儲的,那麼在查詢以後頁面展現的時候是怎麼 將某一圖片和關於介紹他的問題相匹配的呢

 

劉傳雙：

整體來講

1、商品的結構化信息保存在數據庫，名稱、價格、庫存、屬性等，固然不是簡單的一張表。

2、商品的非結構化信息保存成小文件，存儲在自主開發的海量小文件系統中，圖片和商品描述信息。

3、商品的圖片文件id須要存儲在數據庫或者其餘類型的存儲的，不必定非要多個字段，這是水平方式，通常把商品的一個圖片存儲爲一條記錄，縱向擴展。

4、文檔在存儲以前，先保存圖片，並把文檔中<img>的圖片src地址替換爲小文件系統中的圖片路徑，就能夠了

 

補充一句，不能把存儲理解成只有數據庫和文件系統，存儲有各類類型的，不一樣的文件系統、各類RDBMS、NoSql存儲……

 

子柳：

其實幾位同事已經回答了，我再從歷史的角度作個補充

最先這個字段確實是放在數據庫裏面的，是一個clob字段，存放的就是html的片斷。並且當時這個字段跟商品的標題、價格、賣家ID等等是在一個表裏面的，性能會受到多大影響是能夠想象的。

因此這種方式是註定長久不了的，我在2005年，把這個字段單獨分離出來一張表來存放了，這沒多少技術含量，當時卻給數據庫減輕了很大壓力，DBA們很感謝我。

在2006年之後，淘寶開始大規模的採用緩存，這個字段也放進了緩存裏面，因而這又給數據庫減輕了很大壓力（只有不在緩存裏的數據，纔去數據庫裏面讀取，讀出來就放入緩存了）。

到了2007年，淘寶開發了分佈式文件存儲系統TFS，因而就完全的把這個字段請出了數據庫，一同請出的還有交易快照這樣的大字段信息。