在百度云的应用(2015年):
通信录,短彩信备份
网盘图片视频meta (分片数达到了30个)
网盘图片时光轴;
用户操作日志;
数据规模
网盘图片meta 数目在千亿以上。
业务数量几百个
数据总量PB级别 (几百台物理机)
部署结构:
入口: rest 统一入口
磁盘: 使用ssd, 做 raid0
主从: 一主多从(1-3); 核心业务 一主三从, 像用户日志采用 一主一从。
关闭balance, 均衡与扩容依靠外部工具。
2.2 版本,均衡问题:
ns 粒度单任务,oplog 同步ns 级串行并发。
解决:
关闭均衡
运维工具并发均衡,oplog并发同步。
运维工具长期运行。
2.2版本问题:慢查询问题。
解决: 运维工具遍历并杀死慢查询。
长期运行。
3.0 加上 timeout参数。
3.0版本 crash 问题
wiredTiger 对索引字段做了长度限制
索引字段长度超限 crash
解决: 去掉字段
Mongodb 在京东中的应用:
商品信息
比价:
关注/订阅
日志
复制集实践
架构图一:
使用副本集代替主从(master slave)架构
部署奇数个节点(投票 目的)
使用通用的arbiter机器以节省资源
Primary和Secondary 放在不同的机柜上 或者 在不同的机房 以便容宅; 机器是双电
每个机房 必须分配一个单独的机器 部署 arbiter( 开启几百个实例)
Read Preference:
默认的 Read Preference 模式: Primary.
是不是可以使用 Secondary 或者 SecondaryPreference 实现读写分离来提高系统的承载能力?
- Secondary 节点写压力跟Primary 基本是相同的, 所以操作在从库上并不会提高查询速度。
- 由于是异步复制数据,所以读取 Secondary的数据可能是过时的。
- 分片架构中使用读写分离的时候有可能会丢失数据或者读取到重复数据
两种比较好的可以使用读写分离的读操作
- ETL作业, 分析查询,备份或者Hadoop 作业
- 跨地域的查询(双机房)
关于存储的一个建议:
如果系统中有大量的delete 或者update 操作,或者在某个集合上使用了TTL索引,那么最好使用usePowerOf2Sizes = true 标签 // 2的 n次方大小
db.runCommand({collMod: “products”, usePowerOf2Sizes : true})
分片架构实践
图 jd-2
Sharding 架构中使用中的一些建议:
保持集群中机器的时间同步,时间差不能超过30s;
error.clock skew is too far ou of bounds to allow distributed locking
选择一个好的片键。一个好的片键必须保证数据可以均匀的分布到各个片上,可以让CRUD 能够利用局部性索引,可以有足够的力度拆分chunk
开启 releaseConnectionsAfterResponse 参数: //防止链接过多 如 :几万个
db.runCommand({setParameter: 1, releaseConnectionsAfterResponse : true})
设置 connPoolMaxShardedConnectionsPerHost 参数
mongos — setParameter connPoolMaxShardedConnectionsPerHost = 250( since 2.6 默认是200
定时清理孤立文档(2.6)
db.runCommand({
cleanupOrphaned : “<database>.<collection>”,
startingFromKey: <minimumShardKeyValue>
secondaryThrottle:<boolean>
})
监控和备份
Zabbix server && 模版 Template && agent
使用db.serverStatus() and rs.status() 收集监控指标
备份:
- 全量备份 mongodump
- 延迟备份
cfg = res.conf
cfg.members[0].priority = 0
cfg.members[0].hidden = true
cfg.members[0].slaveDelay = 3600
rs.reconfig(cfg)
- 增量备份和增量恢复
mongodb 在赶集网应用:
成功案例1:
pv浏览计数
如果是mysql 用多张表 count() 就不容易实现了
使用的设备:
3台2u物理机, 32G内存, 各配2块SSD
线上10亿数据, 1.5T硬盘
日均访问量约 3kw
mongodb2.2.2 3 replicate set, 3 shards
日志 — 经过分析在mongodb 更新 post:155=> 800 , incr
// scribe —>storm —> mongodb
只提供http接口取数
选型对比:
redis :浪费内存, 数据持久化恢复慢
ssdb : 解决内存问题, 但仍需客户端实现分片
mongodb : 自动分片, 跨机房应用。
成功案例2:
用户中心:
提供登录, 注册, 收藏,
第三方登录, 绑定, 手机邮箱认证, 绑定
用户帖子查询等业务功能
关系简单, 纬度单一,uid 聚合数据
设备:
用户中心:
mongodb 2.2.7 , 32 replicat sets, 128 shards;
18台2u服务器, 64G内存, 普通盘 hdd
线上13亿数据, 1.5T 磁盘大小
每天用户中心请求千万级别
为什么MySQL?
同样数据量与请求,用mysql 完全可以
MySQL 没有shard解决方案。
连接mongodb 中间件/ 跨语言调用
服务化, 不允许第三方值连 mongodb
c++ thrift 解决跨语言调用。
引入队列,请求过多开启过载保护
尽量用长连接,本身对php支持不够好。
jira 网站