Mangodb 的缺点是什么？性能？

[shyrock]

最近一个项目打算采用mangodb替换mysql。吹了一堆好处后，销售问我，这些好处的代价是什么？他不懂技术，但是坚持一个朴素的理念“有得必有失”。

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

所以想问问各位有没有权威的说法啊？

[feetbig]

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

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

[shyrock]

@feetbig 懂了，谢谢。

[Sight4]

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

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

[shyrock]

@Sight4 我的观点是，理论指导实践。实操和测试都是为了印证理论而做的。否则实验的结果很难有说服力，看看网上各种自相矛盾的测试数据就知道了。

[lilydjwg]

MangoDB 好棒～

[Sight4]

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

[lilydjwg]

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

[Sight4]

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

[zonghua]

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

[shyrock]

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

[lijianying10]

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

[shyrock]

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

[sampeng]

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

[lilydjwg]

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

[shyrock]

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

[fractal314]

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

[lilydjwg]

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

[ixiaohei]

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

[movieqiu]

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

[onelee]

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