根据我的情况看，看你线路质量和代理方式，我用新加坡的线路+shadowsocks，大部分情况都会比直接访问快一点。

@hepochen 有时需求很难实现，我会借助 map reduce，好像内嵌文档的 map reduce 比范式化的不易？

因为就一个人搞技术，情况复杂时有问题也没人讨论。

反正经历过这么一次后，把数据放 MongoDB 是谨慎又谨慎了。

@hepochen 谢谢
1、年月日我们是涉及一定范围内的统计的，更别说什么排序之类的，除非把数据全部取出来自己排。而如果是范式化的，就有现成的——当然数据处理不应该交给 MongoDB，这个时候才念起 SQL 的好来。
而且时间久了有可能出现巨大的内嵌文档（当然这个是设计错误，但是处理起来范式化的设计更容易处理点）。

2、字段是指有的字段包含大量数据，而不是说特殊字符。包含大量数据的字段，而且不是 PHP 这类用完就销毁的语言很可能内存爆满。范式化也有个好处是精准控制需要的数据。

3、我是在翻书后才知道，原话是「不断增长的内嵌文档将导致 IO 瓶颈」。如果 update 数据增长，也会是有问题的。当时我就一个进程后台默默写 MongoDB，也差不多写到了 IO 瓶颈——当然，数据量越大卡得越明显，刚设计完的时候还没发现。

除了性能，还要考虑需求实现是否方便。比如涉及日期范围的，用内嵌将会很痛苦（比如很多人把日期当做键而不是一个值……），操作内嵌文档，大多数命令也和范式化的不同。尤其是为了简洁，没什么多余字段的内嵌文档。
其次是大尺寸内嵌文档更难控制需要的字段，以前线上发现 tornado 内存不断增长却找不到原因，最后谨慎选择了下字段排除了不需要的、数据量大的字段就好了。

@hepochen 我的情况是不断 insert 的数据，卡得掉眼泪。

这个命题比一般人想象的更复杂，这个不应该参照普通 JSON 数据来。
应该搜索 「MongoDB 范式化 反范式化」。
举个我的血泪栗子：内嵌的 JSON 如果频繁更新，它就不应该是内嵌的，否则会有性能问题。

@est 明白了，不过用队列代码会越来越复杂…… 还是优化 SQL、拆分数据库、加缓存方便？

@est 但是 mysql 有多线程啊亲！起码不会影响其他用户的访问。

@Insomnia 我是新机……刚激活的时候没装，后面再去搜索 app store 价格也是免费的。

用异步的数据库驱动。。。

@eric_zyh 我前段时间激活的 4S 也是免费的Pages、Keynote、Numbers。

如果用 MongoDB，推荐motor，是一个异步的 mongodb 驱动，文档也比较齐全 http://motor.readthedocs.org/en/latest/differences.html

其他对应的异步驱动这里都有写：https://github.com/facebook/tornado/wiki/Links
但是大多数都看上去没经过大量考验，起码没多少人用。

@lichao 大概邮箱要签证了才能用 lol

我前几天买的 4S 进 app store 它还是免费的。

以前吃了一口就想吃第二口，结果一个晚上吃掉了半瓶，当零食吃……

最后内存需要像电池一样保养（绑定电池），然后当硬盘来用。

全都是个推荐码…… 注个小号有那么难么……

「动作的幅度超过一个阀值时」应该为「阈值」