领导不让用mongo了

背景

2018年启动的一个新项目，项目初期，作为探索项目，基于两点考虑，部分数据存储选用了mongo，理由如下

1. 早期项目需要快速迭代，mongo开发速度快
2. mongo在数据量小的情况下，使用方式和mysql一样，性能差异不大。组员学习成本基本为0
3. 这部分数据比较稀疏，适合nosql存储
4. 项目迭代过程中肯定会频繁的变更表结构，选用mysql交由dba审核麻烦，不适合新项目

到5月份的时候，项目发展的很好，升级为重点项目，招兵买马，扩展了很多人，招来了一个大牛，担任技术leader, 过来不让用mongo了。

弃用

弃用原因有以下

1. 在A家公司内部已经经过验证，不适合数据存储，已被内部选用淘汰。
2. 从监控日志中，看到晚上有段时间mongo 一直read timeout。 经过我的排查，这段时间mongo server有大量的写，虽然cpu占比只有60%，但是secondary node read都失败，这段时间有global lock，联系阿里云的工程师后无法找到原因，只知道让升级配置，也就是交钱。
3. mysql在国内各大互联网公司普遍使用，已是成熟方案，各种轮子一大堆。
4. 公司有专人运维mysql，而没有人运维mongo，作为业务团队，不可能有精力去维护。

总结

我在NoSQL概述-从Mongo和Cassandra谈谈NoSQL曾经详细比较过mongo,cassandra和关系型数据库。但是忽略了一个重要因素，运维。这个主要受限于以前的公司经历，以前的公司运维太强了，以致有些将这部分工作当做理所当然了。

最后我们差不多达成了共识了，进行了mongo的迁移

1. 业务团队做技术选型时，尽量选用公司里面没有专人维护的技术选型，包括不限于数据库/缓存/搜索/大数据处理框架
2. mongo只用于非对外提供的服务上，比如内部系统。或者不重要的服务上。

画外音:这次技术选型给我最大的启示就是要因地制宜的选型。比如像存储这种比较底层的，出现0.1%服务不可用,都是很大的故障。这也是为什么越来越多的服务被迁移到云上了，因为对于公司来说，99.9999%的可用和99%的服务可用差别很大，技术人员背不起这个锅