GAE 用的算是 Hierarchical Database，記得十多年前念大學時聽過，這 些年來還真的是第一次碰到，到現在還在找書交怎麼設計資料結構較好 GAE 這樣設計的好處是，在同一個子樹(Entity Group)下，可以保證每秒 最少可以有五次的寫入，跟上百次的讀取；此外，lock住一個子樹，並不 會影響到另一個樹的存取。 最後你說cron job的問題， GAE datastore在設計上，就不是拿來跑分析 報表用的，所有的統計相關的資料，該在寫入時就更新。 再不然，就是把你 8xx個 Query改成用 Queue處理，拆成 8xx個獨立的事 件，這樣就不會超過 CPU的使用上限了。 GAE 的問題是，為了不知道會不會長大的軟體，從第一天起就要開始為資 料跟程式結構，對流量做最佳化；這些額外的工作，是 startup該負擔的嗎？ ※ 引述《twck (twck)》之銘言： : 為了平衡報導，我也來說一下Google App Engine的缺點。XD : 對我來說，GAE有幾項致命的缺點，之前網友的討論裡似乎沒講到。 : 先說一下GAE用的非關聯性資料庫，以下圖片是盜用Ericsk上官林傑在COSCUP的簡報： : http://farm3.static.flickr.com/2630/4177320925_9af5b354df_o.jpg : 一張圖片就可以清楚明白關聯跟非關聯資料庫的差別。 : 過去用關聯性資料庫久了，我一遇到GAE的非關聯資料庫時，一開始竟然搞不懂！ : 後來發現Google一開始用非關聯資料庫是有道理的，也拉開跟對手的競爭差距。 : 犧牲了資料庫的體積（反正硬碟很便宜嘛），換來存取速度跟擴展規格的方便性。 : 所以對我來說，非關聯資料庫反而是優點，用順手之後非常方便。 : Ericsk上官林傑演講影片在： : https://www.youtube.com/watch?v=tUZKta19TnY : 再來盜用一張： : http://www.flickr.com/photos/kevin814/3587610731/sizes/o/ : CPU Time使用時間超過，除了改善程式碼之外，花點小錢就可以解決，也不是大問題。 : http://farm5.static.flickr.com/4011/4177338277_7b4c7eea49_o.jpg : 以上圖片是我GAE設定付費的畫面，每項都可以自訂預算。 : 沒超過就不用付錢，用多少付多少，很合理。 : （我雖然啟動付費機制，但是還沒付到錢，顯然網站不夠熱門XD） : 可以看到CPU使用時間是以美金1角為單位，花個1.6元美金預算就有很多可以用。 : 那真正致命的缺點是什麼？ : 變數不能超過1MB！ : 一般變數傳遞很少會超過1MB，但是過去當我在果子咖啡萬樓噗聚活動時， : 想用GAE擷取那個在噗浪的萬則留言，再用jQuery計算幾層樓，回應至Blogger網站時， : 前幾小時都正常，但過沒多久就擷取的頁面就超過1MB爆掉了。 : 只好另找其他空間擺我的Python程式碼。 : 這個花錢也無法解除限制。 : 除了CPU Time限制，我發現其實還是有個CPU(API)使用率限制，如下圖： : http://farm3.static.flickr.com/2661/4177360627_ec511f4d6d_o.jpg : 這是我幫BillyPan統計縣市長選舉搜尋筆數，總共54個候選人，16種搜尋條件， : 所以一下子就要去作864次查詢、擷取關鍵字、存入資料庫。 : 雖然我已經拆成11個cron分別去跑，但是可以看到一小時內跑第二輪就會爆掉。 : 在CPU Time還很少時，這個CPU(API)已經紛紛爆掉了。 : 這個也是用錢買不到的。 : 要等一小時過後才會恢復正常。 : 所以GAE的限制也不少啊，不過這跟租用其它虛擬主機同樣會有CPU使用率的問題， : 但是GAE有詳細的數據給你看，讓你有機會調整。 : 很多虛擬主機業者並沒提供這種詳細數據，爆掉就網站停掉，EMAIL要你快交錢。 : 即使如此，Google還是很積極改善GAE，版本更新非常快速。 : 例如之前抓網頁不能設Referer，這樣像無名正妹相簿就沒辦法抓， : 後來新版本就提供Referer了！ : 之前也沒提供主機收信功能，都是突然冒出一個新版本，突然提供新功能。 : 跟Google其它熱門產品很相像。 : 所以我相信GAE的功能或是可以使用的工具會愈來愈齊全， : 讓網站開發者可以專注創意的發想，用最快的方式達成目的。 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 67.185.160.97 ※ 編輯: CPython 來自: 67.185.160.97 (12/12 12:08)