一些应该使用mongodb或者其他文档存储而不是redis或mysql的情形

通常来说，我们应该使用应用的特性而不是自己的爱好或者规定而去选择一种合适的组件，选择的标准应该是这个组件最适合或者本身其设计就是为了解决这个问题，而不是这个组件能够做这事情为标准。就拿存储来说，任何时候，我们都有至少文本文件、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扯进来把事情复杂化。