NoSQL[产品设计]电商安顿博客园计算

 

想做一个B2B2C的电商平台,在后台数据总结搭建的时候必要专注哪些难点?怎样规划具体的计算模块?

 

王于萍:

自我以为在建数据库前,要求规划好的,是须要和流程,有了这一步的急需,你就知道了在那里你须要如何数据;有了工艺流程,你就清楚了您能获取哪些数据,甚至于数据类型。

比如供应商管理,你会获得供应商的营业所地区、电话、类目等,在数额总计中,你可以对地面、类目计算,再依据C的附和需求推荐等

 

 

PalmWong:

提出先从事情明白起来:

BBC平台,首先分成四个后台

NoSQL,商家门户+平台运营门户+买家个人门户

 

要做统计的一对雷同是三块:

1、消费者个人看法出发:个人的消费统计

2、平台运营的见地出发:整个平台的运营意况总结,针对集团的营业情形计算

3、商家视角出发的计算

 

BBC商城其实是万分复杂的事情系统,因为角色和效果的生成,导致其中多少交互其实万分多。且对账、计算、权限管理卓殊情状很多。

 

不是瞅着Taobao的形式,就闭着双眼可以做的。

 

用 PHP+MySql 架构用户数和访问量为千万级其余类似Tmall商城那样的 B2C 网站,怎么着?

 

Dion:

系统架构很要紧!

 

语言:

主流语言都不要紧难点。PHP、Java什么的都行。

 

前端服务器:

一经有规范CDN,最好。没有的话,一定要确保前端的载荷品质。一般推荐Nginx。

 

应用服务器:

集群呗。前端负责负载均衡。集群的话,Session的难题放在心上下就行。其他没什么。

 

多少存储:

假若数据量相比大的话(百万级),用MySQL + Memcached做集群没难点。

一旦数据量再大的话,考虑NoSQL吧。比如脸书用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整个存储到多少库么?不具体吧?

  1. 假诺以数据库字段存储到话,每个产品的
    图片数和介绍的段落数是不稳定的,尽管设置一个上限,那也会浪费广大字段啊

3.在询问的时候,如果图片和介绍文字是分别储存的,那么在询问之后页面显示的时候是怎么
将某一图纸和关于介绍她的题材相匹配的啊

 

刘传双:

一体化来说

1、商品的结构化音信保存在数据库,名称、价格、库存、属性等,当然不是几乎的一张表。

2、商品的非结构化信息保存成小文件,存储在自立开发的海量小文件系统中,图片和商品描述新闻。

3、商品的图形文件id要求仓储在数据库或者其余品种的蕴藏的,不自然非要三个字段,那是水平格局,一般把货物的一个图形存储为一条记下,纵向扩充。

4、文档在蕴藏此前,先保存图片,并把文档中<img>的图形src地址替换为小文件系统中的图片路径,就足以了

 

增补一句,不可以把仓储通晓成唯有数据库和文件系统,存储有各连串型的,不一致的文件系统、各个RDBMS、NoSql存储……

 

子柳:

实际上几位同事早就回答了,我再从历史的角度做个补充

最早这一个字段确实是位于数据库里面的,是一个clob字段,存放的就是html的局地。而且当时那么些字段跟商品的标题、价格、卖家ID等等是在一个表里面的,质量会遭逢多大影响是可以想像的。

故此那种艺术是尘埃落定长久不了的,我在二零零五年,把那几个字段单独分离出来一张表来存放了,那没多少技术含量,当时却给数据库减轻了很大压力,DBA们很感谢自己。

在二零零六年过后,天猫商城开首广泛的选择缓存,那个字段也放进了缓存里面,于是那又给数据库减轻了很大压力(唯有不在缓存里的多少,才去数据库里面读取,读出来就放入缓存了)。

到了二零零七年,天猫开发了分布式文件存储系统TFS,于是就根本的把那么些字段请出了数据库,一同请出的还有交易快照那样的大字段音信。

 

网站地图xml地图