[心得] google app engine的缺點及限制

[心得] google app engine的缺點及限制

最近GAE(Google App Engine)可說是十分火紅，我玩了也算有一小段時間了，基本的介紹我就略過不說了，App Engine的官方網站上已經把優點介紹的非常清楚，各大程設論壇也一片讚揚GAE的未來性和潛力，但是現實上GAE並不是真的那麼無所不能，它還是有其先天性的限制和使用上的條件，使得某些應用難以在上面開發，這部份網路上的文章就很少談及。

接下來我是要把這一小段時間所碰到的困難和所發現的限制做一下整理，讓新近的開發者可以審視一下並評估是否自己的應用程式適合放在GAE上，並不是所有的網路應用都適合使用GAE這樣的平台，若沒有好好慎選，可能會花了大量的開發時間反而得到比本來更低落的效率 (畢竟PYTHON也不好寫)。

#以下的所提及的內容皆是以GAE在2008年8月我所觀察到的情況為準，或許日後GOOGLE會推出新版本來改善這些缺點

一.儲存空間

1. 依據規定”程式內容”(程式碼和靜態圖片等等)，單一檔案大小限制為1MB，檔案數目為1000個(因此總量為1G)，而且這些內容只能透過SDK的上傳工具(update)去上傳，網站執行時期不能透過網站介面去新增或刪除這些靜態檔案
(這裡有個有趣的事情，GAE會對你update過的程式做紀錄，大概是比對checksum之類的做法，這樣如果下次update時，沒修改過的文件就不會被再上傳一次，更神奇的是，如果你刪除了某個文件並update後，GAE不會真的把那個文件從伺服器上砍掉!而只是把他註記起來不能存取而已!要怎麼證明這一點呢? 因為你如果又把剛剛砍掉的那文件再放回來update一次，GAE還是不會要你上傳，大概是直接把伺服器那端又註記成可以存取而已，非常聰明的機制，當網站檔案數量很多的時候節省了很多update的時間)

2. 網站”資料庫”容量為500MB，單一紀錄大小限制為1MB

#根據以上兩點，大家可以發現其實容量問題還可以忍受，大部份網站內容都不會超過1G，資料庫也很少大過500MB，但是這個乍看之下大方的條件卻都有不得單檔超過1MB的限制，這意味的這網站不可能有mp3當背景音樂，不能讓使用者上傳大過1MB的圖檔，更不可能有flv之類的影音內容，甚至連入口頁面的flash介紹都會放不下去，一些flash小遊戲之類的也就不用說了，通通不行，這對網站的開法有很大的限制，希望google能盡早解除這方面的設限

二. 頻寬和流量

1. 網站的頻寬取決於google對使用者的頻寬，在某方面來說這對不同使用者會有很大的落差，以我在學校來說，不知道為啥最高下載就只有45k/s，但是我朋友在家用hinet，有的甚至能達到1.4MB/s的速度，因此，如果你的應用程式需要穩定的頻寬，在建置之前需先評估主要使用者對GOOGLE的網路流量為何，我測量的方法其實很簡單，找一部約700~800MB大小的電影，用rar切成1MB的小檔上傳後，用flashget之類的續傳軟體批次下載，就可以看出速度的變化，下面的流量測試也是用相同的方法做的

2. GAE的規範上寫每天進出皆有10G的流量，可是在管理者控制畫面怎麼只寫進出各2G呢?這就是沒說清楚的地方，事實上兩者都對，首先如果你超過了流量，使用者連到網頁時會看到下面的訊息


但是我們進管理者控制畫面時會看到其實不是完全中斷，還是有再傳的，由上圖可知速率大概在600k/s附近，換言之每秒會多出大概600k的流量額度，我們把600k/s*60秒*60分鐘=2160000k=2.16g，所以我們就可以知道其實控制畫面上的2g意思是”最近一小時內的流量不得超過2G”，而每小時有2G，一整天下來流量超過10G也就是很合理的了(根據我的實測，一整天10G的限制似乎不存在，流量滿了對外速度就一直卡在600k附近而已)，所以結論就是如果你的網站平均每秒超過600k，那流量就一定會每天爆表，反之如果平均流量小於600k，即使瞬間有大量下載，額度也不太會被用完

3. GAE目前不支援串流傳輸，所有的request都必須在限制時間內執行完畢，不然就會回傳錯誤碼

4. 反應時間: 這是一個很多人沒想到的一個問題，可是它確實會對某些應用帶來影響，我試過開發一個網站的視訊系統，由於不支援串流傳輸所以我想說使用單張圖片的方式來解決，每load完一張圖片就再跟網站要一張新的圖片更新，但是實測之後發現效率比在我本來的機器上慢很多，本來在我機器上每秒可以跑到10fps以上，但是換上GAE之後每秒平均不到一張，我試過如memchahe之類的法法來改扇效率但是經過分析之後顯示效率並不是卡在執行時間，從debug模式可看出即使是從datastore，處理的時間不到50ms，但是往返的時間會將拖近到2s甚至3s~4s(單一圖檔大小為30kb)，原因是因為一個request發出到GAE之後，GAE要先判斷request是哪個APP的，然後在從相對應的伺服器之中挑選要回應的伺服器，這一來一往之間會耗掉固定的時間，因此反應的速度會有所延遲約500ms到1s，如果你的應用程式也有類似嚴格回應時間的需求，必須鄭重考慮到這點，因為這是難以避免的(GAE的平均回應時間會略遲於普通WEB SERVER的回應時間)

三.資料庫:

1. 單次查詢筆數的限制最多返回1000筆資料:這在某些應用上可能會有麻煩

2. 沒有內建COUNT的計數: 以往資料庫中常用的”SELECT COUNT(*) FROM mytable”並不能使用在GAE上，雖然有db.count()可以得知此次查詢的筆數可是跟fetch()一樣最大筆數只有1000，如果符合條件的值超過1000也只會回傳1000，google有提出另外一個解決方法是新增一筆COUNT的欄位在資料有異動時就去更改相關COUNT的值，可是在某些需要條件的計數情況下這仍然不能解決問題，例如”SELECT COUNT(*) FROM mytable WHERE score <=100”，這算是很嚴重的缺憾，不知道google之後會不會支援這樣的功能

3. 一次查詢只能有一個不等式條件: 例如”SELECT * FROM mytable WHERE score<100”，"SELECT * FROM mytable WHERE score <> 60” 這兩句是可以的，第二句雖然有兩個不等式，但是因為都是針對score這個欄位所以是可以的，但是”SELECT * FROM mytable WHERE score <> 16”就不行，這也大大的限制了操作資料庫的彈性和靈活度

4. 如果有需要desc排序就要建index，但是不同條件index還不能混用，例如”SELECT * FROM mytable where tag=’test’ ORDER BY date DESC”需要index:
- name: tag
- name: date
direction: desc
理論上更簡單的查詢”SELECT * FROM mytable ORDER BY date DESC”應該能使用上面建好的index，可是事實上仍然要建立一個獨立的index才能運作
- name: date
direction: desc
這非常麻煩，也對開發工作造成困擾，同時越多的index在新增或更動資料時也會越緩慢

5. 過短的資料庫連線時間和缺乏資料庫匯出備份的機制: 跟回應request一樣存取資料庫也是有timeout限制的，只是這限制時間似乎太短了動不動就出現資料庫存取逾時(不到一秒)，例如當資料庫中也很多資料時，刪除資料的方法就是先select出來再delete，但是我的經驗是雖然他一次能讓你select 1000筆資料，但是執行1000筆的刪除卻鐵定會逾時，所以我一次只能刪個100筆資料，重覆好幾次才能把資料刪光，不過這跟所建的index多寡和資料大小或許有關係(不過我覺得1000筆真的太少了就是 應該多開放一點 timeout也該放寬一點) ，最後就是現在官方似乎沒有提供資料庫備份的機制，要資料備份只能自己1000筆1000筆的撈出來，還要自己寫界面存放，這應該也是要改進的缺點

寫了那麼多GAE的缺點和限制主要的用意不是批評GAE不好，事實上我覺得這是相當有潛力的平台而且也是未來的趨勢，只是在現階段它有這樣的限制所以在開發前應該要審慎的評估一下是否符合自己應用程式的特性，以免花了大把的時間開發出不合預期的東西(當然如果只是玩玩就沒差囉)

以上所提及的內容或許有些是我自己的誤解或是其實有其他方法可以避免，如有謬誤歡迎大家一起討論指正