Flowdock是一个基于Web的团队通讯工具.所有的软件开发人员都应该使用它进行沟通,而不是使用Campfires、Skype Chats或IRC等工具.因为它可以更好的的支持他们的真实工作流.
上周,我们对Flowdock的数据库服务做了一次切换,聪从Cassandra迁移到了另一种NoSQL工具-MongoDB.由于我们的技术选择已经引起了大家的部分兴趣,我将在此向公众说明下我们的决策理由.
我们的部分客户一定对下面这个图片记忆犹新:
从一定程度上讲,我们遭遇到了Cassandra的稳定性问题.所有的节点都陷入无线无限循环(infinite loop),运行垃圾回收工作(GC, Garbage Collection)并尝试压缩数据文件-并偶尔导致集群瘫痪.除了对集群进行重启并经常性的手工对节点做压缩工作以让其稳定一会外,我们无计可施.其他人也报告过类似的问题.在前面几周的时间里,我们的Cassandra节点总是会吃掉给他分配的所有资源,而导致Flowdock运行缓慢.
由于我们刀口嗜血式的数据库选择(James注: 这是我不认同的地方,可能对于一些Startup的公司来讲,这是一种不得已的选择.),这已经不是我们第一次遇到此类问题了.从Cassandra 0.4升级到0.5的时候,我们被迫关闭了整个集群,仅仅是为了将所有的数据刷新到磁盘上(虽然,我们已经按照文档进行了手工刷新的操作).这个操作导致我们丢失了几分钟的讨论内容,以及我们手工创建的索引出现严重的不一致,以致于需要做完全的重建.我想,我们最后离开办公室的时间已经是凌晨4点了.
从我们最初选择Cassandra到现在,NoSQL社区已经出现了很大的变化.MongoDB已经发生了很大的改变,最近新增的自动分片(auto-sharding)与副本集(replica set)使得它可以作为Cassandra的有力的替代品.因此,我们决定试试MongoDB.
写从Cassandra往MongoDB的数据迁移的脚本耗费我一天的时间.在一周左右的时间内,我们已经可以完全在MongoDB上运行Flowdock了.在生产环境部署MongoDB之前,内部测试持续进行了好几个星期.
目前,我们已经完成这个调整,
1. 智能(多键)索引. 手工维护的索引令人生厌,MongoDB可以自动帮我们维护所需的索引.例如,我们的消息包含标签(tag),例如下面这个格式的document:
- { content: "Write a blog post about #mongodb.",
- workspace: 'myflow',
- tags: ["mongodb", "todo", "@Otto"] }
- 这样,如果仅检索自己的任务,Flowdock的后台只需要做下面这个查询:
- db.messages.find({
- workspace: 'myflow',
- tags: { $all: ["todo", "@Otto"] }
- })
2. 查询.无论数据模型多么简单,每当需要执行一个查询的时候,你都不需要提前规划此事.在MongoDB中,你可以直接在控制台定制复杂的查询,这一点非常类似于SQL数据库.它会据此执行一次顺序扫描,这比在客户端手工处理上百万的记录要更快捷也更便利.
3. Map-Reduce. 这是分析人员的利器啊.MongoDB的Map-Reduce功能支持虽然不是非常完美,但它起码很易用.
4. GridFS让我们的文件存储操作变得非常容易.它的存储能力可以随着我们的MongoDB集群的扩展一起增长.
我们也遭遇到部分轻微的限制:
1. 我们发现了一个JSON解析的bug,不过我们在10分钟内就解决了此bug.
2. BSON的Document键中不支持点(dot).通常,这或许不是个问题,但是我们必须在数据迁移中解决此问题.
3. Document有4MB的大小限制.这对于我们的数据模型来讲不是问题,由于MongoDB对在位的原子更新(atomic in-place updates)有非常好的支持,所以,你需要关注,Document不要超过4MB的限制.
4. 增加新的节点没有在Cassandra中那么容易.然而,Cassandra在新增节点的负载均衡上有它自己的问题.
到目前为止,它的运行还非常平稳.开发人员与数据库管理员的工作也因此减轻了很多.
原文链接：http://www.dbthink.com/?p=599&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+dbthink+(a+db+thinker's+home
【编辑推荐】
