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

Mangodb 的缺点是什么?性能?

  •  
  •   shyrock · 2015-07-01 17:39:52 +08:00 · 14046 次点击
    这是一个创建于 1605 天前的主题,其中的信息可能已经有所发展或是发生改变。
    最近一个项目打算采用mangodb替换mysql。吹了一堆好处后,销售问我,这些好处的代价是什么?他不懂技术,但是坚持一个朴素的理念“有得必有失”。

    我翻了一下网络,发现根据CAP原则,mangodb的归类是CP,是牺牲了可用性来保证一致性和分片容忍性,换句话说mangodb的性能比归类为CA的mysql在性能上应该有所降低。
    但是很遗憾,网上做两者性能对比的文章观点互相矛盾,且都不具权威性。

    所以想问问各位有没有权威的说法啊?
    88 回复  |  直到 2015-08-25 23:20:12 +08:00
        1
    CIVITAS   2015-07-01 17:40:55 +08:00
    Mongodb.
        2
    avastms   2015-07-01 17:41:32 +08:00
    就是没有事务,没有Join
        3
    tabris17   2015-07-01 17:41:50 +08:00
    没有事务
        4
    blacktulip   2015-07-01 17:42:25 +08:00
    没有权威说法,实测方知
        5
    9hills   2015-07-01 17:43:51 +08:00
    你看到的什么文章。MongoDB性能不如MySQL,人用它干嘛,难道没有事务比带事务还要慢?
        6
    lilydjwg   2015-07-01 17:45:19 +08:00
    我的感受:

    1. 不支持事务
    2. 不支持 schema、值约束等等 SQL 才有的东西
    3. 程序都是静态链接的,一个程序十几 M
    4. mongo 命令行 shell 使用 linenoise 而不是 readline,中文支持问题严重

    另据说 MongoDB 存 JSON 的性能不如 PostgreSQL 9.4 的 jsonb 数据类型。
        7
    shyrock   2015-07-01 17:53:50 +08:00
    小结一下,截止6楼提到的都是没有事务和值约束、外键这些,然而这些都跟CAP原则中的A可用性没有关系啊。换句话说,Mangodb比mysql多了分盘容错性的好处,但是却没有因此而付出代价。
        8
    TheJuli   2015-07-01 17:59:55 +08:00
    @shyrock
    MongoDB
    *
        9
    aisk   2015-07-01 18:00:04 +08:00
    CAP 理论是针对分布式系统的,跟你单机使用没有关系。
    另外求楼主千万不要用 mongodb,因为 mongodb 现在最大的问题就是属于这种「不知道现在系统有什么问题」「不知道新的系统解决了什么问题」的人误用导致的各种问题。
        10
    blacktulip   2015-07-01 18:05:26 +08:00
    CAP 不单是针对分布式系统的,而且跟性能没有关系,可用性跟性能是两回事
        11
    Had   2015-07-01 18:16:58 +08:00
    坑很多... 修坑很慢,尤其Query Plans相关的... 很痛苦有没有...
        12
    shyrock   2015-07-01 18:18:13 +08:00
    @aisk 忘了在问题里面说明,就是在分布式系统中使用的,可没有说是单机系统。
    我这不是在使用之前专门求教MangoDB的优缺点吗?您的意思是只有生而知之的人配得上用MangoDB?
        13
    shyrock   2015-07-01 18:18:46 +08:00
    @blacktulip 求教CAP中的A可用性是指什么?
        14
    shyrock   2015-07-01 18:19:35 +08:00
    @Had 被你一说,心里有点怕。。。都这么些年了,应该还是基本可用吧?
        15
    xlrtx   2015-07-01 18:20:32 +08:00
    好像不支持acid
        16
    Had   2015-07-01 18:24:34 +08:00   ♥ 1
    @shyrock 来看看这张卡。
    https://jira.mongodb.org/browse/SERVER-13866

    最后那个人的回复就是我们遇到的:
    If I drop and regenerate the index the problem resets itself, but I assume that's similar to just restarting mongod. What is normally a 1ms query jumps to 100ms or more.
        17
    yoa1q7y   2015-07-01 18:33:55 +08:00
    Mongodb
    Mongodb
    Mongodb
    Mongodb!!!
        18
    shyrock   2015-07-01 18:37:24 +08:00
    @Had 看懂了,不过这应该是bug。其实我想问的是MangoDB在设计上所付出的代价是什么,也就是说理论上无法通过补丁解决的问题。
        19
    shyrock   2015-07-01 18:38:15 +08:00
    @yoa1q7y Sorry,前几个人的提醒我以为重点是大小写呢。。。
        20
    shyrock   2015-07-01 18:38:59 +08:00
    @9hills 不是所有数据库设计都以性能为第一诉求的。。。
        21
    seki   2015-07-01 18:40:01 +08:00
    实在忍不住吐槽了
    一堆人在指出拼写错误楼主还是我行我素 - -
        22
    shyrock   2015-07-01 18:42:17 +08:00
    @seki 喏,你看前一个回复。
        23
    incompatible   2015-07-01 18:46:05 +08:00   ♥ 1
    CAP讲的是分布式系统
    我们讨论数据库时要讨论的是ACID

    mongodb无法做到ACID,所以对事务有要求的应用不适合用它。
        24
    blacktulip   2015-07-01 18:56:46 +08:00
        25
    zxp   2015-07-01 18:57:23 +08:00
    https://github.com/dcramer/mangodb

    License
    If you use this, you must donate $1 to someone more intelligent than you.
        26
    shyrock   2015-07-01 19:11:19 +08:00
    仔细看了wiki,确实说到CAP是适用于分布式计算系统。
    那么问题是MongoDB作为分布式NoSQL数据库,在Availability这项上面付出的代价到底是什么?
        27
    shyrock   2015-07-01 19:13:14 +08:00
    @zxp 这不算代价。
        28
    lijianying10   2015-07-01 19:31:23 +08:00
    我觉得,要是做的话,还是结合各家所长来用比较好。

    其实MongoDB数据库里面有函数:
    之前我就研究过: http://www.philo.top/1899/11/30/788MongoDB%E5%AD%98%E5%82%A8%E8%BF%87%E7%A8%8B%E6%80%A7%E8%83%BD%E8%B0%83%E4%BC%98/

    MongoDB的插入性能是非常好的,只是你不能建立太多的Index最好是用有意义的ID来存储。
    Update也不推荐
    千万不要Delete不然文件里面就有个洞。
    Select的时候直接拿ID说话就可以了。

    所以不管是是用什么数据库,得看业务啊。
    脱离业务讨论技术,不会有什么结论。
        29
    wintersun   2015-07-01 19:32:47 +08:00
    @shyrock 晕死,人家调侃的是Mangodb,而不是Mongodb
        30
    anubiskong   2015-07-01 19:45:28 +08:00
    @lijianying10 delete会有个洞是什么意思?
        31
    TangMonk   2015-07-01 20:01:14 +08:00
    坑多
        32
    lijianying10   2015-07-01 20:06:45 +08:00
    @anubiskong
    http://stackoverflow.com/questions/5518581/mongodb-data-remove-reclaim-diskspace
    删除数据会在硬盘文件上。
    mongodb虽然删除数据了。但是不能释放该数据的存储空间。造成碎片。
    然后你懂得。
        33
    lijianying10   2015-07-01 20:09:17 +08:00
    其实我想问LZ说的是不是这个数据库啊:
    http://www.oschina.net/p/mangodb?from=rss
    我看大家(包括我)都在讨论MongoDB
        34
    morethansean   2015-07-01 20:12:09 +08:00
    主页上这么大大的 Mangodb ,处女座实在是不能忍!!!
        35
    bramblex   2015-07-01 20:24:49 +08:00
    千万不要随意入坑,先确保你的业务是否一定需要mongo
        36
    shyrock   2015-07-01 21:47:31 +08:00
    @lijianying10 是笔误哈
        37
    shyrock   2015-07-01 21:47:54 +08:00
    @morethansean Sorry,原帖无法编辑
        38
    aisk   2015-07-01 21:49:30 +08:00
    @shyrock 生而看文档,生而 google 之的人。
        39
    sanddudu   2015-07-01 22:13:53 +08:00
    @lijianying10
    @morethansean
    这个 py 脚本的主要功能就是监听个端口,然后把接受到的数据全部写入 /dev/null(也就是没了)
    嘲讽可以,OSC 居然收录了,这是智商问题吧
        40
    Ricky123   2015-07-01 22:25:09 +08:00
    自己用的时候太占磁盘了
    烧不起
        41
    shyrock   2015-07-01 22:27:33 +08:00
    @aisk 生而google之的人注册技术论坛账号是专门为了吐槽用的吧?已block,不谢。
        42
    anubiskong   2015-07-01 22:32:09 +08:00
    @lijianying10 不是吧, 这点问题都解决不好?
        43
    df4VW   2015-07-01 23:23:45 +08:00
    缺点是,一般从sql来的人,都还是用sql的思维方式在用mongo,然后发现不好用,就在网上疯狂吐槽。

    我也不喜欢mongo,但是我自认为我还没有100%的用对mongo,就不吐槽了。
        44
    zhangsoledad   2015-07-01 23:33:14 +08:00
    据说坑多 已被吓退
        45
    typcn   2015-07-01 23:38:36 +08:00
    再慢,也比 MySQL 快几倍
        46
    9hills   2015-07-02 01:10:42 +08:00 via iPhone
    @shyrock 我的意思是你不懂性能也不懂CAP 。言尽于此
        47
    9hills   2015-07-02 01:15:39 +08:00 via iPhone   ♥ 1
    @aisk 苦口婆心被人block ,也是悲剧。

    把mongo 仅仅是当作没有事务的mysql 来用,是现在mongo 的最大误用。


    Nosql 和sql的思想完全不同。
        48
    nine   2015-07-02 01:43:32 +08:00
    那MongoDB 优点是什么?为什么不用PostgreSQL?
        49
    Septembers   2015-07-02 04:06:40 +08:00 via Android
    @9hills
    NoSQL的重点是围绕文档
    DBMS的重点是围绕关系
    不知是否有理解错误?
        50
    vietor   2015-07-02 06:32:26 +08:00 via Android   ♥ 1
    最大不同,不支持关联查询,性能的确提升,索引难建对
        51
    mengzhuo   2015-07-02 07:49:37 +08:00   ♥ 1
    没法join比较蛋疼,只能用embeddocument,配合ORM+预先载入内存才能感受到爽快
    木有事务,只能自己用程序保证

    对于我司手游这样的应用,用mongodb就很好,结构灵活,反正性能不是啥问题,都是赚了1年钱就跑的(逃
        52
    imlonghao   2015-07-02 07:57:28 +08:00 via Android
    我滚到 Github 上看了看 mangodb,
    感觉就是一个用来搞笑的....

    License
    If you use this, you must donate $1 to someone more intelligent than you.

    楼主我来拿你的$1了.....
        53
    virusdefender   2015-07-02 08:33:49 +08:00
    反正我用的时候就是MySQL之类的存储小数据,有关系的数据

    mongo存储大字段,而且不会再修改的,防止把MySQL撑的太大。
        54
    safilar   2015-07-02 08:46:55 +08:00
    mongoDB 其实学习成本很低,类别 hadoop 等其他大数据库框架来说。它的性能不是很杰出,如果按穿传统意义上的关系数据库来设计的话,也不支持所谓的跨表查询。
        55
    realpg   2015-07-02 08:51:24 +08:00
    不同功能的东西,实现的功能都不同。损失的就是功能。
    RDMBS跟noSQL实现的基本功能都不一致,比较个卵啊。
    举个极端的例子,我以前用MYSQL,现在自己写了个内存存数据的引擎叫rCache替换MYSQL,实现的功能就是一个只有get和set和remove的KV内存存储器,总代码100行,因为我的业务需求就是一个单一存储器,只需要这一个功能,以前的mysql表两列key,value查询也就是三个查询 按主键select,按主键删除,插入记录
    对于这个项目,性能提升1000%以上,我的代价是啥?没有。
        56
    dingyaguang117   2015-07-02 08:52:38 +08:00 via iPhone
    @vietor mongodb转mysql,觉得 应该是mysql索引难建吧

    毕竟还有查询条件复杂多了
        57
    josephok   2015-07-02 09:11:50 +08:00
    能把标题改一下吗?
        58
    Sight4   2015-07-02 09:25:03 +08:00   ♥ 1
    首先,这里面有一点误导的是,CAP不是说,只要有A,就一定没P,而是究竟是A的优先级高一点,还是P的优先级高一点。好了,回到正题

    一般而言,MySQL是传统的RMDBS,是以ACID为第一守则,实现分布式,CA成为首要优先级,这里的表述不是很到位,可以看看下面这篇参考

    http://www.infoq.com/cn/articles/cap-twelve-years-later-how-the-rules-have-changed/

    所以,并不是牺牲什么为代价,只是处理事情的优先级的先后顺序,这个的使用还是需要结合实际生产应用。


    再者,mongoDB跟RMDBS是完全不一样的东西,没事务,没关联,没约束,这些在实际的生产应用中可能会产生很多的问题,所以,mongoDB是那种看起来很爽,用起来就各种问题的存在。如果没有实际将模型拿去验证,又或者把SQL那一套塞进去的话,很多时候会得不偿失。
        59
    shyrock   2015-07-02 09:27:36 +08:00
    @9hills 你第一个回复就纯吐个槽而已,第二句就来个言尽于此,真谢谢你的技术讨论精神了。
        60
    shyrock   2015-07-02 09:31:29 +08:00
    @Sight4 我看到CAP的解释是,在一个实用的分布式系统中,CAP三者只能取其二。这里当然没说完全没有第三个选项,而是说在设计上第三个选项的优先级最低。
    说道NoSQL比起RDBMS少了事务、约束等功能(或者说限制),我觉得首先可以思考一下这些限制是否本身就是CAP模型中的一个维度呢,比如说是否事务本身就是C的一个具体表现。
        61
    feetbig   2015-07-02 10:45:10 +08:00   ♥ 1
    CP的好处是在一个cluster里面即使有几个nodes互相无法通信了,整个cluster仍然是可用的(P)。在通信恢复后仍然可以通过比如互传transaction logs之类的方法保持所有nodes的数据是一致的(C),但是这个同步的过程中用户是无法访问这个cluster的,即牺牲了可用性(A)。

    关系数据库是CA没有P,意思是只要cluster中没有partitons就一直可用(A)并且所有nodes的数据是一致的(C)。但是如果cluster中出现partitions从而导致各个nodes的数据不同步,即使nodes间的通信恢复了,数据库系统本身是无法解决数据不同步的问题的。
        62
    shyrock   2015-07-02 11:46:40 +08:00
    @feetbig 懂了,谢谢。
        63
    Sight4   2015-07-02 11:49:40 +08:00
    @shyrock 事务本身的确是C的一种具现;

    你的问题是mongoDB的缺点是?我的回答是拿模型去试试,理论这东西,有指导意义,但远不及实操的体会深刻。当你要自己去实现关联/限制/约束,还要考虑性能的问题时候,你自然而然会体会到所谓的缺点,缺点也是因场景而异的。当然,不是所有的应用都需要关联/限制/约束,所以mongoDB才有存在的意义。
        64
    shyrock   2015-07-02 11:52:01 +08:00
    @Sight4 我的观点是,理论指导实践。实操和测试都是为了印证理论而做的。否则实验的结果很难有说服力,看看网上各种自相矛盾的测试数据就知道了。
        65
    lilydjwg   2015-07-02 11:54:45 +08:00
    MangoDB 好棒~
        66
    Sight4   2015-07-02 11:57:27 +08:00
    @lijianying10 还真有MangoDB额.....
        67
    lilydjwg   2015-07-02 12:03:17 +08:00
    @shyrock 那如果理论错了呢?出一本 IT 界的《水知道答案》?
        68
    Sight4   2015-07-02 12:16:42 +08:00
    @shyrock 自相矛盾的测试数据不就是 理论->实验->理论 不断重复修正的过程么,而你一旦实验测试,就会涉及到场景模型,单纯撇开模型或者实际场景先讨论一番理论,很多情况只是徒生口水仗而已
        69
    zonghua   2015-07-02 12:49:03 +08:00 via iPhone
    @lijianying10 电子档案咧?很多数据都要细分的。
        70
    shyrock   2015-07-02 13:46:00 +08:00
    @Sight4 我就是这个意思,实验要有理论模型支撑,所以我先问一下CAP模型合适不,如果合适,那么从模型就可以推断CP类的MongoDB必然在A上有损失。如果数据推翻了这个模型,那么就要想一个新的模型。
        71
    lijianying10   2015-07-02 13:46:06 +08:00
    @zonghua 没明白你说的是什么意思、
        72
    shyrock   2015-07-02 13:46:29 +08:00
    @lilydjwg 如果理论错了,就找一个或者想一个新理论
        73
    sampeng   2015-07-02 14:44:48 +08:00
    想知道?
    招聘的时候,不要再问有什么优点了。。问缺点。。。
        74
    lilydjwg   2015-07-02 14:46:41 +08:00
    @shyrock 你没明白我的意思。如果「实操和测试都是为了印证理论而做的」,那么不可能发现理论是错的;你只会看到与理论相符的部分。
        75
    shyrock   2015-07-02 15:23:10 +08:00
    @lilydjwg 不觉得。测试数据可能支持理论假设也可能背道而驰,如果是后者,就需要调整甚至改变理论假设。
        76
    fractal314   2015-07-02 15:31:40 +08:00 via Android
    我觉得这个数据库太消耗内存了,512的vps跑个mongodb,别的就跑不动了
        77
    lilydjwg   2015-07-02 16:01:12 +08:00
    @shyrock 那么你的「实操和测试」的目的是「印证或者否定」理论,而不是「为了印证理论而做」。不想纠结这个了。
        78
    ixiaohei   2015-07-02 22:43:38 +08:00
    缺点没有事务,优点效率很高。完爆mysql,可能是没有事务一堆的约束吧。另外产品开发一直使用,单机并发很高。再就是面向文档,某些应用很爽,另外没有关系数据库的join,一些场景还是很别扭。。另外建议系统不需要事务可以尝试
        79
    movieqiu   2015-07-03 09:10:15 +08:00
    @lijianying10 我看mongodb的描述是采用双链表结构存储,delete以后不释放,但是如果下次有同样大小的会重用。所以我在想,如果每个条目都一样大小的话,应该可以避免碎片问题。
        80
    onelee   2015-07-03 09:53:31 +08:00
    3000W用户的生产环境使用mongodb 2年中(社交类,含交易支付)。。。 有遇到过问题,但是用其他数据也会遇到过问题,(用什么没问题?呵呵) 好好解决就行了,, 可以mysql+mongodb呀 ,或者这2都不用(任性。。。还有其他选择,,O(∩_∩)O~) 根据自身需求来吧。
        81
    Neveroldmilk   2015-07-03 10:23:45 +08:00
    我觉得纠结半天,还不如实际试试。数据量不是太大的情况下,No SQL的缺陷可以通过代码流程来补足。
        82
    ly827   2015-07-03 10:33:28 +08:00
    我觉得先用起来才会知道 我是没用过~~
        83
    lijianying10   2015-07-03 11:15:34 +08:00
    @movieqiu 但是,得具体业务看来,如果是存储数字的话还好说。如果是字符串之类的,那就难受了。
        84
    movieqiu   2015-07-03 12:26:38 +08:00
    @lijianying10 恩这倒是没错。那如果在设计的时候,就将字符串的长度做一些限制,比如固定多少长度。会不会好一些呢?感觉mongodb就是牺牲了不少老式数据库的特性达到的高性能,那么为了用这些高性能,自己就得动手做一些调整。
        85
    movieqiu   2015-07-03 12:29:32 +08:00
    @lijianying10 恩这倒是没错。那如果在设计的时候,就将字符串的长度做一些限制,比如固定多少长度。会不会好一些呢?感觉mongodb就是牺牲了不少老式数据库的特性达到的高性能,那么为了用这些高性能,自己就得动手做一些调整。
        86
    kamushin   2015-07-03 13:44:16 +08:00
    @lilydjwg MYSQL有个引擎BLACKHOLE,效果和MangoDB一样样的~
        87
    lijianying10   2015-07-03 23:01:20 +08:00   ♥ 1
    @movieqiu 我觉得比较好的方案是:
    1. 合理使用删除与更新数据
    1.1 删除只是一个状态,不真正的删除
    1.2 更改数据内容只加入一个新的对象到Collection中顺便还能做版本管理或者类似时间轴这种的常见需求。
    2. 合理的根据建立Collection让数据尽量分散一些
    如果数据量可预测的非常长,可以针对业务分类。让Skip的数据量减少,或者说是让Skip大量数据的概率减少。
    3. 单索引,ID查询为王。

    我也许说的不对,或者还是不够理想,当然我自己也认为我对数据库设计还是不够深刻,同时我也是个开发新手,欢迎批评,也希望能有更多的讨论。

    最后希望能够帮到LZ。
        88
    aspirin2d   2015-08-25 23:20:12 +08:00 via iPhone
    @lijianying10 还有一个就是尽量让每个文档的长度都一致,且尽可能多预留写占位的 field
    关于   ·   FAQ   ·   API   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   2436 人在线   最高记录 5043   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.3 · 30ms · UTC 12:07 · PVG 20:07 · LAX 04:07 · JFK 07:07
    ♥ Do have faith in what you're doing.