一些应该使用mongodb或者其他文档存储而不是redis或mysql、oracle json的情形(最近更新场景)

通常来说，我们应该使用应用的特性而不是自己的爱好或者规定而去选择一种合适的组件，选择的标准应该是这个组件最适合或者本身其设计就是为了解决这个问题，而不是这个组件能够做这事情为标准。就拿存储来说，任何时候，我们都有至少文本文件、SQL数据库、文档数据库或者k/v方式来实现。在我们的一个监控MQ积压的系统中，我们有数十个线上MQ实例跑着几十个金融交易系统的行情和其他关键推送服务，为了在客户尚未感知的情况下我们可以知道每个系统的整体运行情况，为此笔者做了一个最简单的web应用，有增删改服务器、MQ队列积压的监控，因为不想使用mysql导致维护一堆表结构，还得定期升级给运维使用，于是选择了使用redis(append每秒1次)作为存储（本来考虑过使用mongodb，但因为redis相对于mongodb，太小巧），几个月以来，系统运行的很好，一有问题屏幕就会有红色提醒。突然有一天，我们要改个需求，于是笔者让新员工去改，因为一直都是用的本地redis，所以线上的也没有配置密码在运行，因为这个新员工毫无经验，于是我让他去找运维，配置下密码，比较背的是，运维也没有什么经验，在redis.conf更改了密码之后，直接kill的redis进程，启动的时候发现本来的append.log文件也被删除了，于是所有的配置都丢了。

就这个事情本身来说，redis本身并没有什么错，但是我们大部分人通常会认为redis只是缓存，重启后也不会假设其中有持久化的数据，所以日常性的维护很有可能根据惯例进行。从这件事可以看出，选择一个组件的时候，最好还是让最合适的组件做合适的事，尽可能避免不必要的不小心，毕竟整个公司/项目/部门不仅仅只有当事人自己，还有各种周边人员会参与，甚至很有可能决策者只是个发起者，所以一定不要做出乎意料的事情。

言归正传，有些时候，虽然数据是结构化的，但是如果我们实在不想拘泥于rdbms的强结构，并且多一个字段、少一个字段并不会造成系统不可用，而仅仅是丢失了一些信息时，从效益比的角度来说，这个时候选择文档存储可能是合理的。当然，如果数据量巨大、对稳定性或者对性能有极端要求，这个时候必须专门考虑。

虽然，当前postgresql、mysql都支持json了，但是毕竟他们不是nosql为主战场，如果只是简单的应用，没有必要非把rdbms扯进来把事情复杂化。

https://www.vividcortex.com/blog/2015/06/02/json-support-postgres-mysql-mongodb-sql-server/

https://mariadb.com/resources/blog/json-with-mariadb-10-2/

https://oracle-base.com/articles/12c/json-support-in-oracle-database-12cr1

mongodb

MongoDB是一个介于关系数据库和非关系数据库之间的产品，是非关系数据库当中功能最丰富，最像关系数据库的。它支持的数据结构非常松散，是类似json的bson格式，因此可以存储比较复杂的数据类型。Mongo最大的特点是它支持的查询语言非常强大，其语法有点类似于面向对象的查询语言，几乎可以实现类似关系数据库单表查询的绝大部分功能，而且还支持对数据建立索引。

它的特点是高性能、易部署、易使用，存储数据非常方便。主要功能特性有：

*面向集合存储，易存储对象类型的数据。

*模式自由。

*支持动态查询。

*支持完全索引，包含内部对象。

*支持查询。

*支持复制和故障恢复。

*使用高效的二进制数据存储，包括大型对象（如视频等）。

*自动处理碎片，以支持云计算层次的扩展性。

*支持RUBY，PYTHON，JAVA，C++，PHP，C#等多种语言。

*文件存储格式为BSON（一种JSON的扩展）。

*可通过网络访问。

mongodb性能测试

https://www.cnblogs.com/wyett/p/7464332.html