2012年5月30日 星期三

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

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

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 月之後再說吧!

2012年5月21日 星期一

MongoDB Master/Slave with pymongo

前幾天把影像紀錄區的 MongoDB 加入 Master/Slave 機制,目前是 Master + 2 x Slaves,但我非常的白痴,以為這樣設定建立好之後就沒事了,也以為網站效能會提升之類的,當我在看系統資源監控的時候發現兩個 Slaves 的使用率好低好低,低到好像沒有在運作一般。

沒錯,在 MongoDB 設定完之後,Python 驅動 MongoDB 的 pymongo 要使用 MasterSlaveConnection 指定誰是 Master、Slaves,這樣才真的可以讓這機制產生效用。

就這麼簡單設定完成!影像紀錄區有明顯的感覺到資料讀取速度有比較快了!MongoDB 的文件提到如果發生意外,怎樣對調 Master 與 Slave,只是看著看著笑出來了,因為寫的好詳細 XD

至於 MongoDB 另外一個與資料庫分佈有關的 sharding,我想目前應該是實作不到,一方面影像紀錄區的資料量沒這麼多,另一方面是我也沒多的機器來操作,不過我倒是有想到 grs 要不要來建一個各股歷史資料庫,把證交所的資料倒進來,好像也可以齁!

2012年5月7日 星期一

義守大學攝影社影像紀錄區 重新開張

大約在4月底的時候與學長聊天,聊到以前攝影社的影像紀錄區,可以讓社員上傳作品的平台,那時候我們就是以這項強大的網站服務來吸收社員,所以只要入社就有帳號可以使用。 距離事件發生也過了3年了,2009 年莫拉克颱風的關係,把原本架在財金系的攝影社網站給摧毀掉了,之後也找不到合適的主機架站,就這樣一直延盪到最近。

前陣子作完 grs 的網站後,發現一些東西在做網站的時候可以迅速建立,所以就乾脆以現在比較拿手的 Python 來重寫一個影像紀錄區。大約花了一個禮拜的時間,網站就上線了!基本的架構用到:Python + Flask + uWSGI + nginx + MongoDB,另外社員上傳後的圖片是丟到 amazon S3 服務,現在大家都愛談雲端,那就來實作這部份,圖片都丟到雲上面去!

另外就是 MongoDB 的部份,之前 grs 都沒有使用到資料庫,而我又不是很想用 MySQL,所以就決定來實作 NoSQL 資料庫的應用,於是就選擇 MongoDB 當作底層的資料庫系統。雖然剛開始用的時候還是會有之前用 MySQL 影響在,但後來使用 MongoDB 就會發現 NoSQL 資料庫的優點,很適合這小小的網站來使用。

這幾天也加入 Facebook、twitter 的連結,當社員發佈作品的時候,也會同步到這兩個社群服務,希望這樣可以增加曝光率,讓更多人來看我們分享的作品。現在網站是上線了,但有些功能還沒有寫完,只能慢慢調整、慢慢補,反正功能寫的差不多就上線,看大家使用的怎樣在調整修改,這樣比較好,要不然會有盲點。

不過我在思考一件事情,之後要開放給大家使用嗎?或許可以變成一個攝影同好交流的平台也不錯!