Mangodb 的缺点是什么？性能？

Mongodb.

就是没有事务，没有Join

没有事务

没有权威说法，实测方知

你看到的什么文章。MongoDB性能不如MySQL，人用它干嘛，难道没有事务比带事务还要慢?

我的感受：

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

另据说 MongoDB 存 JSON 的性能不如 PostgreSQL 9.4 的 jsonb 数据类型。

小结一下，截止6楼提到的都是没有事务和值约束、外键这些，然而这些都跟CAP原则中的A可用性没有关系啊。换句话说，Mangodb比mysql多了分盘容错性的好处，但是却没有因此而付出代价。

@shyrock
MongoDB
*

CAP 理论是针对分布式系统的，跟你单机使用没有关系。
另外求楼主千万不要用 mongodb，因为 mongodb 现在最大的问题就是属于这种「不知道现在系统有什么问题」「不知道新的系统解决了什么问题」的人误用导致的各种问题。

CAP 不单是针对分布式系统的，而且跟性能没有关系，可用性跟性能是两回事

坑很多... 修坑很慢，尤其Query Plans相关的... 很痛苦有没有...

@aisk 忘了在问题里面说明，就是在分布式系统中使用的，可没有说是单机系统。
我这不是在使用之前专门求教MangoDB的优缺点吗？您的意思是只有生而知之的人配得上用MangoDB？

@blacktulip 求教CAP中的A可用性是指什么？

@Had 被你一说，心里有点怕。。。都这么些年了，应该还是基本可用吧？

好像不支持acid

@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.

Mongodb
Mongodb
Mongodb
Mongodb！！！

@Had 看懂了，不过这应该是bug。其实我想问的是MangoDB在设计上所付出的代价是什么，也就是说理论上无法通过补丁解决的问题。

@yoa1q7y Sorry，前几个人的提醒我以为重点是大小写呢。。。

@9hills 不是所有数据库设计都以性能为第一诉求的。。。

实在忍不住吐槽了
一堆人在指出拼写错误楼主还是我行我素 - -

@seki 喏，你看前一个回复。

CAP讲的是分布式系统
我们讨论数据库时要讨论的是ACID

mongodb无法做到ACID，所以对事务有要求的应用不适合用它。

@shyrock https://zh.wikipedia.org/wiki/可用性

https://github.com/dcramer/mangodb

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

仔细看了wiki，确实说到CAP是适用于分布式计算系统。
那么问题是MongoDB作为分布式NoSQL数据库，在Availability这项上面付出的代价到底是什么？

@zxp 这不算代价。

我觉得，要是做的话，还是结合各家所长来用比较好。

其实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说话就可以了。

所以不管是是用什么数据库，得看业务啊。
脱离业务讨论技术，不会有什么结论。

@shyrock 晕死，人家调侃的是Mangodb，而不是Mongodb

@lijianying10 delete会有个洞是什么意思?

坑多

@anubiskong
http://stackoverflow.com/questions/5518581/mongodb-data-remove-reclaim-diskspace
删除数据会在硬盘文件上。
mongodb虽然删除数据了。但是不能释放该数据的存储空间。造成碎片。
然后你懂得。

其实我想问LZ说的是不是这个数据库啊：
http://www.oschina.net/p/mangodb?from=rss
我看大家（包括我）都在讨论MongoDB

主页上这么大大的 Mangodb ，处女座实在是不能忍！！！

千万不要随意入坑，先确保你的业务是否一定需要mongo

@lijianying10 是笔误哈

@morethansean Sorry，原帖无法编辑

@shyrock 生而看文档，生而 google 之的人。

@lijianying10
@morethansean
这个 py 脚本的主要功能就是监听个端口，然后把接受到的数据全部写入 /dev/null（也就是没了）
嘲讽可以，OSC 居然收录了，这是智商问题吧

自己用的时候太占磁盘了
烧不起

@aisk 生而google之的人注册技术论坛账号是专门为了吐槽用的吧？已block，不谢。

@lijianying10 不是吧, 这点问题都解决不好?

缺点是，一般从sql来的人，都还是用sql的思维方式在用mongo，然后发现不好用，就在网上疯狂吐槽。

我也不喜欢mongo，但是我自认为我还没有100%的用对mongo，就不吐槽了。

据说坑多 已被吓退

再慢，也比 MySQL 快几倍

@shyrock 我的意思是你不懂性能也不懂CAP 。言尽于此

@aisk 苦口婆心被人block ，也是悲剧。

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


Nosql 和sql的思想完全不同。

那MongoDB 优点是什么？为什么不用PostgreSQL？

@9hills
NoSQL的重点是围绕文档
DBMS的重点是围绕关系
不知是否有理解错误？

最大不同，不支持关联查询，性能的确提升，索引难建对

没法join比较蛋疼，只能用embeddocument，配合ORM＋预先载入内存才能感受到爽快
木有事务，只能自己用程序保证

对于我司手游这样的应用，用mongodb就很好，结构灵活，反正性能不是啥问题，都是赚了1年钱就跑的（逃

我滚到 Github 上看了看 mangodb，
感觉就是一个用来搞笑的....

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

楼主我来拿你的$1了.....

反正我用的时候就是MySQL之类的存储小数据，有关系的数据

mongo存储大字段，而且不会再修改的，防止把MySQL撑的太大。

mongoDB 其实学习成本很低，类别 hadoop 等其他大数据库框架来说。它的性能不是很杰出，如果按穿传统意义上的关系数据库来设计的话，也不支持所谓的跨表查询。

不同功能的东西，实现的功能都不同。损失的就是功能。
RDMBS跟noSQL实现的基本功能都不一致，比较个卵啊。
举个极端的例子，我以前用MYSQL，现在自己写了个内存存数据的引擎叫rCache替换MYSQL，实现的功能就是一个只有get和set和remove的KV内存存储器，总代码100行，因为我的业务需求就是一个单一存储器，只需要这一个功能，以前的mysql表两列key,value查询也就是三个查询 按主键select，按主键删除，插入记录
对于这个项目，性能提升1000%以上，我的代价是啥？没有。

@vietor mongodb转mysql，觉得 应该是mysql索引难建吧

毕竟还有查询条件复杂多了

能把标题改一下吗？

首先，这里面有一点误导的是，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那一套塞进去的话，很多时候会得不偿失。

@9hills 你第一个回复就纯吐个槽而已，第二句就来个言尽于此，真谢谢你的技术讨论精神了。

@Sight4 我看到CAP的解释是，在一个实用的分布式系统中，CAP三者只能取其二。这里当然没说完全没有第三个选项，而是说在设计上第三个选项的优先级最低。
说道NoSQL比起RDBMS少了事务、约束等功能（或者说限制），我觉得首先可以思考一下这些限制是否本身就是CAP模型中的一个维度呢，比如说是否事务本身就是C的一个具体表现。

CP的好处是在一个cluster里面即使有几个nodes互相无法通信了，整个cluster仍然是可用的（P）。在通信恢复后仍然可以通过比如互传transaction logs之类的方法保持所有nodes的数据是一致的（C），但是这个同步的过程中用户是无法访问这个cluster的，即牺牲了可用性（A）。

关系数据库是CA没有P，意思是只要cluster中没有partitons就一直可用（A）并且所有nodes的数据是一致的（C)。但是如果cluster中出现partitions从而导致各个nodes的数据不同步，即使nodes间的通信恢复了，数据库系统本身是无法解决数据不同步的问题的。

@feetbig 懂了，谢谢。

@shyrock 事务本身的确是C的一种具现；

你的问题是mongoDB的缺点是？我的回答是拿模型去试试，理论这东西，有指导意义，但远不及实操的体会深刻。当你要自己去实现关联/限制/约束，还要考虑性能的问题时候，你自然而然会体会到所谓的缺点，缺点也是因场景而异的。当然，不是所有的应用都需要关联/限制/约束，所以mongoDB才有存在的意义。

MangoDB 好棒～

@lijianying10 还真有MangoDB额.....

@shyrock 那如果理论错了呢？出一本 IT 界的《水知道答案》？

@shyrock 自相矛盾的测试数据不就是 理论->实验->理论 不断重复修正的过程么，而你一旦实验测试，就会涉及到场景模型，单纯撇开模型或者实际场景先讨论一番理论，很多情况只是徒生口水仗而已

@lijianying10 电子档案咧？很多数据都要细分的。

@Sight4 我就是这个意思，实验要有理论模型支撑，所以我先问一下CAP模型合适不，如果合适，那么从模型就可以推断CP类的MongoDB必然在A上有损失。如果数据推翻了这个模型，那么就要想一个新的模型。

@zonghua 没明白你说的是什么意思、

@lilydjwg 如果理论错了，就找一个或者想一个新理论

想知道？
招聘的时候，不要再问有什么优点了。。问缺点。。。

@shyrock 你没明白我的意思。如果「实操和测试都是为了印证理论而做的」，那么不可能发现理论是错的；你只会看到与理论相符的部分。

@lilydjwg 不觉得。测试数据可能支持理论假设也可能背道而驰，如果是后者，就需要调整甚至改变理论假设。

我觉得这个数据库太消耗内存了，512的vps跑个mongodb，别的就跑不动了

@shyrock 那么你的「实操和测试」的目的是「印证或者否定」理论，而不是「为了印证理论而做」。不想纠结这个了。

缺点没有事务，优点效率很高。完爆mysql，可能是没有事务一堆的约束吧。另外产品开发一直使用，单机并发很高。再就是面向文档，某些应用很爽，另外没有关系数据库的join，一些场景还是很别扭。。另外建议系统不需要事务可以尝试

@lijianying10 我看mongodb的描述是采用双链表结构存储，delete以后不释放，但是如果下次有同样大小的会重用。所以我在想，如果每个条目都一样大小的话，应该可以避免碎片问题。

3000W用户的生产环境使用mongodb 2年中（社交类，含交易支付）。。。 有遇到过问题，但是用其他数据也会遇到过问题，（用什么没问题？呵呵） 好好解决就行了，， 可以mysql+mongodb呀 ，或者这2都不用（任性。。。还有其他选择，，O(∩_∩)O~） 根据自身需求来吧。

我觉得纠结半天，还不如实际试试。数据量不是太大的情况下，No SQL的缺陷可以通过代码流程来补足。

我觉得先用起来才会知道 我是没用过~~

@movieqiu 但是，得具体业务看来，如果是存储数字的话还好说。如果是字符串之类的，那就难受了。

@lijianying10 恩这倒是没错。那如果在设计的时候，就将字符串的长度做一些限制，比如固定多少长度。会不会好一些呢？感觉mongodb就是牺牲了不少老式数据库的特性达到的高性能，那么为了用这些高性能，自己就得动手做一些调整。

@lijianying10 恩这倒是没错。那如果在设计的时候，就将字符串的长度做一些限制，比如固定多少长度。会不会好一些呢？感觉mongodb就是牺牲了不少老式数据库的特性达到的高性能，那么为了用这些高性能，自己就得动手做一些调整。

@lilydjwg MYSQL有个引擎BLACKHOLE，效果和MangoDB一样样的~

@movieqiu 我觉得比较好的方案是：
1. 合理使用删除与更新数据
1.1 删除只是一个状态，不真正的删除
1.2 更改数据内容只加入一个新的对象到Collection中顺便还能做版本管理或者类似时间轴这种的常见需求。
2. 合理的根据建立Collection让数据尽量分散一些
如果数据量可预测的非常长，可以针对业务分类。让Skip的数据量减少，或者说是让Skip大量数据的概率减少。
3. 单索引，ID查询为王。

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

最后希望能够帮到LZ。

@lijianying10 还有一个就是尽量让每个文档的长度都一致，且尽可能多预留写占位的 field