排解 MongoDB 掛在 AWS EBS 的硬碟用量上限
2020 年初 iCHEF 用的 MongoDB 硬碟即將達到 AWS EBS 硬碟上限 16TB，到時無法再加容量會非常麻煩。因此在那之前規劃了三路來試解這問題，最後主要由中路：升級 MongoDB 2.6 到 3.6，藉由它的儲存引擎從 MMAPv1 升級到 WiredTiger 的壓縮率，這裡可以做到 15T → 不到 3T，下面是過程中遇到的難題。
- 簡介另外兩路的結果：上路是程式邏輯解，方向是切割掉會過時但仍佔著大量空間的資料，因中路已解而不急，它也分兩階段，最後在年中上了第一階段。下路是從自建 MongoDB 轉移到 AWS DocumentDB 或 MongoDB 官方的 Atlas，最後沒用到，心得也記在下方。
- 當時還有相當頻繁的資料備份（約每３小時備一次），在硬碟用量上的花費相當高，完成升級後發現我們其實沒在刪交易資料，並不需要留著這麼多 snapshot，刪一刪後整個 EBS 花費下降到四分之一。
上路：程式邏輯解
分析了目前 iPad 那邊上傳資料後的用法與後端 cloud 這邊報表的用法後，歸納出用 PostgreSQL 已有的資料一樣能產生一樣的報表，於是階段一便是讓報表使用 PostgreSQL 的資料；以利之後階段二能清掉 iPad 上傳的大量資料過時後還留在 MongoDB 裡。
中路：升級 MongoDB，從 2.6 到 3.0 後一路到 3.6
同事 Johnny 駱勁成在【Upgrade MongoDB 2.6 to 3.6】一文中已寫了許多要點，推薦閱讀。
下路：AWS DocumentDB 或 MongoDB Atlas
這兩個都是把 MongoDB（放到雲上）代管的方案，只是一個是 AWS 自己做的 MongoDB 3.6 大部份 API （漸漸）相容的方案，一個是 MongoDB 公司官方做的完全相容方案。
分別洽詢了 AWS 與 MongoDB 各自的台灣官方團隊，首先發現 DocumentDB 不論官方或業界的實戰經驗都還不多，只好先照著文件實作看看，最後在用 AWS DMS(Data Migration Service 搬移資料時，遇到 DocumentDB（當時）不支援字串裡有 null character 無法繼續。因清洗大量的資料再來轉過去並不容易，而且洗過的資料就跟原來的資料不同了。
事後過了四個月時 AWS DocumentDB 已支援 null character，只是暫時不用這個解了。另外它相比 DynamoDB 的費用與有趣的架構設計，提供如容量自動增加的功能也蠻吸引人的，沒有相容性問題或從頭開始的話也許值得一試。
MongoDB Atlas 看來相當強大而且相容，想像中官方對這樣的操作會更有經驗。那時的估計花費大約會是兩倍，也還需要額外的配置與準備，所以因為中路即將成功，就先留著當最後的方法之一。
有時候我們會做錯選擇，而重點是能從中學到什麼然後，讓再來一次能選對。
參考
- MongoDB Storage Engines
- AWS DocumentDB: Supported MongoDB APIs, Operations, and Data Types
- > 將資料庫移轉至 Amazon Aurora、Amazon Redshift、Amazon DynamoDB 或 Amazon DocumentDB (與 MongoDB 相容) 時，您可以免費使用 DMS 六個月。 — AWS Database Migration Service
- MongoDB Atlas Pricing
