mongodb数据库适合什么？

众所周知 MongoDB 不支持事务，所以需要强事务的企业根本不能考虑 MongoDB。

mongodb的优势就是文档存储:

1.业务变化频繁，需要时不时添加字段，所以mongodb比较适合，关系型数据库中添加字段的复杂度也不错。

2.嵌套文档，业务数据比较复杂，适合嵌套文档存储，那么mongodb就很适合了，这个关系型数据库比较难处理，虽然mysql和pg也有文档存储，但是mysql还不成熟，毕竟pg现在在生产中使用的还是比较少的，个人也不是很了解，这里就不多说了。但这不仅仅是这个优点，下面将详细介绍。

3. upsert支持，查询速度也不慢

4. 高可用的副本集支持

5.查询语法非常丰富，嵌套文档查询功能非常强大，不重度用户可能看不懂

下面说说一个具体的使用事例:

项目中的一条数据大约10kb。如果使用关系型数据库，则需要将这些数据拆分成几百块左右，构建多张表，设计比较复杂。这种数据大约有一百万条，想想拆分后，数十亿的数据量是可怕的。数据拉平后，任何DB都可以赢，但一百万变成十亿多，太可怕了。

如果使用MySQL存储，每次查询都需要使用外键查询多张表，从这些表中拉取数据的性能肯定会下降很多，还不如只查询一张表，只拉取两个订单量级较少的数据。查询也不错，业务允许你把结果缓存起来放到redis中。

但重点来了。它需要增量更新一些数据。这时候需要更新多个表，根本无法做到原子性（注意事务不是原子操作）。当然，也可以使用 cas 等技术进行补偿，以达到最终的一致性。但是使用mongodb存储只需要更新一条数据，对应的嵌套文档中的内容就可以原子更新。不是很方便吗？

推荐学习《
》

具体说一下这个项目的难点，查询不能使用缓存可能会比较意外，但是业务已经决定不能做，增量更新量达到上万QPS。如果不能保证原子性，想想有多可怕！

所以mongodb在这里帮助很大，关系型数据库解决不了这个问题。

可能有人会问，mongodb没有事务，上游数据写入也会有问题。你不能将所有数据存储在一张表中，对吧？

当然不是。我们 mongodb 中的数据是从 MySQL 中清理出来的，并存储在 mongodb 中。 mongodb只服务于单点业务需求，综合数据还在MySQL中。

在这个项目中，我们使用了数百个副本集来保证系统的高可用性。这些副本集的配置只需一个 shell 即可完成。如果MySQL的主从不知道怎么配置（我自己也不知道），估计DBA会很忙。这个项目根本不需要或使用 DBA。

说了这么多mongo的优点，也说说他的缺点:

1. 查询优化器和MySQL没法比

2.不支持reload，只需要冷启动，初始化配置时比较麻烦

3.没有业务，不敢存储一手数据，多用于备份数据存储

mongodb可以做很多事情，看你的大脑，性能还不错，存储了一些相对不重要的数据。 mongodb拥有强大的嵌套文档，每次看官方文档，挖掘有用资料，都能发现更多惊喜。