Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Andere mochten auch
Andere mochten auch (16)
Ähnlich wie 基于 MySQL 的B2C电商系统前端数据层架构
Ähnlich wie 基于 MySQL 的B2C电商系统前端数据层架构 (20)
Mehr von Sky Jian
基于 MySQL 的B2C电商系统前端数据层架构
- 1. B2C电商系统前端数据层架构 - 基于分布式 MySQL 数据库 简朝阳 @麦包包 2011.4.23 http://www.mbaobao.com 2011/4/23 1
- 2. 基于 MySQL 的 B2C电商系统前端数据层架构 简朝阳(sky000) Oracle ACE (Expertise MySQL) 技术保障部 @麦包包 http://isky000.com http://twitter.com/sky000 http://weibo.com/isky000 2011/4/23 2
- 3. 主题内容 1. 基于MySQL的常见高可用可扩展方案 业界常见高可用可扩展架构分析 2. 基于日志解析的准实时同步对架构进行扩展 结合 B2C 电商的特点，利用开放的复制协议对常规架构进行扩展 3. 基于用户访问行为的实时推荐分析系统数据层 作为电商，除了让用户方便的找到想要的产品的同时，还 希望让用户尽可能多的看到可能感兴趣的产品。该如何构 建一个分析推荐引擎的数据层？ 4. Q/A 2011/4/23 3
- 4. 常见架构-高可用 • 硬件高可用 • 冗余 主机/储存/电源/网络 … … • 数据高可用 • 共享 SAN/NAS/iScsi/SAS … … • 冗余 Replication/DadaSyncer … … 2011/4/23 4
- 5. 高可用架构 – 共享 2011/4/23 5
- 6. 高可用架构 – 冗余 2011/4/23 6
- 7. 高可用架构 – 冗余 2011/4/23 7
- 8. 高可用架构 – 冗余 2011/4/23 8
- 9. 高可用架构 – 冗余 2011/4/23 9
- 10. 常见架构-可扩展 • 向上扩展 • 升级/增加/更换硬件 CPU/内存/磁盘 … … • 向外扩展 • Sharding 垂直/水平/ … … • Replication • Cache/Search 2011/4/23 10
- 11. 可扩展架构 – Sharding 2011/4/23 11
- 12. 可扩展架构 – Sharding 2011/4/23 12
- 13. 可扩展架构 – Sharding 2011/4/23 13
- 15. 架构扩展- B2C网站特点 • 产品数量基数不大，变更频率较低 • SKU数量基数不会太大，一般不会过千万级别 • SKU信息变化频率较小，基本上都是公司内部运营人员操 作，并发量小 • 产品数据并发访问量大 • 在线平台并发访问量大，且高峰时段集中 • 系统整体读多写少 • 读远远大于写，甚至超过10:1 • 和后端仓储库存物流交互复杂 • 和后端系统的交互较多，逻辑比较复杂，系统间数据同步 实时性要求较高 • …… 2011/4/23 15
- 16. 架构扩展- B2C网站应对策略 • 写入集中化，读取离散化 • 写入操作集中到一个核心数据库，方便后台管理维护 • 利用 MySQL 开发的复制协议，实时获取 MySQL Binlog 信息按 模块/类别/… 将数据分发至各个提供读取服务 的数据库节点 • 交易库与产品库分离 • 产品库读多写少，交易库写多读少，优化模型不一样， 可用性要求也不一样。 • 利用Binlog进行数据同步/分发，提高复制灵活度和效率 • 减少和后端的交互节点 • 跨系统交互维护成本高，开发复杂，出现异常的概率也 高。减少交互节点可以充分极大减少系统异常概率和交 互系统开发和维护成本 2011/4/23 16
- 17. 架构扩展- 写入集中,读取离散 2011/4/23 17
- 18. 架构扩展- 交易库/产品库分离 2011/4/23 18
- 19. 架构扩展- 减少和后端的交互节点 2011/4/23 19
- 20. 分析推荐系统-必要性 • 提升用户体验 • 降低用户查找成本，节约用户搜索时间 • 提升用户友好度，提升品牌形象 • 提升销量 • 提高滞销品曝光率，提高因曝光率不够导致滞销的产品 销量。 • 根据用户购买行为提升相关配套产品曝光率和销量 • 根据用户兴趣推荐相关产品激发用户购买欲 • … … 2011/4/23 20
- 21. 分析推荐系统-技术难点 • 基础数据难以收集 • 该收集哪些数据？哪些有用哪些没用？ • 数据量大，如何有效过滤无用数据？ • 收集范围广，如何降低收集程序的影响？ • 收集结果难以分析 • 收集结果数据量大，通过传统的关系型数据库或者是常 规日志分析工具难以处理。 • 分析模型各家都不一，没有合适的商业软件满足需求。 • 分析结果难以实时呈现 • 数据分析运算复杂，分析需要消耗较大量资源 • 用户在线时间不会太长，分析结果难以从离线分析系统 及时反馈在前台应用 2011/4/23 21
- 22. 分析推荐系统-架构组成 • 以关系型结构化方式将用户行为记录在MySQL中 • 以 BlackHole 存储引擎作为行为记录的基础表引擎 • 以 MySQL Infobright 对行为数据进行存储/分析 • 实时解析Binlog将行为数据发送至分析引擎数据中心 • 应用以标准的 SQL 接口对行为数据进行分析 2011/4/23 22
- 23. 分析推荐系统-数据层架构 2011/4/23 23
- 24. 分析推荐系统-理由 • 为什么不直接以文件存储用户行为信息 • 统一存储，统一接口，统一维护 • 为什么不用Hadoop/Greenplum等分布式计算系统 • 离线运算能力强，并发能力弱 • 为什么选择 MySQL Infobright • 标准 SQL 接口 • 列式存储，压缩比大 • 并发能力较高，可提供在线运算 • 知识网格技术/先进的优化器 • … … 2011/4/23 24
- 25. 分析推荐系统-Infobright 2011/4/23 25
- 26. END Q/A http://isky000.com 2011/4/23 26