mongodb在没使用SSD时就是个坑货

有ssd也抗不牢,还是将mongodb当成内存数据库来看好了..

还是应用场景来看，mmap方式的映射你始终要保证内存>索引+热数据size，否则长期fault不为零，内存和硬盘一直来回颠簸，你就是ssd也扛不住啊，可试着调整syncdelay。

@mongodb

mongodb 在坑货人眼里就是个坑货

你先给出数据呗。没数据要别人和你辩？

我说MySQL在没有SSD的时候就是个坑货 不服来辩 岂不是也适用？要人心服口服的时候没有数据，没有案例给出来。辩什么。呵呵

@ritksm 写过一个广告管理平台，流量不算特别大，反正就有HIT点击、访问这些统计数据，最终都存进了MongoDB了。起先是直接使用的MongoDB，在被主业务调用频次少时还好，大过后速度明显跟不上。后来用了别的内存KV数据库，队列处理数据才解决了这个问题。
配置啥的虽然我没去看，但如果这是MongoDB的优势的话，默认配置不体现出来热数据内存持久化真心很遗憾。

BTW，是去年写的平台，早已跳槽，最近工作中一项目可能用到MongoDB，所以再来挖挖以前被埋过的坑。

@xoxo 按我的理解是。你做了一个广告数据存储和查询的平台。

那么是否用了Index：http://docs.mongodb.org/manual/administration/indexes/
Index又是如何设置的，是否是设置在查询的键上了。

再者Index大小是否超过了内存的大小：http://docs.mongodb.org/manual/faq/indexes/#what-happens-if-an-index-does-not-fit-into-ram 如果超过了，一个是可能你的Index设计的不科学，还一个是你的内存太小了。这个时候无论什么数据库都会陷入窘境吧

再来说你的查询是如何优化的，当然这就涉及到了你的Document是如何设计的，如果嵌套过多的话性能必然也会受到影响

总之，如果你觉得MongoDB的优势在于热数据内存持久化的话，那么我觉得方向就不对。难道MySQL没有这个功能吗？

我个人认为MongoDB最大的优势之一就在于Document based design，那么你的数据模型可以尽可能的去模拟现实的情况，而不是表与表之间做关联。
还有优势就在于无比简单的shard和replica设置，现对于MySQL的M/S不知道简单了多少，当然如果复杂也可以很复杂

就说那么多吧。我觉得现在的技术发展并不是拼硬件，而是拼设计、理论，Hadoop的想法不也是把分布式系统放在“普通的机器”上么。SSD或者非SSD，完全就不应该成为衡量一个工具好与不好的标准。

退一万步来说，为什么访问量上来了以后你不在前面加Cache（如Redis）去缓存呢，这样可以减少直接读取数据库的次数。不管是不是MongoDB都应该这么做吧。

对MongoDB没啥研究，最近一个项目用了下。中途遇到过几次麻烦，一般加Sharding都能解决些问题，自动的Balance很慢。
MongoDB的更新是通过内存文件映射，默认5分钟或者1分钟同步到硬盘一次，如果业务对写要求高可用降低这个值，或者加Sharding。最后再考虑加SSD。
查询方面，MongoDB是文档数据库，意味着不需要那么多的关联查询。而这里的确MySQL更需要SSD。
还有就是要考虑冷（未加载在内存的数据）热数据的问题，随机的频繁对大数据查询对Mongo性能影响大。

@ritksm MySQL没有你说的那个功能，用MySQL那个功能一般都是靠Memcache来实现。

@xzl 我们之前就被搞过，随机冷数据读取导致Page Fault在二三十分钟都降不下去...

这个时候看起来的确很坑，io、负载啥的都很低。最后瓶颈锁在了netstat。

你知道SSD多贵么？

我也遇到Mongodb的性能问题, 明天调一下index,看看能优化多少.

看吧，你一说mongodb不行，他们就会说不是mongodb不行，是你不会用
看吧，你一说mongodb这个方面不好，他们就会说mysql更不好，连xxx都不支持

所有讨论mongodb的时候，mongo方都是这个思路，不信多看看，懒得辨

@likexian 呵呵 那你说如题主 不服来辩？