五月份幾乎都在建構 影像紀錄區 功能，雖然主要上傳照片的功能在網站上線之後就沒什麼變更了，但整個網站的效能與使用者操作一直不斷的調整、測試。所以紀錄一下這段時間發生的一些事情與未來的方向，當作五月最後的結尾！ MongoDB 這次影像紀錄區用的資料庫是 MongoDB，也是我第一次實際應用在網站上，因為影像紀錄區 2008 年版本 有使用過 MySQL 的經驗，所以這次在檢視 MongoDB 時，有特別注意看是否能把需要的資料庫資料檢索出來。MongoDB 有一張 MySQL 對照表 ，基本上都可以對映過去。而且比較喜歡像 MongoDB 這類 NoSQL Free-schema 的特性，這樣隨意擴充的彈性有時真的對於初期開發還滿快速的。像影像紀錄區的例子，只要關注 postid 與 userid 這唯一（key）的辨識資料，其他就可以隨意的擴充出新的資料內容。 MongoDB Master-Slaves 通常會用到 Master-Slaves 是因為網站上可能需要大量的讀寫，所以才需要建構 Slaves（只能讀） 分擔 Master（寫/讀） 的讀取。不過影像紀錄區目前還沒有這樣的需求，即使一台 Master 就可以應付了，但是 Master-Slaves 除了分擔 Master 以外，還可以當作備份來使用。所以我想說還是要做備份的話，那就實作看看 MongoDB 的 Master-Slaves 。網站上有教學，也有範例在 Master 死掉如何用 Slaves 恢復，所以我就建構了兩個 Slaves 來當作分擔與備份。老實說就回應的速度有提升。 不過剛上線的時候遇到了 Data inconsistency 的問題，不確定是我設計的問題還是如何，像是 MongoDB 沒有 auto increment 的功能，所以必須額外儲存 value，透過 +1、取得、存入的方式手動，這中間一定會發生問題，所以在後端程式在寫的時候我儘量把所有要寫入的資料備齊之後，才呼叫這流程。另外之前也忘記 Slaves 也會有 sync delay 的問題，所以在執行這個流程時指定只向 Master 取值，要不然會出事。但目前我還是覺得用 increment value 是個錯誤，因為就直接用 uuid 來產生 uni key，再要不然就是直接用 Mon...