首页   注册   登录
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
推荐工具
RoboMongo
推荐书目
50 Tips and Tricks for MongoDB Developers
Related Blogs
Snail in a Turtleneck
宝塔
V2EX  ›  MongoDB

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

  •  
  •   xoxo · 2013-12-12 23:13:55 +08:00 · 8921 次点击
    这是一个创建于 2166 天前的主题,其中的信息可能已经有所发展或是发生改变。
    不服来辨
    17 回复  |  直到 1970-01-01 08:00:00 +08:00
        1
    advancedxy   2013-12-12 23:34:44 +08:00
    有ssd也抗不牢,还是将mongodb当成内存数据库来看好了..
        2
    xzl   2013-12-12 23:43:29 +08:00
    还是应用场景来看,mmap方式的映射你始终要保证内存>索引+热数据size,否则长期fault不为零,内存和硬盘一直来回颠簸,你就是ssd也扛不住啊,可试着调整syncdelay。
        3
    ericFork   2013-12-12 23:48:28 +08:00
        4
    linode   2013-12-12 23:52:17 +08:00
    mongodb 在坑货人眼里就是个坑货
        5
    ritksm   2013-12-12 23:54:04 +08:00
    你先给出数据呗。没数据要别人和你辩?
        6
    ritksm   2013-12-12 23:55:18 +08:00
    我说MySQL在没有SSD的时候就是个坑货 不服来辩 岂不是也适用?要人心服口服的时候没有数据,没有案例给出来。辩什么。呵呵
        7
    xoxo   2013-12-12 23:58:35 +08:00   ♥ 1
    @ritksm 写过一个广告管理平台,流量不算特别大,反正就有HIT点击、访问这些统计数据,最终都存进了MongoDB了。起先是直接使用的MongoDB,在被主业务调用频次少时还好,大过后速度明显跟不上。后来用了别的内存KV数据库,队列处理数据才解决了这个问题。
    配置啥的虽然我没去看,但如果这是MongoDB的优势的话,默认配置不体现出来热数据内存持久化真心很遗憾。
        8
    xoxo   2013-12-12 23:59:49 +08:00
    BTW,是去年写的平台,早已跳槽,最近工作中一项目可能用到MongoDB,所以再来挖挖以前被埋过的坑。
        9
    ritksm   2013-12-13 00:06:38 +08:00   ♥ 5
    @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都应该这么做吧。
        10
    griffinqiu   2013-12-13 00:26:04 +08:00
    对MongoDB没啥研究,最近一个项目用了下。中途遇到过几次麻烦,一般加Sharding都能解决些问题,自动的Balance很慢。
    MongoDB的更新是通过内存文件映射,默认5分钟或者1分钟同步到硬盘一次,如果业务对写要求高可用降低这个值,或者加Sharding。最后再考虑加SSD。
    查询方面,MongoDB是文档数据库,意味着不需要那么多的关联查询。而这里的确MySQL更需要SSD。
    还有就是要考虑冷(未加载在内存的数据)热数据的问题,随机的频繁对大数据查询对Mongo性能影响大。
        11
    griffinqiu   2013-12-13 00:28:52 +08:00
    @ritksm MySQL没有你说的那个功能,用MySQL那个功能一般都是靠Memcache来实现。
        12
    griffinqiu   2013-12-13 00:31:43 +08:00
    @xzl 我们之前就被搞过,随机冷数据读取导致Page Fault在二三十分钟都降不下去...
        13
    griffinqiu   2013-12-13 00:33:33 +08:00
    这个时候看起来的确很坑,io、负载啥的都很低。最后瓶颈锁在了netstat。
        14
    zeinima   2013-12-13 02:36:41 +08:00
    你知道SSD多贵么?
        15
    cyr1l   2013-12-13 03:16:35 +08:00
    我也遇到Mongodb的性能问题, 明天调一下index,看看能优化多少.
        16
    likexian   2013-12-13 09:56:46 +08:00
    看吧,你一说mongodb不行,他们就会说不是mongodb不行,是你不会用
    看吧,你一说mongodb这个方面不好,他们就会说mysql更不好,连xxx都不支持

    所有讨论mongodb的时候,mongo方都是这个思路,不信多看看,懒得辨
        17
    xzl   2013-12-14 16:59:54 +08:00
    @likexian 呵呵 那你说如题主 不服来辩?
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   742 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 70ms · UTC 20:59 · PVG 04:59 · LAX 12:59 · JFK 15:59
    ♥ Do have faith in what you're doing.