花了两天时间看完nodeclub的源代码，感觉用了MongoDB，就没有必要用redis了。

是吧，我也一直这么觉得

1. mongodb 确实会把数据加载到内存，不过你看各种测速结果，都不会告诉你 mongodb 跟 redis 是做同一层面的事情的。mongodb 跟 mysql 才是同一层面的东西。mysql innodb 也会把数据缓存到内存中。 mongodb 跟 redis 速度差很多。这不在于数据在内存还是硬盘，还在于他们查询和插入时候要经历的步骤，以及数据按什么方式存储在内存中。
2. nodeclub 类似的产品，作为教学目的用用 mongodb 没关系，实际的开发中，类似的产品用 mysql 更合适。一些统计需求用 mongodb 做起来很蛋疼，不能关联查询也很蛋疼。
3. 渲染 html 这块的话，我确实想过好好做一下，当时的思考在这里：https://cnodejs.org/topic/55210d88c4f5240812f55408 。后来由于懒，没有怎么做。其实html渲染消耗性能的话，对于服务器来说，多加几个 cpu 就好了。不过对于用户体验来说，会增加不少的渲染时间。我们现在首页在 200ms 的 rt，帖子页一般在 100ms 这样。其实还是比较挫的。
4. 服务器请求这块的话，没有像 v2ex 做得那么细致，其实 cnode 一直是比较脆弱的。很多类似的事情，增加了代码的复杂度，对于新手看代码阻碍很大，并且在开源的情况下， 我也拿不准自己能做出一个透明却有效的防恶意刷帖机制。

对于 3、4 点，不得不承认，一半是懒，一半是不想增加代码复杂度。

@alsotang 很赞，很牛，很无私。楷模。

@alsotang 第二点是有点带有主观情绪的，除了事务还是事务，这已经不再那么难于处理了，另外，mongodb的查询还是可以的，如果要多表查询，也是有很多办法的。其实最恶心的是大家不习惯面向key做设计，没架构经验会被玩死

@i5ting 我支持alsotang的观点，nosql技术不能说不好，但处理复杂查询上还有点缺陷的。我个人觉得，nosql技术有点像以前Java中的hibernate，用的时候很爽，优化的时候想死。再说，面向关系的数据库设计是经过时间验证的，面向key的设计，还需要时间来验证。 最近我看到很多公司的代码，mongodb、mysql、redis 同时使用，这些开发者有时都搞不清这个数据应该放那儿。在技术栈不成熟的情况下，尽量少用新技术，拿不准的事情不要做。

@zouzhenxing 拿hibernate举例容易被喷，优化的时候想死只能说明你对hibernate不够理解。和说mongdob不好查询是一样的，不要直接在生产的数据上直接做关联，都是key会非常难受，你可以加一层，相关数据汇总，变成大的宽表就好了，或者更负责的上es类的。

大家的舒适区都在rdbms上，所以有这个感觉是正常的，mysql如果没有dba优化也挺难的

最后一个：混用多种的时候，对开发的要求会非常高，这种正确的做法是封装成服务让开发调用，而不是尽量少用新技术，拿不准的事情不要做。公司里只要有一个人能搞定，其实就够了

@zouzhenxing 如果用rdbms，当项目非常大的时候，你的er模型和范式都是无法遵守的，一样会造成查询的问题，比如很多公司禁止用join。。。先去哭一会

@i5ting 拿什么举例都会被喷的，这是一种造句方式；XXXX不好，是因为你对XXXX不够深入不够了解。其实你想说我和我想表达的都一样的东西，每个技术都是有自己的适用范围的，超出范围了就有瓶颈。我也不反对新技术，我是从项目角度去看这个问题。 现在这个浮燥的时代，每个领导都想三天造飞机，五天造火箭。我们搞技术的，就算设计得再完美，老板一催，就开始乱写，完成任务是第一嘛。在面向领导的开发中，那有时间去研究这些细节。所以还不如搞一些成熟的技术，至少犯的错误不会离谱。我就是这个意思。呵呵

redis源码 1.5M - -。 这就是我为什么用它- -。

@zouzhenxing 哈哈，把境界放高点，如果完全面向领导干技术和当公务员就没啥区别了

争论更多的是起点不同，如果2个你都熟悉，争论才有意义。技术发展这么快，以一个积极的态度面对，才能乐此不疲的

@MiguelValentine 棒棒哒

看看大神之间的对话也是蛮有收获的

@MiguelValentine 你这样强行装一波，我感到很吃力

@i5ting 不错，学习可以激进点。项目，我个人还是保守点。

@alsotang mongodb和mysql的"表"结构设计理念是完全不同的. 比如我设计一个单据流程,里面涉及原型单,审核规则,审核结果,审核意见.如果是关系型数据库,那肯定是各自一张表,join查询,操作也是事务加锁 但在mongo里面,我是把他们放在一个collection里面,因为我认为这几个单据组合起来,才是一个完整的审核流程,而操作一个单个collection,也不存在什么join 事务了.写起代码来,简直不要太方便. 除了流量多点,几乎没什么影响.

看你的痛点是什么了。redis可以用来写队列，缓存自动过期什么的，mongodb实现就很尴尬了。而我早就放弃mongodb，回到mysql了。没办法，符合实际项目需求的才是好东西

这两个不是一个东西吧 -。 -

redis 做缓存做队列的 mongodb 做数据库的

两者的目标都不一致吧...

@178220709 用 mongodb 来做这个场景，我听你说着都怕。

统计报表怎么跑出来的？mongodb mapreduce？

@captainblue2013 充气，爆炸－ －

@alsotang mongodb可以用populate做关联查询啊，如果同时要使用aggregate的话，就只能先用aggregate，再populate

@alsotang mongodb的aggregate不比sql语义差, 甚至某些方面更强. 只是性能方面会有一些差距.

@qujinxiong populate是mongoose的, mongoose的实现性能差一些, 是取到文档, 再去取关联的. aggregate是一下取出来.

@joesonw 对，aggregate 是 mongodb 的，populate 是 mongoose 的。

Good

mongodb的aggregate+mapreduce已经足够强大，如与spark集成应对大数据分析也能胜任。另外redis和mongo也是两个层面上的东西。主要还是要看理解程度加怎么用