在 twitter 上听说

「我说为毛TL上这么多「来往」推广呢，原来是阿里的员工被逼完成指标。可以想象，当指标完成后，在「来往」互加的好友就老死不相往来了。」

@sophy 第一眼望去还以为是域名停放页面

@Nick 哈哈哈看来他们公司的招聘广告是 HR 写的。

我的是2011的。偶尔会出现很奇怪的问题，重启下就好了。大部分时间里都不需要关机、重启。

烂大街的dedecms不也是全部生成的么，禁用PHP也照样不影响访问，一般需求能满足。

眼花了，原来「Robomongo」不是错拼……

有个客户端叫 MongoHub，但是几年没更新，老是闪退。 RockMongo 不错。

建议首页一句话描述和系统的任务切换有什么区别，光一个截图和「Simple. Easy. Fast」和「Manico is a fast app launch and switch tool designed for OS X.」实在看不懂这个软件到底有什么优点。

我觉得这句话才说明了软件用途「 when you want to switch to an app, hold the Option key and press the target number, you will be switched to the target app immediately. If this app hasn't launched yet, Maco will also launch it.」
但是又太长而且太靠下方。

看见「有妹子要同去吗」心都凉了

@hhrmatata 我是在 oneasiahost 买的最便宜的方案（ $12/季度），一个月流量 100GB，也用不完。
也有日本和香港的 VPS，日本的虽然便宜，线路可能没香港、韩国、新加坡好。香港的没找到便宜的，线路是不错。

根据我的情况看，看你线路质量和代理方式，我用新加坡的线路+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、拆分数据库、加缓存方便？