mongodb 在foursqure中的应用及教训

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

发布于 13 Aug 2013 10:26
标签 blog mongodb nosql

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

图中路由机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）：

单纯的［x，y］的数据是无法建立索引的，所以MongoDB在建立索引的时候，会根据相应字段的坐标计算一个可以用来做索引的hash值，这个值叫做geohash，下面我们以地图上坐标为［4，6］的点（图中红叉位置）为例。
我们第一步将整个地图分成等大小的四块，如下图：

划分成四块后我们可以定义这四块的值，如下（左下为00，左上为01，右下为10，右上为11）：
01 11
00 10
这样［4，6］点的geohash值目前为 00
然后再将四个小块每一块进行切割，如下：

这时［4，6］点位于右上区域，右上的值为11，这样［4，6］点的geohash值变为：0011
继续往下做两次切分：

最终得到［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
先上高清大图：

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