目前有一些工具可以很方便的升級線上的數據庫的結構，比如ruby寫的rails以及php的doctrine都有migration，不知道mongodb有沒有很方便升級庫結構的方法。
拥有18年软件开发和IT教学经验。曾任多家上市公司技术总监、架构师、项目经理、高级软件工程师等职务。 网络人气名人讲师，...
MongoDB升級資料庫還是相對比較方便的，如非特殊版本更新，基本上都不用停服務。
1.如果你的資料結構有變化，MongoDB的Schema－free機制使你可以不用遷移
2.如果你想使用新版本中的新功能，那確實得遷移資料了，一種比較通常的做法是透過其Replication機制。可以看一下官方的相應版本的release notes，通常會寫升級時是否可以用Replication的方式，不能用的話可能是因為本次新版本在Replicastion協議上本來就有改動。那可能就得停服務來做遷移了。
3.停服務遷移前，也可以先透過mongodump和mongorestore遷移當前數據，然後停服務再遷移增量數據，通常也不會停太長時間服務。
沒有，只能靠自己在程序裡做約定。
這也是這類面向文件的資料庫的最大問題，開發的時候不得不小心翼翼，因為我們只能在客戶端維護了一份資料庫結構，萬一有某個開發者多插入或少插入了些什麼字段，服務端都是可以接受的。
更苦惱的是有時客戶端不是唯一的，因此我們就要在不同的客戶端上維護同一份資料結構，這為資料結構的升級帶來了很大的不方便。以文件為導向的設計本來是要解放對資料結構的依賴，但是卻沒有解決沒有資料結構約定後帶來的隨意性。
MongoDB升級資料庫還是相對比較方便的，如非特殊版本更新，基本上都不用停服務。
1.如果你的資料結構有變化，MongoDB的Schema－free機制使你可以不用遷移
2.如果你想使用新版本中的新功能，那確實得遷移資料了，一種比較通常的做法是透過其Replication機制。可以看一下官方的相應版本的release notes，通常會寫升級時是否可以用Replication的方式，不能用的話可能是因為本次新版本在Replicastion協議上本來就有改動。那可能就得停服務來做遷移了。
3.停服務遷移前，也可以先透過mongodump和mongorestore遷移當前數據，然後停服務再遷移增量數據，通常也不會停太長時間服務。
沒有，只能靠自己在程序裡做約定。
這也是這類面向文件的資料庫的最大問題，開發的時候不得不小心翼翼，因為我們只能在客戶端維護了一份資料庫結構，萬一有某個開發者多插入或少插入了些什麼字段，服務端都是可以接受的。
更苦惱的是有時客戶端不是唯一的，因此我們就要在不同的客戶端上維護同一份資料結構，這為資料結構的升級帶來了很大的不方便。以文件為導向的設計本來是要解放對資料結構的依賴，但是卻沒有解決沒有資料結構約定後帶來的隨意性。