先从个人角度来吐槽一下吧。因为这两个数据库我都不是深度用户，且学艺不精，也只能看一下表面现象了，发表一下自己的拙见了。

1.公司项目的不断壮大，技术总监决定阶段性的把一些MongoDB里面的数据迁移到Pg里面。
(Leader的眼光是不会错的,至少是很深刻的结合了现有的业务场景)

2.在做数据迁移的时候，发现MongoDB里面没结构的坏处太多了,每一个字段都要各种校验 isset,类型字段校验。

3.mongoDB里面我们记录的_id是我们生成之后写进去的，在某些没兼顾的情况下，造成了一部分_id是数值类型，一部分是字符串类型.
当你通过_id去排序查询的时候，类型不一样会造成漏数据。（迁移部分数据之后，发现数据少了）

4.之前两个月还遇到过MongoDB数据量过大的情况下，查询效率严重下降，爆内存等情况。所以你可能见过，有些分页查询，到一定数量级之后，就不让查询了。
Mongodb里面数据量大的时候不能用limit().skip()的形式进行分页查询。要用上一次的最大id进行下一次的查询，而且不能用排序，mongodb大了之后索引会很大，排序会导致内存不足。
记录一次神坑操作–导出500万的数据


5.用习惯了MySQL之后，发现Pg的查询语句和MySQL很相似，上手也快。然鹅。mongodb的查询方法需要额外去学习。
查询: mysql pg SELECT  mongodb find
删除: mysql pg DELETE  mongodb remove
查询：mongodb: $type $gt $lt $sum $min skip sort aggregate

6.MongoDB由于集合的自由度，你想查询出没有client_id，或者client_id=0的记录是很艰难的。

7.数据量大了是瓶颈，没有事务，只能存一些日志类型的。

8.其实mongodb这么优秀很多人在用，可能只是目前不太符合我目前的场景和需求吧。

9.我们现在操作日志的数据库也选择了PG。

接下来就是网上搜索的一些资料，可能不一定很准确。仅供参考。

PG和MongoDB在读写方面的测试对比：

PG的商业版EnterpriseDB公司在2014.9月发布了一份针对MongoDB v2.6 to Postgres v9.4 beta的对比报告
如果其对比MongoDB 3.0版本可能测试结果会有差别）
简单翻译其测试报告结果如下：

5000万文档型数据查询、加载、插入时：

1 大量数据的加载，PG比MongoDB快2.1倍

2 同样的数据量，MongoDB的占用空间是PG的1.33倍。

3 Insert操作MongoDB比PG慢3倍

4 Select操作MongoDB比PG慢2.5倍。

//虽然有点点水分，但是很多地方PG确实优于MongoDB
https://blog.csdn.net/jincm13/article/details/53353268

POSTGRESQL: THE WORLD'S MOST ADVANCED OPEN SOURCE RELATIONAL DATABASE

截止2018年9月份最新的版本 PostgreSQL 10.5 and 11 Beta 3 Released! 和 MongoDB 4.0。

PG支持的数据类型叫JSON，从PostgreSQL 9.3版本开始，JSON已经成为内置数据类型，不仅仅是一个扩展了。
PG从9.4开始，又推出了新的JSONB的数据类型。 

MongoDB支持的数据类型叫BSON其实BSON就是JSON的一个扩展，
BSON是一种类json的一种二进制形式的存储格式，简称Binary JSON，
它和JSON一样，支持内嵌的文档对象和数组对象，
但是BSON有JSON没有的一些数据类型，如Date和BinData类型。


在实际项目，PostgreSQL在关系型数据库的稳定性和性能方面均优与MySQL。
但PostgreSQL也兼具NoSQL特性，且支持两种json数据类型：json和jsonb，而两者唯一的区别在于效率。

json是对输入的完整拷贝，使用时再去解析，所以它会保留输入的空格，重复键以及顺序等。
而jsonb是解析输入后保存的二进制，它在解析时会删除不必要的空格和重复的键，顺序和输入可能也不相同。
使用时不用再次解析。两者对重复键的处理都是保留最后一个键值对。
效率的差别：json类型存储快，使用慢，jsonb类型存储稍慢，使用较快。

PostgreSQL是历史悠久知名的开源关系型数据库，一直以性能卓越而著称；其中对空间数据库(PostGIS)的完备支持更是让人爱不释手。

MongoDB CTO于2018年2月16日凌晨在MongoDB西雅图大会上宣布，MongoDB将在4.0版本中正式推出多文档ACID事务支持 。

用户的评论和吐槽也很精彩

我一直很佩服使用Mongodb作为主要数据库的人。
一没事务，二没锁，要它何用
大概也就只能作用博客系统这样的地方，只要稍微复杂一点的逻辑，
比如Update两个表，没有事务很有可能会产生前一个Update了，后一个失败了的尴尬局面.
以及并发下，没有锁的资源 “竞态”
最后我选择 pg


MongoDB:好处就是没结构，坏处也是没结构。
mongodb的弱点是没有SQL的支持，数据量大了以后，维护数据的成本太高了。

Olery公司的选择与努力

Olery公司为什么要放弃MongoDB

我们最引以为豪的是迄今为止我们所取得的成就，不过在这些成就的背后总闪现着一样东西,即基础数据库。
从Olery成立之日起，我们就安装了数据库，它用MySQL来存储（用户、合同等等）核心数据，用MongoDB来存储评论及其类似的数据（即哪些在数据丢失的情况下很容易恢复的数据）。
一开始，这样的安装运行的非常好，然而，随着公司的成长，我们开始遇到了各种各样的问题，尤其是MongoDB的问题居多。
其中一些问题是由于应用与数据库的交互方式而引起的，一些则是由数据库本身而产生的。

例如，某个时刻，我们需要从MongoDB中删除一百万个文档，以后再把这些数据重新插入到MongoDB里。
这样的处理方法使得整个数据库几乎要被锁定数个小时，自然服务性能就会降低。而且直到对数据库执行修复（即在MongoDB上执行repairDatabase命令）后才会解锁。
而且完成修复还要花费数个小时，修复所花的小时数要根据数据库的大小来确定。

在另一实例中我们注意到我们的应用程序的性能降低和设法跟踪到的 MongoDB 集群。
然而，经过进一步检查，我们无法找到问题的真正原因。无论我们怎么安装，或使用什么工具敲了什么命令我们都找不到原因。
直到我们更换了集群的初选，性能才恢复正常。

这只是两个例子，我们已经有过许多这样的情况。这个问题的核心是，这不只数据库在运行，而且无论我们何时察看它都没有绝对的迹象表明是什么原因导致的问题。


Olery公司为什么没选择MySQL

本来，MySQL是第一候选，因为我们的一些关键数据已经在使用它存储。
然而，MySQL也有一些问题。例如，当将一个字段定义为int(11)时，你却可以轻松地向该字段插入文本数据，因为MySQL会试图对它进行转换。
值得注意的是，MySQL在这些情况下会发出警告。但是，仅仅是警告而已，它们通常（若非总是）会被忽略。

此外，MySQL的另一个问题是，任何表的修改操作（例如：添加一列）都会导致表被锁，此时将无法进行读或写操作。
这就意味着，使用这种表的任何操作都不得不等待修改完成之后才能进行。
对于包含有大量数据的表，这可能会花费几个小时才能完成，很可能会导致应用程序宕机。
这已经导致一些公司（例如SoundCloud）不得不自己开发工具（例如lhm）来解决该问题。


Olery公司为什么选择了Pg

PostgreSQL可以解决很多MySQL不能解决的问题。例如，PostgreSQL中你不能将文本数据插入一个数字字段。
PostgreSQL 还具有在许多方式中不需要每一个操作都上锁就可以改写表的能力。
例如，添加一列没有默认值却可以设置为null的列并能够快速完成无需锁定整个表。

还有其他各种有趣的功能，如在 PostgreSQL 可以：trigram 为基础的索引和检索，全文检索，支持JSON查询，支持查询/存储键-值对，支持发布/订阅等更多。

最重要的是PostgreSQL在性能，可靠性，正确性和一致性之间能够权衡。


//感觉PG要一统天下的节奏。。。。。

参考文档：
https://blog.csdn.net/jincm13/article/details/53353268

https://www.jianshu.com/p/d838a5905303?utm_source=oschina-app

https://www.oschina.net/translate/goodbye-mongodb-hello-postgresql?lang=chs&p=1

https://www.jianshu.com/p/c684c6441237

活着就该逢山开路，遇水填桥。生活有压力，才有奇迹。