背景

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%的服務可用差別很大，技術人員背不起這個鍋