借助 mongodb 实现扩展
TRANSCRIPT
借助 MongoDB 实现扩展
Thomas BoydMongoDB 解决方案体系结构主管
MongoDB 扩展
1 2 3 4 5 6 7 80
5,000
10,000
15,000
20,000
25,000
30,000
MongoDB 集群 吞吐量
节点数
操作数/
秒
议程• 优化技巧
– 架构设计– 索引– 监视– WiredTiger
• 纵向扩展• 横向扩展• 扩展运维团队
优化技巧:架构设计
文档模型• 匹配应用程序对象• 灵活• 高性能
{ "customer_id" :123,"first_name" : ”John","last_name" :"Smith","address" : { "street": "123 Main
Street", "city": "Houston", "state": "TX", "zip_code": "77027"
}policies: [ {
policy_number :13,description: “short
term”,deductible:500
},{ policy_number :14,
description: “dental”,visits: […]
} ] }
架构设计的重要性• 与 RDBMS 架构设计截然不同• MongoDB 架构:
– 反规范化数据– 通过预先知道的实际(而不是预计)查询模式创建(可能很复杂的)架构– 编写简单查询
真实示例销售遍布 20 个国家 / 地区的零售商产品目录{
_id:375,en_US: { name: …, description: …, <etc…> },en_GB: { name: …, description: …, <etc…> },fr_FR: { name: …, description: …, <etc…> },fr_CA: { name: …, description: …, <etc…> },de_DE: …,<… and so on for other locales …>
}
未能很好地匹配访问模式实际应用程序查询:
db.catalog.find( { _id: 375 }, { en_US: true } );db.catalog.find( { _id: 375 }, { fr_FR: true } );db.catalog.find( { _id: 375 }, { de_DE: true } );… 其他区域以此类推
资源利用效率低红色数据正在使用。蓝色数据占用内存,但并非所需。
{_id:375,en_US: { name: …, description: …, <etc…> },en_GB: { name: …, description: …, <etc…> },fr_FR: { name: …, description: …, <etc…> },fr_CA: { name: …, description: …, <etc…> },de_DE: …,de_CH: …,<… and so on for other locales …>
}
{_id:42,en_US: { name: …, description: …, <etc…> },en_GB: { name: …, description: …, <etc…> },fr_FR: { name: …, description: …, <etc…> },fr_CA: { name: …, description: …, <etc…> },de_DE: …,de_CH: …,<… and so on for other locales …>
}
重新设计架构的结果• 查询引起最低内存开销• 多于 20 倍的产品同时装入 RAM• 磁盘 IO 使用率降低• 应用程序延迟减少
{_id:"375-en_GB",name: …,description: …, <… the rest of the document …>
}
架构设计模式• 模式:理想情况下,为每次写操作预计算关注的量• 模式:将无关项放入不同集合以便充分利用索引• 反模式:无限制地附加到数组• 反模式:将关系型架构直接导入 MongoDB
架构设计资源• 深入探讨数据建模,下午 2 点
Robertston 礼堂 1
• 博客系列,“ 6 rules of thumb”– 第 1 部分: http://goo.gl/TFJ3dr– 第 2 部分: http://goo.gl/qTdGhP– 第 3 部分: http://goo.gl/JFO1pI
• 网络讲座、培训、咨询等…
优化技巧:编制索引
B 树索引• 文档的树形结构引用• 单个最大可协调性能因素 • 索引编制和架构设计齐头并进
索引编制错误及其修复• 无法构建所需索引
– 运行 .explain() ,检查较慢查询日志、 mtool 、 system.profile 集合• 构建不必要的索引
– 与应用程序开发人员讨论用法• 在生产中运行即席查询
– 使用模拟环境,使用从节点
mongod 日志文件Sun Jun 29 06:35:37.646 [conn2] query test.docs query: { parent.company:"22794", parent.employeeId:"83881" } ntoreturn:1 ntoskip:0 nscanned:806381 keyUpdates:0 numYields: 5 locks(micros) r:2145254 nreturned:0 reslen:20 1156ms
mtool• http://github.com/rueckstiess/mtools• 对性能较差的查询进行日志文件分析
– 显示从早上 6 点到晚上 6 点之间所用时间超过 1000 毫秒的查询:
– mlogfilter mongodb.log --from 06:00 --to 18:00 --slow 1000 > mongodb-filtered.log
索引编制策略• 创建支持查询的索引!• 创建选择性高的索引• 消除具有复合索引的重复索引
– db.collection.ensureIndex({A:1, B:1, C:1})– 允许查询使用最左前缀
• 排列索引列以支持扫描和排序• 创建支持覆盖查询的索引• 防止在预生产环境中进行集合扫描
db.getSiblingDB("admin").runCommand( { setParameter: 1, notablescan: 1 } )
优化技巧:监视
立即行动吧
在预生产 /压力环境中
MongoDB Management Service (MMS)
备份
监视
自动化
MMS :数据库指标
MMS 监视设置
MMS 云版本1. 访问 http://mms.mongodb.com2. 创建帐户3. 在数据中心内安装一个代理4. 在 Web 界面中添加主机5. 尽情享用!
WiredTiger 存储引擎
提升 7 倍到 10 倍性能,减少 50% 到 80% 存储原理: WiredTiger 存储引擎• 相同数据模型,相同查询语言,相同运维团队• 文档级并发控制推动写性能提升• 本地压缩推动存储节省• 完全向后兼容• 非破坏性升级
MongoDB 3.0MongoDB 2.6
性能
纵向扩展
因素:– RAM– 磁盘– CPU– 网络
我们愿帮助您进行扩展
主节点从节点从节点
复制集 主节点
从节点
从节点
复制集
工作集超出物理内存
真实示例• 业务实体的状态更改• 批量更改状态
– 有时更新 10% 的实体– 有时更新 100%
初始架构分片集群,旋转磁盘支持的 4 分片
应用程序 / mongosmongod
横向扩展快速增长的业务意味着更多分片
应用程序 / mongos
…16 个以上的分片…
mongod
纵向扩展通过 SSD 扩展随机 IOPS
应用程序 / mongosmongod SSD
增加硬件之前 ....
• 确保已解决正确的扩展问题• 首先解决架构和索引问题
– 架构和索引问题可能看起来像硬件问题• 调整操作系统
– 使用管理程序调整 ulimits 、 swap 、 NUMA 、 NOOP 计划程序• 调整 IO 子系统
– ext4 或 XFS 对比 SAN 、 RAID10 、 readahead 、 noatime
• 参阅 MongoDB“ 生产说明”页面• 留意日志文件启动警告
横向扩展
分片概述
主节点从节点从节点
分片 1
主节点从节点从节点
分片 2
主节点从节点从节点
分片 3
主节点从节点从节点
分片 N
…
查询路由器 查询路由器 查询路由器……
驱动程序
应用程序
范围分片
mongod
读 / 写可扩展性
键范围0..100
范围分片
读 / 写可扩展性
mongod mongod
键范围0..50
键范围51..100
分片
mongod mongod mongod mongod
键范围0..25
键范围26..50
键范围51..75
键范围76..100
读 / 写可扩展性
片键特征• 好的片键应具有:
– 充足的基数– 分布式写入– 针对性读取(“查询隔离”)
• 片键应尽可能位于每个查询中– 否则为分散聚合查询
• 选择好的片键非常重要!– 影响性能和可扩展性– 以后更改代价高昂
注意升序片键• 单调递增片键值会导致插入上出现“热点”• 例如:时间戳、 _id
分片 1
mongos
分片 2 分片 3 分片 N
[ ISODate(…), $maxKey )
扩展运维团队
MongoDB Management Service (MMS)
轻松扩展满足 SLA
最佳实践、自动化 削减管理开销
未使用 MMS
部署示例 - 12 台服务器安装、配置150 多个步骤
… 错误处理、限制、告警
横向扩展、迁移服务器、调整 Oplog 大小等10-180 多个步骤
升级、降级100 多个步骤
使用 MMS
常见任务,执行时间以分钟为单位• 部署 – 任意大小、大多数拓扑• 升级 / 降级 – 无需宕机• 扩展 – 添加 / 删除分片或复制集成员,无需宕机• 调整 Oplog 大小 – 无需宕机• 指定用户、角色、自定义角色• 配置 AWS 实例并针对 MongoDB 进行优化
扩展 MonoDB
2.5 亿条分笔成交数据 / 秒30 多万次操作 / 秒50 多万次操作 / 秒联邦机构
性能1400 台服务器1000 多台服务器250 多台服务器
娱乐公司集群
千兆字节数百亿对象130 亿文档
数据
亚洲互联网公司