84669 人學習
152542 人學習
20005 人學習
5487 人學習
7821 人學習
359900 人學習
3350 人學習
180660 人學習
48569 人學習
18603 人學習
40936 人學習
1549 人學習
1183 人學習
32909 人學習
目前有一些工具可以很方便的升级线上的数据库的结构,比如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遷移當前數據,然後停服務再遷移增量數據,通常也不會停太長時間服務。
沒有,只能靠自己在程序裡做約定。
這也是這類面向文件的資料庫的最大問題,開發的時候不得不小心翼翼,因為我們只能在客戶端維護了一份資料庫結構,萬一有某個開發者多插入或少插入了些什麼字段,服務端都是可以接受的。
更苦惱的是有時客戶端不是唯一的,因此我們就要在不同的客戶端上維護同一份資料結構,這為資料結構的升級帶來了很大的不方便。以文件為導向的設計本來是要解放對資料結構的依賴,但是卻沒有解決沒有資料結構約定後帶來的隨意性。