MongoDB 不确定的地方还是很多。因为 Cache 使用 Memory-mapped 的原因，在进行 sharding 的时候，sharding key 选择要很小心，不然像出现 4sq 那样的问题，修都没法修，只能停掉整站重新做 sharding。
也因为 cache 的原因，一些随机 I/O 也很讨厌。

现在 MongoDB 的写入锁还是全局的，没法实现单一 collection 的写锁。这个有点要命。虽然写入内存的速度很快，但是谁也不知道大数据量的时候会怎样。

使用 replica set 之后网络间的通信也是一个问题。sourceforge 为此采用了读写都在 master 上进行这样的架构。

http://www.quora.com/Quora-Infrastructure/Why-does-Quora-use-MySQL-as-the-data-store-instead-of-NoSQLs-such-as-Cassandra-MongoDB-CouchDB-etc

引用 Adam D'Angelo 的更新：a friend's startup that was going through explosive growth tried to switch to MongoDB and gave up after a month due to instability

MongoDB 也是给有钱人用的，没有大内存的机子很难发挥优势。况且使用 BSON 后也十分消耗硬盘。有兴趣的人可以那这个和 MySQL 做比较。

所以我觉得 MongoDB 还需要再等等，可以用些小项目，但是做主力数据库，有点悬。

Textmate 党表示 T 键容易坏。。

@keakon 赞同。底层数据结构的改变会导致上层一系列逻辑的改变。这个不是在一星期内能想清楚的。

Livid 加油！

可以放 div 在 table 里，控制 div 的宽度。

@lianghai 同喜欢。。

@ayanamist 我现在在用 Task Queue，做后台计算。

本身 Transaction 就无法应对高写入啊，你的例子需要用到 http://code.google.com/appengine/articles/scaling/contention.html 这篇文章用到的东西。

@ayanamist 大量的写入可以用 Task Queue 来做。如果是 back-end 需求，现在也有新的服务提供了。 我觉得 Google 提供的 Transaction 已经很棒，ACID 都满足了。对于一个分布式的架构，能做到这点很牛逼。

你真的有 entity 达到每次 5 秒的写入频率？如果你的 app 一天使用 10 个小时，那也是而是万 PV 每天啊。即便有，Google 也有提供文档告之如何避免 Data contention 吧。

@lepture 做社区类型的，还是需要吧。尤其是一个贴有很多回复的，过了 1000 个，用 range 这个方法就不行了，除非用每一个回复的 id 做 primary key。

嗯，全文搜索，赞同。我也在为这个伤脑筋。。

高效率的分页很痛苦。

One-to-Many relationship 需要仔细设计。

我在英国用 Spotify，但是广告太他娘多了....

于是就去虾米了。

Monaco

douban

nice.

为楼主最后一段喝彩。

@icarian 嗯 就是那个视频。 他的AK扫射压枪之稳啊.....

@sparklo 忘@ 你了。答复在#11

Johnny.R 是AWP之神啊。。。

Potti和HeatonN还有spawn，这三个人在一起无论枪法战术可能都是当时的最佳组合吧。

我还看过1.3时代HeantonN用asdf这个名字玩32人大图乱战，那叫一个疯狂啊。

俺当年的偶像是 HeatonN