借助 mongodb 实现扩展

借助 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. 尽情享用！

http://mms.mongodb.com/

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 亿文档

数据

亚洲互联网公司

借助 mongodb 实现扩展

Technology