你好,游客 登录 注册 发布搜索
背景:
阅读新闻

Mailbox:日支撑过亿信息数据库的性能调优及集群迁移

[日期:2013-10-03] 来源:CSDN  作者: [字体: ]

在Mailbox快速扩展过程中,其中一个性能问题就是MongoDB的数据库级别写锁,在锁等待过程中耗费的时间,直接反应到用户使用服务过程中 的延时。为了解决这个长期存在的问题,我们决定将一个常用的MongoDB集合(储存了邮件相关数据)迁移到独立的集群上。根据我们推断,这将减少50% 的锁等待时间;同时,我们还可以添加更多的分片,我们还期望可以独立的优化及管理不同类型数据。

我们首先从MongoDB文档开始,很快的就发现了 cloneCollection命令。然而随后悲剧的发现,它不可以在分片集合中使用;同样, renameCollection也不能在分片集合中使用。在否定了其它可能性之后(基于性能问题),我们编写了一个Python脚本用以复制数据,和另一个用于比较原始和目标数据的脚本。在这个过程中,我们还发现了许多有意思的事情,比如 geventpymongo复制大数据集的时间是 mongodump(C++编写)的一半,即使MongoDB客户端和服务器在同台主机上。通过最终努力,我们开发了 Hydra,用于MongoDB迁移的工具集,现已开源首先,我们建立了MongoDB集合的原始快照。

问题1:悲剧的性能

早期我做了一个实验以测试MongoDB API运作所能达到的极限速度——启用一个简单的使用MongoDB C++ 软件开发工具包的速度。一方面对C++ 感觉厌烦,一方面希望我大多数熟练使用Python的同事可以在其他用途上使用或适应这种代码,我没有更进一步的探索C++的使用,而是发现,如果是针对少量数据,在处理相同任务上,简单的C++应用速度是简单Python应用的5-10倍。

所以,我的研究方向回到了Python,这个Dropbox默认语言。此外,进行了诸如对mongod查询等的一系列远程网络请求时,客户 端往往需要耗费大量时间等待服务器响应;似乎也没有很多copy_collection.py (我的MongoDB集合复制工具)需要的CPU密集型操 作(部分)。initialcopy_collection.py占很少的CPU使用率也证实了这一点。

然后,MongoDB请求到copy_collection.py.。最初的工作线程实验结果并不理想。但接下来,我们通过Python Queue对象来实现工作线程通信。这样的性能依旧不是很好,因为IPC上的开销让并发带来的提升黯然失色。使用Pipes和其他IPC机制也并没有多大 帮助。

接下来,我们尝试了使用单线程Python进行MongoDB异步查询,看看可以有多少性能结余。其中Gevent是实现这个途径常用库之一,我们对它进行了尝试。Gevent 修改了标准Python模块以实现异步操作,比如socket。比较好的一点是,你可以简单的编写异步读取代码,就像同步代码一样。

这种简单的代码可以根据它们的_idfields,从MongoDB源集合拷取代码到目标位置,它们的_idfields是每个 MongoDB文档的唯一标识符。opy_documents 会产委派greenlets运行runcopy_document()做文档复制。当greenlets执行一项阻塞操作,比如对MongoDB的任何需 求,它会将控制放给其它准备执行的greenlet。因为所有greenlets都在相同的线程和进程中执行,你一般不需要任何形式的内部锁定。

有了gevent,就能够找到比工作者线程池或工作者进程池更快的方法。下面总结了每种方法的性能:

ApproachPerformance (higher is better)
single process, no gevent 520 documents/sec
thread worker pool 652 documents/sec
process worker pool 670 documents/sec
single process, with gevent 2,381 documents/sec

综合gevent和工作者进程(每个分片一个)可以在性能上得到一个线性提升。有效使用工作进程的关键是尽可能使用更少的IPC。

问题2:快照后的复制修改

因为MongoDB不支持事务,如果你对正在执行修改的大数据集进行读取,你得到的结果可能会因时而异。举个例子,你使用MongoDB find()进行整个数据集上的读取,你的结果集可能是:

  • ncluded: document saved before your find() 
  • included: document saved before your find() 
  • included: document saved before your find()
  • included: document inserted after your find() began 

此外,为了在Mailbox后端指向新副本集时能最小化故障时间,尽可能减少从源集群应用到新集群过程中所耗费的时间则至关重要。

类似多数的异步复制存储,MongoDB使用了操作日志oplog记录下了mongod实例上发生的增、改、删操作,用以分配给这个mongod实例的所有副本。鉴于快照,oplog记录下快照发生后的所有改变。

所以这里的工作就变成了在目标集群上应用源集群的oplog记录,从 Kristina Chodorow的教学博客上,我们清楚了oplog的格式。鉴于序列化的格式,增和删都非常容易执行,而改则成为了其中的难点。

改操作的oplog日志记录结构并不是非常友好:在MongoDB 2.2中使用了duplicate key,然而这些duplicate key并 不能通过Mongo shell呈现,更不必说大部分的MongoDB驱动。 深思熟虑之后,选择了一个简单的变通方案:将_id嵌入修改源文档,以触发其它的文档副本。因为只是针对修改,虽然不能做到副本集和源实例的完全同步,但 是却可以尽可能的减少副本集实时状态与快照之间的差距。下面这个图表显示为何中间版本(v2)并不一定完全相同,但是源副本与目的副本仍能保持最终一致:

在这里同样出现了目标集群的性能问题:虽然为每个分片的ops使用了独立的进程,但是连续的ops性能仍然匹配不了Mailbox的需求。

这样ops的并行就成了必选之路,然而其中的正确性保证却并不容易。特别的是,同_id操作必须被顺序执行。这里采用了一个 Python集去维持正在执行修改ops的_id集:当copy_collection.py上发生一个请求正在执行修改操作的文档时,系统会阻塞后申请 的所有ops(不管是修改或者是其它),直到旧的操作结束。如图所示:

>

验证复制数据

比较副本集与源实例数据通常是个简单的操作,但是在多进程与多命名空间中进行却是个非常大的挑战。同时基于数据正在不断的被修改,需要考虑的事情就更多了:

首先使用compare_collections.py(为对比数据开发的工具)对最近修改的文档进行数据校验,如果出现不一致则进行提醒,随后再进行复查。然而这对文档的删除并不有效,因为没有最后修改的时间戳。

其次想到的是“ 最终一致性”, 因为这在异步场景中非常流行,比如MongoDB的副本集和MySQL的主/从复制。经过非常多的尝试之后(除下大故障情景下),源数据和副本都会保持最 终一致。因此又进行了一些反复对比,在连续的重试中不断的增加backoff。发现仍然有一些问题存在,比如数据在两个值之间摇摆不定;然而在修改模式 下,迁移的数据并不会出现任何问题。

在执行新旧MongoDB集群的最终转换之前,必须确保最近ops已经被应用,因此我们在 compare_collections.py增加了命令行选项,用以对比文档被修改的最近N个操作,这样可以有效的避免不一致性。这个操作并不用耗费太 多的时间,单分片执行数十万的ops对比只需短短的几分钟,还能缓和对比和重试途径的压力。

意外情况处理

尽管使用了多种途径去处理错误(重试、发现可能的异常、日志),在产品迁移之前的最终测试中仍然出现了许多未预计的错误。 出现了一些不定期的网络问题,一个特定的文档集会一直导致mongos断开与copy_collection.py连接,以及与mongod的偶然连接重 置。

而在尝试之后,我们发现针对这些问题制定出专门的解决方案,所以快速的转到了故障恢复方面。我们记录了这些compare_collections.py 检测出的文档_id,然后专门建立了针对这些_id的文档重复制工具。

最终迁移时刻

在产品迁移过程中,copy_collection.py建立了一个上千万电子邮件的原始快照,并且重现了过亿的 MongoDB ops。执行原始快照、建立索引,整个复制过程持续了大约9个小时,而我们设定的时限是24个小时。期间我们又使用 copy_collection.py重复3次,对需要复制的数据核查了3次。

全部转换直到今日才完成,与MongoDB相关的工作其实很少(只有几分钟)。在一个简洁的维护窗口中,我们使用 compare_collections.py对比每个分片的最近的50万个ops。在确保最后操作中没有不一致后,我们又做了一些相关测试,然后将 Mailbox后端指向了新集群,并将服务重新为用户开放。而在转换之后,我们未收到任何用户反馈的问题。让用户感觉不到迁移,就是最大的成功。迁移后的 提升如下图所示:

写锁上的时间减少远高于50%(原预计)

开源Hydra

Hydra是上文操作所用到的所有工具合集,现已在 GitHub上开源

收藏 推荐 打印 | 录入:574107552 | 阅读:
相关新闻      
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款