mongodb 在foursqure中的应用及教训

博客首页 » mongodb 在foursqure中的应用及教训

发布于 08 Jun 2014 02:40
标签 blog
200px-Foursquare-logo.png
foursqure可以说是mongodb的顶级应用之一了,网上搜索了一下,故事还真不少,值得记录下来。
http://blog.nosqlfan.com/tags/foursquare

Foursquare 长达 11 小时的宕机

http://blog.nosqlfan.com/html/696.html

作者:nosqlfan on 星期五, 十月 8, 2010 · 6条评论 【阅读:2,523 次】
本文转载自著名博客DBA Notes,Foursquare是目前最流行的LBS应用,就像在MongoDB官网上看到的一样,其底层应用了MongoDB进行一些重要数据的存储。而最近的长达11小时宕机,正是由于MongoDB的问题导致的。
原文链接:http://www.dbanotes.net/arch/foursquare_outage.html
前几天 Foursquare 经历了长达 11 个小时的宕机,没错,11 个小时。网站官方的解释是 Shard 负载不均匀造成后续的连锁反应。很多人都知道 Foursquare 在线的 DB 是 MongoDB,今天又看到 10gen (MongoDB的开发与支持团队)的 Eliot Horowitz 在得到 Foursquare 许可后,通过邮件组详细介绍了宕机的过程:Foursquare outage post mortem,不用说,也有为 MongoDB 辟谣的意味在里面。
读罢 10gen 团队的介绍(或者说解释)之后,发现这是一个很好的研究样本。值得分享。
为了提高响应速度,Foursquare 使用 MongoDB 存储 Check-in 的数据已经有一段时间了。这部分数据的数据库起初跑在一个 66GB 内存的 Amazon EC2 单实例上(全部在内存里),两个月前,出于对容量增长的考虑,迁移到两台 Shard 集群上。每个 Shard 机器都是 66GB 内存,为了冗余,每个 Shard 都有复制到 Slave 实例。迁移的目标是所有的 Check-in 数据都保存在内存中。数据根据 ID 分成 200 个 Shard 分片,两台机器各占一般,也就说联机数据在每台机器上各使用 33GB 的内存。两个月相安无事。
问题来了,因为 Shard 算法导致的数据分散不均衡,其中一台(Shard0)数据增长到 67GB(另外一台 50GB),超过了 66GB 的限制,读写部分分散到磁盘上,性能急剧下降。从而,网站宕机。
首先尝试增加第三台 Shard 机器,上线后开始迁移,读取从三台进行,Shard0 的数据迁移到 5% 的时候,但是写操作还是让 Shard0 宕机了。这个时候发现Shard0 存在数据碎片(data fragmentation),即使数据迁移走,还是会占用原来的内存。每个Check-in 文档大约占用 300 字节,而 MongoDB 是 4KB 的页(Page),也就说十几个文档会填满一个页,而迁移 5% 反而造成了页更加稀疏,并不是将页全部删除。
这个时候已经到了第二天,随着网站全面宕机,技术团队开始用 MongoDB 的 repairDatabase() 功能来对数据库进行压缩,因为数据库太大和 EBS 慢,也因为 repairDatabase() 不能充分利用多核CPU 的能力,这个过程耗费了 4 个小时。之后这 5% 的内存空间终于释放出来,系统重新上线。
随着 Shard0 修复,第三台成功上线,进而添加了更多的 Shard 服务器,现在数据已经更加的均衡,通过在Slave上运行 repairDatabase(),然后将其切换到 Master ,每台 Shard 内存占用缩减到 20GB左右。整个故障时间已经延续了 11 小时之多。
产生问题的主要原因就是系统过载,前面介绍每台 Shard 承载原来 50% 的压力,到了问题发生的时候,单台 Shard 的负载已经超过 Shard 之前的系统负载,这时候已经积重难返了,在容量的临界点增加新系统资源,必然导致更多的停机时间。暴露了 Foursquare 团队在容量规划方面的不足之处,或许也因为业务增长太快了吧。另外,内存碎片化的问题在没有宕机之前,技术团队应该没考虑过这个问题,如果文档的大小超过 4K,碎片化问题就不严重了,这是特定应用场景造成的特定问题。10Gen 现在已经着手研究如何进在线压缩(online compaction)。再次,Shard 键值的顺序和插入顺序是不同的,这造成了迁移数据的时候 Chunk 的迁移不是连续的。
这个过程给我们的启示是:最近 NoSQL 已经成为一个热词,类似 MongoDB 这样的新事物当然值得尝试,但是不能冒进,因为驾驭起来并非易事。仅仅能够使用是不够的,系统没出问题一切都好,一旦出了异常,有足够的技术力量(设想一下 Foursquare 得不到 10gen 团队的支持会如何?) 支持么?在极端情况下如何控制? 如果回答不了这个问题,那么还应该暂缓。最好的办法就是…”等待”。
给我的另一个感慨是 Amazon 在云计算领域已经真的成为一个赢家,而且越来越得到 Web 2.0 Startup的信赖。前面说的 66GB 内存,应该指的是EC2 的 “High-Memory Double Extra Large Instance”,可提供的最大内存是 68.4 GB 。CPU 和内存能力都是可以接受的,存储方面的性能似乎还有点不足,也就是其中的 EBS ,指的是 Amazon Elastic Block storage。

auto-sharding无用论:auto-sharding vs manual-sharding

数据库memcachedmongmanual-shardauto-shardin
摘要:auto-sharding一直是MongoDB的一项引以为豪的特性,而这一回它可以会像我们国内的某些砖家叫兽一样,成了理论的巨人,实践的侏儒。下面一篇文章从各个方面对auto-shrading的可用性进行了批驳。
auto-sharding一直是MongoDB的一项引以为豪的特性,而这一回它可以会像我们国内的某些砖家叫兽一样,成了理论的巨人,实践的侏儒。下面一篇文章从各个方面对auto-shrading的可用性进行了批驳。希望能引发你一些新的思考。

一、美好的蓝图

刚接触MongoDB的时候,看到它的auto-sharding功能图,配合上replica sets简直有一种一统世界的感觉。既下图:

mongodb auto-sharding
1331222O8-0.png

图中路由机mongos可以有多台,config机器可以多台配置成主从或者replica sets,sharding的每个结点是三台mongod组成的replica sets。高可用性,无限扩展性尽在眼前。看似宏伟壮观。

然而当我真的打算要用auto-sharding功能的时候,才发现此设计根本不适用,下面谈一点我个人的看法。

Sharding一词的翻译是分片,在这里的意思是将数据进行水平切分。最简单的例子就是我们在数据库设计中的分库分表,在Memcached缓存中的多结点hash存储。而MongoDB的auto-sharding功能重在一个auto(自动化分片)。官方称,使用这一功能,你只需要指定数据分片依赖的某个字段值,既可在不关心具体结点数量的情况下存储你的数据,数据会自动平均分配到后端结点,在增加结点时,数据又会自动的进行迁移,对整个系统进行负载平衡。相比我们传统的分库分表,它是auto(自动)的,而传统方法是manual(手动)的。

二、Foursquare宕机事件

看罢上面的描述,好像没有任何可以挑剔的理由,但事实并不如描绘的那样美好,从Foursquare长达11小时的宕机事件分析中,我们可以看到如下一些问题:

1.auto-sharding算法导致数据分配不均:事实上数据并不会那么平均的在各个机器间平均分配,由此而造成的短板效应是无法忍受的。

2.数据迁移代价过大:在增加新的sharding结点时,数据确实会自动的进行迁移,而这种迁移对于原来线上服务的结点,服务上是有影响的。所以我们最好在存储瓶颈到来很早之前就开始做这个迁移,而这样做,和我们手动进行分片,预先估算好数据量相比,优势不再明显。

3.数据迁移造成碎片:同样是Foursquare的失败经验,在数据迁移时,我们需要迁移的数据通常并不会在磁盘上进行连续存储(除非你的hash条件是天然的insert时间戳)。而我们又知道MongoDB采用的是磁盘空间预分配的机制,于是在数据迁移时,可能并不会减小磁盘占用空间,反而会使得磁盘碎片化。更甚的是由于MongoDB在是采用mmap提速数据访问,磁盘空洞并不会减小mmap的大小,反而导致内存也碎片化。

而以上一些问题,在我们预先规划好存储量的manual-sharding上,是不存在的。

三、冷数据不冷

我认为在存储规划上,可以简单的从两方面来评估,一是磁盘占用,也就是总数据量,二是内存占用,也就是热数据量。热数据在全部数据的中所占的比例,通常会越来越小。造成这一原因的是老数据的访问量下降。我们考虑这样一种情况,如果你的应用用户量和每日新增数据量已经相当稳定,我们以最近三天的数据为热数据进行评估,那么总数据量会随着时间的增长而增长,而热数据量永远是三天的量。我们这里举的是一个极端的例子,可能你的用户量会每天增长,但是热数据量在全部数据中占的比例,通常是越来越少的,这个事实不容反驳。

上面说了这么多,下面我们来看我们的问题。

1.auto-sharding数据量变化情况:和我们上面说的情况一样,auto-sharding机群会通过增加结点数来扩展集群的存储能力。结点数和数据量成线性的正比关系。

2.auto-sharding的热数据比例:auto-sharding一旦一个结点配置完成,那么这些机器的内存与磁盘空间比就定了。于是整个集群的热数据比例占所有数据的比例也是一定的。

而对比我们上面的说法,热数据占比例在所有数据中是会越来越小的。于是我们可以认为,auto-sharding中的老结点浪费掉了大量的内存和CPU资源。

而如果我们是人为手动进行分片,我们完全可以自己控制数据的存储,自行设定自己的LRU或者TTL机制,将老数据,冷数据进行存储转移,不再占用高性能机器的各项机能。从而让我们公司花大钱买来的机器能够物尽其用。

Foursquare:使用MongoDB Replica Sets的三种架构

http://www.dedecms.com/knowledge/data-base/nosql/2012/0820/8850.html

MongoDB 的replication机制除了最普通的Master/Slave模式之外,更强大的就是其支持自动故障转移的 Replica Sets 模式了。相对于其问题多多的 auto-sharding 机制,Replica Sets还是相对比较稳定。 作为MongoDB使用大户, Foursquare (简称4sq) 在MongoDB使
MongoDB 的replication机制除了最普通的Master/Slave模式之外,更强大的就是其支持自动故障转移的Replica Sets模式了。相对于其问题多多的auto-sharding机制,Replica Sets还是相对比较稳定。
作为MongoDB使用大户,Foursquare(简称4sq) 在MongoDB使用上有相当丰富的经验,下面是4sq的一篇文章,描述了Replica Sets机制在4sq 中的几种架构方式。
原文链接:Fun with MongoDB replica sets
1.在原有的Master/Slave 机制上添加一台arbiter
4sq 在早期有一些Master/Slave的MongoDB架构,但这种模式不能实现自动的故障转移,需要在发生故障时手动进行切换。在Replica Sets出现后,这种结构被迁移成为三台机器的Replica Sets:一台Primary,一台Secondary,一台Arbiter。
迁移过程:
修改Master和slave的配置,添加如下几项,并重启MongoDB。
replSet=auxdb
fastsync=true
rest=true
fastsync 使得重启动可以使用到原来的数据文件,重启会非常快。然后再在Primary上用rs.add 和 rs.addArb 将Secondary和Arbiter添加上。就算完成了。
2.一个 Primary用于写,多个Secondary用于读和一个Secondary用于备份
在写多读少的应用中,4sq主要使用了Replica Sets来实现读写分离。通过在连接时指定slaveOk,将读操作放到Secondary上,Primary只承担写操作。同时指定一台priority为0,hidden为true的Secondary来进行备份(这样设置后此机器在读写中都不可见,并且不会被选举为Primary)
3.MongoDB经典配置,上层是Auto-Sharding,每个Sharding结点又是一个Replica Sets
虽然4sq在这上面吃过亏,但很明显他们已经吸取了教训并且在更合理更小心的使用Auto-Sharding这一诱人的功能。

图解 MongoDB 地理位置索引的实现原理

http://www.dewen.org/q/6181
作者:nosqlfan on 星期四, 六月 9, 2011 · 3条评论 【阅读:4,392 次】
地理位置索引支持是MongoDB的一大亮点,这也是全球最流行的LBS服务foursquare 选择MongoDB的原因之一。我们知道,通常的数据库索引结构是B+ Tree,如何将地理位置转化为可建立B+Tree的形式,下文将为你描述。
首先假设我们将需要索引的整个地图分成16×16的方格,如下图(左下角为坐标0,0 右上角为坐标16,16):
map1.png单纯的[x,y]的数据是无法建立索引的,所以MongoDB在建立索引的时候,会根据相应字段的坐标计算一个可以用来做索引的hash值,这个值叫做geohash,下面我们以地图上坐标为[4,6]的点(图中红叉位置)为例。
我们第一步将整个地图分成等大小的四块,如下图:
map2.png划分成四块后我们可以定义这四块的值,如下(左下为00,左上为01,右下为10,右上为11):
01 11
00 10
这样[4,6]点的geohash值目前为 00
然后再将四个小块每一块进行切割,如下:
map3.png这时[4,6]点位于右上区域,右上的值为11,这样[4,6]点的geohash值变为:0011
继续往下做两次切分:
map4.png
map5.png

最终得到[4,6]点的geohash值为:00110100
这样我们用这个值来做索引,则地图上点相近的点就可以转化成有相同前缀的geohash值了。
我们可以看到,这个geohash值的精确度是与划分地图的次数成正比的,上例对地图划分了四次。而MongoDB默认是进行26次划分,这个值在建立索引时是可控的。具体建立二维地理位置索引的命令如下:
db.map.ensureIndex({point : "2d"}, {min : 0, max : 16, bits : 4})
其中的bits参数就是划分几次,默认为26次。

foursquare 的数据分析系统(Hadoop+Hive+Redis+MongoDB)

作者:nosqlfan on 星期三, 三月 16, 2011 · 评论本文 【阅读:6,176 次】
foursquare 作为当下最火热的LBS应用,其checkin数据在去年已经达到了4亿次,面对庞大的数据,他们搭建了一套数据分析系统。本文就是对此系统的一个介绍。
原文链接:http://goo.gl/lfwlg
先上高清大图:
InfographicBlogPost-1.png

分析系统利用Hadoop 的Map/Reduce 功能来进行数据分析,多台机器组成集群进行并行计算。
在Hadoop上层用Hive 完成数据接口转换功能。Hive 是一个将Hadoop封闭成类似于SQL数据库的中间层组件。
在用户与数据分析中间,是一个由Redis,MongoDB 和 Rails 组成的数据服务器,它充当获取数据的中间角色,让数据分析系统与用户完全分离。

其他链接

http://hi.baidu.com/hevensun/item/1b3721ef5a8046d0ea34c985
http://www.cnblogs.com/xinghebuluo/archive/2012/01/18/2308753.html


本页面的文字允许在知识共享 署名-相同方式共享 3.0协议和GNU自由文档许可证下修改和再使用,仅有一个特殊要求,请用链接方式注明文章引用出处及作者。请协助维护作者合法权益。


系列文章

文章列表

  • mongodb 在foursqure中的应用及教训

这篇文章对你有帮助吗,投个票吧?

rating: 0+x

留下你的评论

Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License