非引战，大家用 mongodb 是什么业务用到的，跟关系型数据库比起来为什么要选 mongodb 呢

特别花哨，需求还老变的统计报表，数据提前算好了写进去

就是适合存 json 格式的数据而已吧

mongodb 各人挺喜欢用的，api 友好型

爬虫数据用的比较多，不用担心分库分表什么的，数据库本身就是分布式设计，数据的分片也比较友好，大数据量下的查询、写入性能都还不错

LZ 说得挺对的。mongo 就是把一堆乱七八糟 json 存起来的东西

你要担心各种一致性问题之类的还是不要选 mongo 了

把程序员伺候舒服了，他们就会（选）用……至于适合不适合，那是架构师的事儿（手动狗头

前期用的爽，后面因为要处理关系恨不得火葬场

日志存文件,查起来不方便.

如果一开始就按着规范来做那问题也不大

MangoDB 适合 db schema 一层层包含特别多那种

{
"条件 1": 1,
"日期": 20210903,
"条件 3": 3,
"条件 n": "n",
"data": [{
"gender": 1,
"value": 1
},
{
"gender": 2,
"value": 10
}
]
}
我们是存了这种结构的一堆结果数据（简单举个例子），需要做聚合 or 查询。

如果计划用 MangoDB 了 为什么不选择 ES

mysql 查询速度不够
我们是 mysql 同步到 mongodb 用 mongodb 做查询库

原有屎山就是用 mongoDB 的，冇得选

整个系统都是用的 mongodb, 事务对我们来说不重要，程序写起还是很爽

@MarioLuo mongo 已经支持事务了吧？虽然对你们不重要，但我还是提醒下的，已经支持事务了。
另外，你们的系统是什么类型的系统，为什么选择 mongodb，能分享下吗？

其实大部分国内引用的场景都不存在事务的场景，而数据结构一直在改，挺适合文档型的数据库

用来临时看日志还是挺香的

个人爬虫

不同模型的数据，用不同的数据库。

当需要存储一个层级很多的树状结构的时候，关系型数据库需要给每一层都创建一张表，然后表之间建立联系，查询的时候也要在所有表中进行查询。
用文档型数据库只需要一个集合，查询也只需要一条原子语句查这个集合。

当需要存储一个 N 对 N 关系的结构的时候，实体之间是纯关系模型，此时用文档型数据库就必须为每种实体建立一个集合，然后集合之间互相引用，查询也只能递归查询。
用关系型数据库就方便很多。

另外 ES 不是数据库，ES 是不保证一致性的，本身有刷新周期，在两个刷新周期之间做的任何写操作，都不能读出最新结果，必须等到下一次刷新后，才可以。
设想一个查询表单有二十个查询参数，每次查询都会在这二十个查询参数中随机选取随机数量的参数组合作为查询条件；这种需求用传统业务数据库难以做到高性能查询，受限于索引的机制，理论上要达到稳定的高速读性能要将这二十个参数的全组合都创建为索引，但对于传统业务数据库来说，索引越多就意味着写性能越差。ES 就是专门应付这种场景的，所以为了兼顾一致性和查询性能，很多系统会用业务数据库+ES 将数据冗余两份，业务数据库负责写操作和一致性读操作，ES 负责非一致性读操作，两边做好同步。

MongoDB 从 4.0 就支持事务了，现在很多人对 MongoDB 有偏见是来源于很多年前对与 MongoDB 的了解。

没有任何一种技术能满足所有需求的，所以我们才会需要各种数据库、中间件来配合实现需求。