跳到主要內容

影像紀錄區 紀錄一下這段時間發生的一些事情與未來的方向

五月份幾乎都在建構影像紀錄區功能,雖然主要上傳照片的功能在網站上線之後就沒什麼變更了,但整個網站的效能與使用者操作一直不斷的調整、測試。所以紀錄一下這段時間發生的一些事情與未來的方向,當作五月最後的結尾!

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,再要不然就是直接用 MongoDB 的 _id 就好了。感覺有點多此一舉。只因為產生一段亂數字串看起來有點噁心!

MongoDB Index
目前也產生一些 Index,不過文件是寫說 32MB 以下的資料是感覺不出來的,也就是說目前這資料量我還感覺不太出來,但我還是先產生了。

Celery
Tasks 服務我是用 Celery,不過這裡我真的踩到一個地雷,但還好也平安移除這地雷。由於 Celery 目前沒有辦法多帳號共存,一台機器只能有一個服務,在網路上找到很多人都說沒有辦法解決。之前還想說把 Celery 執行檔切割成兩份,但這方法失敗,會互相覆蓋,也試過 python 跨資料夾存取模組的方式,但也是失敗。不過我試了一天之後想到一個架構,由於一台機器只認一個 Celery,那我就乾脆以這個點出發。

以 Celery 為最頂端(C1),因為我主機裡面有兩個網站,分別為 W1、W2。我就將 W1、W2 的 celery_task 都複製一份到 C1,因為 Celery 的啟動的時候會載入自訂的 Task class,所以我要先讓 Celery 知道有哪些 class,之後我在 W1 或 W2 import 的時候,只要 task class name 一樣,就可以騙過 Celery,但這樣唯一個缺點就是 C1 裡都要與 W1、W2 一樣的 class 與相關的 class。目前就是這樣解決這問題,網路上完全沒有看到相關的建議,那時候真的快瘋掉。因為像是照片 EXIF 解析有點耗時的功能丟給 Celery 排程處理最好的,總不能讓使用者等完上傳後還要等處理吧!

wookmark
我記得我在 twitter 看到有人分享 wookmark 的 jQuery plugin,所以影像紀錄區是套用這樣板當作網站風格的,雖然每個人都說是 Pinterest 風格,但無庸置疑的 wookmark 也是這一類的服務網站。只是當初我單純的覺得這樣的瀏覽方式,對於大量的影像來說還不錯。之後 WM 建議我改用 jQuery Masonry 來呈現,我試用之後也覺得其實這套比較好用,作者也比較有在維護,只是目前還要大規模的更改,所以還沒那麼快換過去,但某些頁面有小部份的套用 Masonry,例如所有使用者頁面。

申請加入
影像紀錄區目前提供填單申請,然後審閱後寄送邀請函加入,會這樣做還是因為目前沒有人可以管理 XD,稍微還是挑一下使用者加入,減少管理的成本。不過還是希望使用者真的有攝影作品產量,因為審閱時會簡單的查詢是否真的有攝影作品,所以如果使用者在網路上找不到作品的話,會比較慢拿到邀請函。感覺好現實喔,真是抱歉,人員不夠,(暫時)一切從簡!

Amazon
截至今天為止,五月在 Amazon 上的花費是 0.55 美金,這費用包含 S3SES 服務與檔案傳輸:
  • S3:$0.16,(114K/10K + 5K/1K requests) * $0.01
  • SES:$0.09($0.01 per 100 mail)
  • AWS Data Transfer:$0.3,15G 的免費傳輸用完了,所以超出部份以 $0.201 per GB 計費(東京)
以目前這樣的費用好像還好,檔案傳輸的費用負擔比較重,但暫時也用不到 CloudFront,不過這個月也一直在看其他相關網站怎樣用 Amazon 的服務,像是最近被 Facebook 買下來的 Instagram,就有分享他們是怎樣建構在 Amazon 上。所以弄的我也好想把影像紀錄區的架構調整一下放到 EC2 上面。前幾天活動遇到 Ernest,也請教他很多關於 Amazon 實際應用的例子,收穫良多,超感謝!但接下來如何調整、搬移到 Amazon 我可能要來評估一下未來影像紀錄區的走向…

影像紀錄區未來的方向
其實打從一開始只是想用影像紀錄區把以前的社員找回來,所以還是用 isuphoto.org 這網址建構,一方面它曾經存在過,和攝影社一起成長…不過眼尖的人可能會發現好像網站上 "義守大學"、"攝影社" 的關鍵字都不見了,其實我是有一點耍脾氣啦。有一天開發一個功能出來,結果我本來服務的對象竟然說出這樣的話,我不是很喜歡這樣的玩笑,一氣之下就決定開放給大家吧!讓喜愛攝影的也喜愛這平台的人繼續用影像切戳技能!

還有 3 個人給我按讚 XD


所以突然一個大轉彎是從這裡開始的,當然也讓我想到 "服務還是要經過市場的考驗",那就不如早點開放給大家吧!來自不同地方的意見可能會更好玩、更有挑戰性吧!影像紀錄區當初就是希望以紀錄生活影像的概念,希望大家(社員)能夠動手多拍照,再透過分享的方式看到其他人的拍攝技巧與風格的一個平台誕生。即使到現在這樣的概念還是不變,只是不再只是校園而已,畢竟大家都畢業了!攝影社也該畢業面對社會了!(好沉重…)

所以未來就是繼續找到更多攝影同好進駐,紀錄更多攝影作品,讓攝影同好拍完照片之後會急著想要上傳到影像紀錄區分享!

Firefox x Ubuntu 12(.04) Release Party
5/27 參加 Party 有上去講閃電秀,不過在輪到閃電秀之前,突然看著大家也做那麼多好玩的事情,感覺自己好渺小喔!坐在底下突然感慨了起來,因為今年好像沒幫到 MozTW 什麼忙,看 Irvin 好辛苦。本來想說不要上去講了,但大老遠跑來台中,也印了一盒名片準備要發,這樣縮頭有點鳥!不過站到台上之後又有很多東西想說出來,所以搞到最後後面都用跳的,講不完。

我記得 Bob 說過:「為一個團體無私的奉獻,每個人心中一定都有其目的。」有的是名、有的是利,但不要利用別人就好了(善意),反過來看著自己,至少此刻是微笑著!

最後
現在到 9 月會變得很忙,中間還有 PyConCOSCUP,今年 COSCUP 接行政工作。可能影像紀錄區就不會花太多時間在上面,但還是會利用這兩個研討會宣傳。所有的事情就等 9 月之後再說吧!

留言

  1. 最近剛想要研究 MongoDB 多謝作者分享相關資訊呀!

    回覆刪除
  2. 您好!我也是一位愛好攝影的朋友剛好也對資訊有興趣
    我目前也是在用GAE作開發平台
    又剛好跟您的"影像記錄區"構想很像
    (怎麼那麼多剛好XDD)
    想多跟您聊聊~
    我的mail:ts771164@gmail.com

    回覆刪除
    回覆
    1. 恩,不過我不是用 GAE

      mail: http://www.google.com/recaptcha/mailhide/d?k=01WTl-Jmp1sxwP7iQqplcRVQ==&c=Xcu3yJ_B5I0R4m244NgyADldPKa06kA3Lw_92BRntvY=

      刪除

張貼留言

show