数据库选型在应用开发中的 “shine”

今天一上班，就有一个电话，问我关于MYSQL 的 excpetion timeout, 问题，我在了解后，便告知一般如何解决这样的问题，以及这样问题的成因等等，因为几年前就遇到这样的坑，并且当时就有成熟的解决方案。

可以转念一想，我的问问这个项目的，因为是第一次听说，在搞清了项目的由来，我在电话这边发出了一声 “唉”。 因为这个项目使用MYSQL 是在是..........

现在的系统开发人员每天都很忙，而最近闹的ICU也是程序员在诉说自己的工作的压力。而一个成熟的 数据架构师，其实应该是在某种程度，在项目的初期就跟踪项目，为项目和程序员寻找一个省时省力，并且也好运维的数据库系统，让抱怨更少一点，让系统更靠谱一点。

因为在听完程序员诉说了这个项目后，我马上反应了一点，这个用MONGODB 来解决，无论从开发的时间，开发的难度，以及后期的维护等等都要比使用MYSQL 好得多，程序员废了半天劲，其实就在解决另一个数据库天生就支持的问题。

“你怎么不早说，你怎么不早说，你怎么不早说”， 唉。 这个项目其实就是从传统数据库抓取信息，然后存储到数据库中，在批量生成 JSON 格式的信息通过，消息队列发送给另一个 微服务。 因为数据量稍微大了点（其实还好，半年也就不到2000万而已），但这还要牵扯到 ，运维后期定期归档，定期清理，那我们这边一般的操作，就是通过程序来完成这样的工作，尽量减小运维的工作量，避免工作中的失误。

所以我们采用定期分表的方法，而MYSQL 对程序的依赖程度要高于ORALCE SQL SERVER，等数据库，所以MYSQL 的使用就要程序员多费力气。

可如果使用MONGODB 这样的数据库，那就是一个“完美的”解决方案，数据在抓入，直接存储在MONGODB 中（JSON格式），提取的时候，直接通过主键，或者标识值，来整体提取，发送，然后采用MONGODB 特性，可以定期的清理已经过期的数据，让运维，开发，稳定性都 笑哈哈。

下午和开发主管通过电话，其实他们也是“遗憾”，如果早知MONGODB 可以完成这样的事情，就不至于现在还要重新修改，又是一头包。还不知道要遇到多少 BUG，并且还要考虑数据量，分表的操作。

其实从某些角度来看，未来开发中，单独使用一种数据库从头到下，至始至终的情形，会越来越低，通过每个数据库的特性，来解决开发头疼问题，并且也降低运维的投入，这样的“投机取巧”，应该被值得推广。