推荐工具
› RoboMongo
推荐书目
› 50 Tips and Tricks for MongoDB Developers
Related Blogs
› Snail in a Turtleneck
这是一个创建于 3439 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近一个项目打算采用mangodb替换mysql。吹了一堆好处后，销售问我，这些好处的代价是什么？他不懂技术，但是坚持一个朴素的理念“有得必有失”。
我翻了一下网络，发现根据CAP原则，mangodb的归类是CP，是牺牲了可用性来保证一致性和分片容忍性，换句话说mangodb的性能比归类为CA的mysql在性能上应该有所降低。
但是很遗憾，网上做两者性能对比的文章观点互相矛盾，且都不具权威性。
所以想问问各位有没有权威的说法啊？
我翻了一下网络，发现根据CAP原则，mangodb的归类是CP，是牺牲了可用性来保证一致性和分片容忍性，换句话说mangodb的性能比归类为CA的mysql在性能上应该有所降低。
但是很遗憾，网上做两者性能对比的文章观点互相矛盾，且都不具权威性。
所以想问问各位有没有权威的说法啊？
 |
1
CIVITAS 2015-07-01 17:40:55 +08:00
Mongodb.
|
 |
2
EPr2hh6LADQWqRVH 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 OP 小结一下，截止6楼提到的都是没有事务和值约束、外键这些，然而这些都跟CAP原则中的A可用性没有关系啊。换句话说，Mangodb比mysql多了分盘容错性的好处，但是却没有因此而付出代价。
|
 |
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 OP @aisk 忘了在问题里面说明，就是在分布式系统中使用的，可没有说是单机系统。
我这不是在使用之前专门求教MangoDB的优缺点吗？您的意思是只有生而知之的人配得上用MangoDB？ |
|
13
shyrock OP @blacktulip 求教CAP中的A可用性是指什么？
|
 |
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 OP @Had 看懂了，不过这应该是bug。其实我想问的是MangoDB在设计上所付出的代价是什么，也就是说理论上无法通过补丁解决的问题。
|
 |
21
seki 2015-07-01 18:40:01 +08:00
实在忍不住吐槽了
一堆人在指出拼写错误楼主还是我行我素 - - |
 |
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 OP 仔细看了wiki，确实说到CAP是适用于分布式计算系统。
那么问题是MongoDB作为分布式NoSQL数据库，在Availability这项上面付出的代价到底是什么？ |
 |
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说话就可以了。 所以不管是是用什么数据库，得看业务啊。 脱离业务讨论技术，不会有什么结论。 |
 |
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
|
 |
34
morethansean 2015-07-01 20:12:09 +08:00
主页上这么大大的 Mangodb ，处女座实在是不能忍！！！
|
 |
35
bramblex 2015-07-01 20:24:49 +08:00
千万不要随意入坑，先确保你的业务是否一定需要mongo
|
|
36
shyrock OP @lijianying10 是笔误哈
|
|
37
shyrock OP @morethansean Sorry，原帖无法编辑
|
 |
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
自己用的时候太占磁盘了
烧不起 |
|
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 快几倍
|
|
47
9hills 2015-07-02 01:15:39 +08:00 via iPhone 1
|
 |
48
nine 2015-07-02 01:43:32 +08:00
那MongoDB 优点是什么？为什么不用PostgreSQL？
|
 |
49
Septembers 2015-07-02 04:06:40 +08:00 via Android
|
 |
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
|
 |
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那一套塞进去的话，很多时候会得不偿失。 |
|
60
shyrock OP @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间的通信恢复了，数据库系统本身是无法解决数据不同步的问题的。 |
|
63
Sight4 2015-07-02 11:49:40 +08:00
@shyrock 事务本身的确是C的一种具现；
你的问题是mongoDB的缺点是？我的回答是拿模型去试试，理论这东西，有指导意义，但远不及实操的体会深刻。当你要自己去实现关联/限制/约束，还要考虑性能的问题时候，你自然而然会体会到所谓的缺点，缺点也是因场景而异的。当然，不是所有的应用都需要关联/限制/约束，所以mongoDB才有存在的意义。 |
|
64
shyrock OP @Sight4 我的观点是，理论指导实践。实操和测试都是为了印证理论而做的。否则实验的结果很难有说服力，看看网上各种自相矛盾的测试数据就知道了。
|
|
65
lilydjwg 2015-07-02 11:54:45 +08:00
MangoDB 好棒～
|
|
66
Sight4 2015-07-02 11:57:27 +08:00
@lijianying10 还真有MangoDB额.....
|
|
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 OP @Sight4 我就是这个意思，实验要有理论模型支撑，所以我先问一下CAP模型合适不，如果合适，那么从模型就可以推断CP类的MongoDB必然在A上有损失。如果数据推翻了这个模型，那么就要想一个新的模型。
|
|
71
lijianying10 2015-07-02 13:46:06 +08:00
@zonghua 没明白你说的是什么意思、
|
 |
73
sampeng 2015-07-02 14:44:48 +08:00
想知道？
招聘的时候，不要再问有什么优点了。。问缺点。。。 |
|
74
lilydjwg 2015-07-02 14:46:41 +08:00
@shyrock 你没明白我的意思。如果「实操和测试都是为了印证理论而做的」，那么不可能发现理论是错的；你只会看到与理论相符的部分。
|
 |
76
fractal314 2015-07-02 15:31:40 +08:00 via Android
我觉得这个数据库太消耗内存了，512的vps跑个mongodb，别的就跑不动了
|
 |
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就是牺牲了不少老式数据库的特性达到的高性能，那么为了用这些高性能，自己就得动手做一些调整。
|
|
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
|
Select Language