#19 楼 @quakewang 我们也一直在服务器（CentOS）上用 RVM，很方便，几乎没有遇到什么问题。 不过老版本的 RVM 在开发环境（Mac）上安装 ruby 遇到过一些问题，但并不是 RVM 的问题，而是 xcode 和 C 编译器的问题。

#60 楼 @huacnlee #64 楼 @Rei 但愿是虚惊一场。安全是个大问题，不出问题没有任何感觉，出了问题通常就是致命的。

#58 楼 @Rei #59 楼 @huacnlee 别吓我，难道 ruby china 曾经被拖过库？ 貌似不太对，在 4 月 30 号的时候，我的 sign_in_count 应该远大于 10，而 topics_count 还没有到 17。

MongoDB 的安全性确实没有经过长时间考验，除了服务器、端口的安全，还有就是语句注入的问题，关系数据库的 SQL 注入曾经有血淋淋的经验教训，但是 MongoDB 安全这块才刚刚开始...

#56 楼 @Rei 不是的，没有见过这个 IP 这个 IP 貌似 浙江省杭州市 阿里软件有限公司 的

@Rei 哈，我根本没有部署 ruby china 的。一般外网的服务器上都有严格的防火墙设置，而且存储的服务器都不允许外网直接访问的。 @Rei 是广西老乡哦，我是广西南宁的，哈

#50 楼 @ihacku @huacnlee @Rei 什么情况？里面有我的 ID，我得赶紧改一下密码。

#26 楼 @fanzc 还在招啊

#22 楼 @lidashuang 哈哈，已经收到，回头和你联系。

#47 楼 @jasjia 这是啥么意思啊？

#40 楼 @gclsoft 哈，能否把你遇到的实际问题提出来，看看什么方法更合适。

#42 楼 @benzheren 仔细读了 http://docs.mongodb.org/manual/tutorial/build-indexes-on-replica-sets/，了解到为了避免建索引对 MongoDB 的冲击，还有这种方法：先把 secondary 停止重启进入 standalone 模式，然后再建立索引。建一个索引搞得如此麻烦，真是不爽。 background 建索引比前台建索引数据大很多 ，以前没有注意过，抽空用一个实例测试一下看看。

#41 楼 @benzheren 其实我也想迁移出去了，无奈的是“上了贼船”，下来就没有那么容易了 ...

一年前发过一个贴 Ruby 的常量查找路径问题 https://ruby-china.org/topics/4777 对 Ruby 常量查找路径问题讲得最清楚的一篇文章 Everything you ever wanted to know about constant lookup in Ruby http://cirw.in/blog/constant-lookup

#38 楼 @gclsoft MongoDB 就是通过牺牲 join，牺牲 跨文档跨集合（跨行跨表）事务支持，才获得了高性能，自动 sharding 等优良特性，这就是代价吧。

在应用要实现 join 的数据需求，有几种解决方法：

• 最基本的方法，在应用中通过多次的数据查询解决

• 在 MongoDB 中使用 embed document 方式

• 在 MongoDB 中建立冗余数据集，预先把数据 join 到一个集合中

• 使用外部检索引擎，比如使用 Solr 或者 Elastic Search 解决

具体的解释和例子说明够再写一大遍，有兴趣的话，我再专门弄一个帖子展开。

#35 楼 @gene_wu 哈哈，可以啊，不过我更喜欢讲一个 Redis 相关的主题，也正打算写一篇 Redis 的文章。

#33 楼 @gene_wu 嘿嘿，什么时候有活动啊？

#19 楼 @shangrenzhidao 智能算法起来很重要的作用。 薄荷是专注健康领域的公司，我们和普通健康机构最大的不同是我们收集了大量的个人健康相关数据（比如每天饮食，运动，体重，围度，生理期等等），通过这些数据分析给用户提供有准对性的、个性化的提醒，建议，更有效的帮助用户达成目标。

薄荷的后台是一套很庞大复杂的智能专家系统，需要智能算法工程师进行大量数据分析挖掘，数学建模的工作。

#17 楼 @shangrenzhidao 你是指智能算法工程师职位吗？这个职位我们刚收了一位复旦生物生态学的博士，目前暂时没有空缺了。

招聘还在进行中... 已经确定 2 位很棒人选，还有多个职位虚位以待，欢迎自荐或推荐，：）

#17 楼 @outman 非常棒的分享，哈哈，做一个主题贴发出来完全足够了。我呢主要谈了写操作引发的一些严重问题，关于读取方面，@outman 的分享很到位，这些都是需要注意的地方。

MongoDB 头上带了很多光环，也许它的商业宣传太成功了，以致让人误以为它就应该如此高性能了。但是实际深入使用过后，才好发现并非如此，它不是银弹，该怎么着还得怎么着，得摸清它的脾气，深入了解其中机制，了解很多最佳实践和注意事项，才可能调教好它。

#14 楼 @shiguodong 2.6 还没有集合锁，据说 2.8 会有文档锁。

infoq 上有 MongoDB 产品营销总监 Kelly Stirman 的访谈。

更细粒度的锁可能是请求最多的特性。与数据库级相比，你们更进一步的路线图是什么？与集合级锁相比，更进一步的主要障碍是什么？ 重要的是要记住，MongoDB 中的锁与 RDBMS 中的“闩（latch）”非常接近——它们非常简单，通常持有 10 微秒或者更少。MongoDB 2.2 引入了更高级的锁让步算法，显著减少了我们在社区中看到的与锁争用相关的问题的数量。不过，我们认识到，还有机会改进并发性，其中包括更细粒度的锁。 MongoDB 2.8 将具备文档级锁。我们认为，与集合级锁相比，这会更显著地改进更广泛应用程序的并发性。但是，更细粒度的锁只是改进并发性的一部分，我们将改进数据库的其它方面，以便在整体上提供更大的并发。MongoDB 2.6 已经包含了部分改进（参见下文），MongoDB 2.8 将带来更多。

希望不是营销人员的空头支票。访谈详细点这里

Embed 和 Array 不合理使用的问题不光是锁的问题，哪怕锁的问题解决了，这种情景下的如此使用的代价还是比较大的。

#9 楼 @winnie @billy @Peter 其实我们薄荷也就在一个比较新的项目上用了 MongoDB，目前绝大部分还是用 MySQL 和 Redis。 #9 楼 @winnie 那相当值得期待，回头好好研究一下，非常感谢。

#5 楼 @Peter 确有悔不当初的感觉，冲动的时候曾想全部换回 MySQL 算了，但是既然已经用了就难以回去了，只有硬着头皮去填坑了。

哈，人生不就在于折腾吗 珍爱生命，远离肥胖

#3 楼 @billy 哈，我是医生同学的同事啦。 选型 MongoDB 是一个复杂的问题，最主要说来是两大方面：

1. 更容易映射数据对象

如果被 MySQL 的 alter table 操作折腾过，你一定会觉得 schemaless 非常棒。 PostgreSQL 我了解不多。

2. 更好的扩展性，伸缩性

MongoDB 很容易分布式集群，failover, auto sharding 直接就提供了的，其它数据库做起来会很麻烦。

不过掉到上面几个坑的时候的确有悔不当初的感觉，但是既然已经用了就难以回去了，只有硬着头皮去填坑了。

#1 楼 @winnie 嘿嘿，这些都是比较深的坑，大家有遇到也欢迎补充啊。

#64 楼 @gene_wu @xiaoronglv 行啊，就这么说定了，今年在我们新办公室办一次大型活动，哈哈

#13 楼 @oldfritter 谢谢！已经收到你的邮件，回头联系你

#60 楼 @gene_wu 哈，谢谢，薄荷估计在 10 月份会搬新办公职场，新地方比现在大很多，而且在地铁口附近，到时候我们可以承办一次大型一点的 Shanghai RubyTuesday 活动，怎样？

@ucloudcn 只要需要，我们随时会提升的。我们对开源的支持相信大家有目共睹。 @huacnlee @lgn21st 貌似 RubyChina 目前还没有足够的云机资源做系统热备，有一次差点发生数据丢失的事故，@ucloudcn 已经发话了，可以提供吧

#59 楼 @zzz6519003 好，我明天再联系你。