Mangodb 的缺点是什么？性能？

[shyrock]

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

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

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

[Neveroldmilk]

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

[ly827]

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

[lijianying10]

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

[movieqiu]

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

[movieqiu]

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

[kamushin]

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

[lijianying10]

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

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

最后希望能够帮到LZ。

[aspirin2d]

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