统一数据服务平台

用户
商品
交易
评价
垂直拆分问题
• • • • • 当单库iops达到几万次 单库连接数达到几千次 单库每秒SQL执行到几万次 搜索dump数据缓慢，DWETL缓慢 高端存储设备
异构的读写分离
• 写库为集中式的oracle环境，提供数据安全性保障 • 读库使用mysql，采用数据切分，分库分表，每台mysql放 少量的数据，单个数据分片内部采用mysql复制机制 • 读库的超大memory容量，起到了很好的cache作用,在内 存中的数据查询性能远远高于在硬盘上的性能 • Oracle到多台mysql按规则复制 • 分区键的选择至关重要，尽量让数据访问落在单台数据库 上 • 利用好当前的高端硬件，保护好自己的投资
业务模型的不同字段可能会来自不同的数据源，组装对象成本很高 延迟加载或按需返回设置不当,加载冗余数据会导致性能问题 呼唤缓存
• 问题2：网站数据非常庞大，缓存过多数据消费比不高，只能 缓存热点数据 • 分析：网站数据访问存在明显的热点分布
行业热点,占总数10%的热门行业的产品浏览量占全部商品浏览量的90%以上
热点匹配query.find(product.category.eq(“服装”)) . orderby(product.salenum.desc).limit(100).list()
• Cache Key规则设置
默认根据查询条件生产key
例如query.find(product.category.eq(“服装”)) . orderby(product.salenum.desc).limit(100).list() key: query.find(product.category.eq(“服装”)) . orderby(product.salenum.desc).limit(100)
对开发人员能力提出很高的要求
• 网站应用组装业务模型的数据查询需要多种数据源
带来开发的不敏捷，大量的资源消耗在无意义的模型组装上
• 网站应用直接依赖于底层数据源，模型发生变更将导致所 有相关应用大面积重构
例如商品模型的图片属性由数据库迁至图片银行
• 数据源改造也会导致相关应用的大面积重构
数据水平切分
热点缓存规则设置
• 设计了一套DSL,设置热点规则,Cache规则,过期规则 • 热点规则设置
根据查询条件表达式来设定热点规则
例如 缓存服装行业的产品,DSL <hotspot name=“rule1” expression=“product.category.eq(“服装”)”/>
通过查询API调用传入的查询条件表达式来匹配热点
统一查询更新API
• 统一数据服务平台采用统一的查询/新API,统一了不同数据源的 查询方式
查询API提供类似于JPA
基于模型表达式的查询方式 支持按模型属性的结果排序 支持限定结果返回条数和返回那些字段 和JPA的不同点 支持按需加载，可以指定返回哪些字段或者过滤那些字段
持久化API提供简单的接口
• 性能优化策略
字段延迟加载 字段按需返回值 架设L2 cache 异步并行加载机制：异步并行加载模型中来自不同数据源的字段 并发保护：拒绝访问频率过高的主机IP or IP段 过滤高危的查询:例如会导致数据库崩溃的全表扫描
热点缓存背景
• 问题1：性能问题
统一数据服务平台,数据架构大幅简化,开发敏捷,但性能问题 亦很严重
构建快速的数据查询
应用到DB的数据写入与查询从双向通行变成了单向通行 ，通行效率更高，大大避免了相互影响。“借道”行驶的 情况不再出现
水平拆分的问题
• 对于核心业务，停机时间有限，庞大的数据无法 在短时间内迁移 • 无法在短时间内完成项目发布过程中的测试工作
大数据量核心业务数据迁移的思路
• 先采用异构的数据库读写分离，将数据复制到目 标Mysql结点上，验证可靠性，机器压力 • 将写压力从Oracle结点迁移到mysql各结点， oracle停止写
内部教程 注意保密
统一数据服务平台专用教程
中程在线(北京)科技有限公司
网站架构发展历程
• • • • • Perl，CGI,Oracle Java Servlet EJB 去EJB重构（底层 MQ+ESB,数据挖掘,cms） Memcached集群,mysql,数据切分,分布式存储， Hadoop,KV,CDN • 安全镜像 • 敏捷，开放，体验（新一代网站架构的要求)
电子商务网站的特点
• • • • • • • • 高并发 数据实时性要求高 数据准确性要求高 大多数页面属于动态网页 网站需要大量的图片展示 用户通过搜索引擎广告类目导航寻找商品 网站读多写少，比例超过10:1 业务量快速增长
数据库里ቤተ መጻሕፍቲ ባይዱ数据
数据存在单台数据库中，用户，商品，交易等数 据都在一起，存在许多的关联查询，应用完全耦 合
提供基于业务模型的统一的查询和更新API，简化网站应用跨越不同数据源的 开发模式
性能优化策略
字段延迟加载，按需返回设置 基于热点缓存平台的二级缓存 异步并行的查询数据 并发保护 过滤高危查询
统一数据服务层模型
模型字段的数据路&Mapping DSL
• 问题
传统的O/Rmapping框架不能实现非关系型数据库和跨不同类型数据库的对象数据映射 统一数据服务平台需要提供除关系数据库以外的数据源的对象关系映射至少要支持目前 的关系型数据库，非关系型数据库MongoDB，Redis 统一数据服务平台支持同一业务模型的各字段映射到不同的数据
对于一些不太核心，业务不太复杂，相关影响点 不多的数据，可以直接进行迁移
数据生命周期之历史迁移
商品，交易，评价，物流等数据都有自己的生命 周期。通过历史数据迁移，减少在线库的容量， 提高在线库的性能。
OnLine Data
Data
Histroy Data
在线与历史应用分离
在线库与历史库重要等级不同，在线库更高 同一应用的在线应用与历史应用分离 高级别的应用不能直接依赖于低级别的数据库
• 跨数据源定位查找问题，实施缓存和性能优化困难
新网站架构
• 敏捷
1.业务快速增长，每天都要上线大量小需求 2.应用系统日益膨胀，耦合恶化，架构越来越复杂，会 带来更高的开发成本。如何保持业务开发的敏捷性
• 开放
Facebook和Appstore带来的启示，如何提升网站的开放 性，吸引第三方开发者加入到网站的共建中来
• 体验
网站的并发压力快速增长用户确定体验提出了更高的要
求
解决方案统一数据服务平台
• 在网站应用集群和底层数据源之间，构建一层代理 ，统一数据层 • 统一数据层的特性
模型数据映射
实现业务模型各属性与底层不同类型数据源的模型数据映射
支持关系数据和非关系型数据库如redis,mongodb
统一的查询和更新API
•
设计
模型数据映射DSL,定义模型字段和底层数据库的映射关系 设计一套DSL 描述模型对应哪些类型的数据源，各个数据源的访问方式是什么 模型有那些字段，每个字段对应哪个数据源的哪个字段或哪个数据接口方法 模型字段是否延迟加载 模型字段的值如果需要对原始数据进行逻辑处理，用何种逻辑方式处理 统一数据服务层阅读DSL定义的数据路由，访问不同数据源，组装模型
热点缓存 缓存失效机制
• 自动过期
1. 2. 绝对过期时间：绝对的时间点 相对过期时间：生存周期 商业数据发生变化时，会产生消息发送到MQ集群的指定队列 热点缓存失效任务监听数据变更事件，踢掉KV中的数据 数据变更时只更新缓存，不更新索引
• 基于EDA时间的过期
1. 2. 3.
• 索引失效
1.
2.
商品
主键查询 分布式缓存
管理类查 询
实时搜索
分布式数据库
注：考虑不同的读载体的技术实现 性 能和成本
用户
用户登录事件数据（日志量90%）与用户主数据（日志量 10%）分离，不仅要分表，而且要放到不的数据库集群中 ，并且做好不同数据等级的容灾处理
难题
• 数据库集群自动扩展仍然是个难题，但是是可以 忍受的，底层数据集群经过评估，扩展的频率并 不高 • MySql DDL 操作不变，锁表，对写操作影响较大 ，分了比较多的表，进一步加重了维护负担。
用户
商品 评价 交易
收藏
连接数问题
无论是小型机还是更高端的存储，随着数据的飞 速增长，都带来瓶颈问题。当oracle数据库连接 数达到5000个以后就相当吃力了。
数据垂直拆分
数据库系统按照不同的业务数据进行一系列垂直 拆分，这种拆分方式具有如下的特点：
1.拆分方式简单，只需要把不同的业务数据进行分离 2.避免了不同的业务数据读写操作时的相互影响 3. 该业务内部及其所导致的问题依旧
只有4个方法insert、update、delete、insertOrUpdate,参数就是对象
• 统一数据服务平台自动的分析查询/更新参数，并根据模型字段 映射配置，转换成底层各数据源的native语句进行数据操作
性能优化
• 问题：完成跨越数据源的对象查询非常消耗资源
业务模型的不同字段可能会来自不同的数据源，组装对象成本很高
数据变更时，更新索引需要遍历所有索引，非常耗时所以不主动更 新索引 客户端的容错机制保证,当索引内结果集的对象ID值，在KV中找不 到时，索引被动失效
热点缓存图例
查询异步化，并行化
• 问题：页面的数据请求过程耗时
1. 2. 3. 一个页面经常需要查询多个数据源 传统的编程模式是一种串行的请求方式 整个请求的耗时，等于所有数据请求的总和
• 缓存过期规则设置
绝对过期时间 相对过期时间 生存周期
热点缓存索引策略
• 缓存索引Index
缓存结果集合所有对象的主键列表 使用索引的原因，节约存储空间
假设不使用Index直接缓存至KV
热点缓存平台
查询/更新索引
热点缓存索引 Query1:id1,id..
使用Index直接缓存至KV
KV集群 [id1:model1]
在不同场景采用了各种类型的数据源
关系型数据库 搜索引擎，提供商业搜索服务 Cache KV,高性能场景 外部数据接口：如淘宝支付宝 文档数据库 列数据库，后台大规模计算场景
• 业务模型各个字段分布在不同数埃布据源
数据架构日益复杂
问题
• 数据架构复杂，应用需要直接依赖多种类型的数据源 • 开发人员需要熟悉各种数据源，以及访问方式
• 解决方案:异步并行加载框架Asyncload
io
• 目前一般的I/O的访问速度： L1 > L2 > memory > disk or network • 常见的IO：
1. 2. 3. 4. 5. 6. nas上文件 (共享文件存储) output/xxx (磁盘文件) memcache client / cat client (cache服务) database (oracle , mysql) (数据库) dubbo client (外部服务) search client (搜索引擎)
• 结论：缓存热点数据
以较少的存储代价，大大缓解应用系统和数据库的压力
• 解决方案:开发热点缓存平台，提供给统一数据服务平台作为 缓存系统
热点缓存设计
• 热点缓存平台
1. 作为统一数据服务平台的二级缓提供DSL，支持定义数据热点规则 2. 热点缓存平台有一级缓存索引，查询时首先根据条件匹配DSL，判 断热点 3. 如果匹配热点根据条件产生Cache Key 4. 根据Cache Key访问Cache Index,如果命中，返回一组查询数据的ID 列表 5. 根据查询结果数据的ID列表去KV系统中取得查询结果数据
OnLine Application Histroy Application
数据迁移 OnLine Data DataBase Histroy Data DataBase
商品访问框架
一般商品有几个主要查询 a.主键查询通过分布式数据库，以及分布式缓存系统解决 b.商品管理类查询，这一类查询数据量大，并且还有like查询 的需求，通过实时搜索解决
借鉴Ajax的思想运用到数据层服务 异步的并行加载同一业务场景中对不同数据源的查询
整个业务处理流程的总耗时，只取决于最慢一次查询 相对于ajax，不会对页面seo有任何的影响 减少了ajax异步发起的http请求 两块代码的资源不存在重复请求，允许进行资源共享
• 解决思路:异步并行查询
1. 2.
1. 2. 3. 4.
多种存储方案
• 不同场景使用不同数据源
关系型数据库 kv 文档数据库 外部数据接口 …
常见问题
1.海量数据面前，用什么策略来保障既能快速响应 用户的请求又能及时应对业务的发展 2.对于后台海量数据的处理如何设计 3.不同区域的数据同步如何处理 4.缓存处理
数据架构日益复杂
• 数据架构现状 • 数据架构非常复杂