9

我正處於開發體育統計網站(終極飛盤)的初期階段,並希望知道您的意見,如果Google App Engine適合我。使用GAE數據存儲的複雜查詢

我使用Django在Python中編寫它,並且對標準RDBMS已經很舒服多年了,但是這個站點是一個長期項目,而且我期待着非常大量的數據,因此我希望GAE的「無限」縮放數據存儲提供。絕大多數對數據庫的查詢都會返回非常標準的結果,這會使數據存儲看起來像是一個合理的選擇。但是,我希望能夠在將來進行極其複雜的查詢,以提出新的統計指標或簡單地提出有趣的結果。我打算將來會做很多這樣的事情,但在數據已經收集之前不會知道這些查詢是什麼。

例如,你經常看到棒球統計分析師拿出了荒謬的統計數字,例如「這只是過去50年來的第一次,兩個左手投手的姓氏以'Z'開頭已經引發一擊封閉在背靠背的日子裏「。我希望在將來能夠靈活地提出任何疑問。 :)

但是,我的印象是,像bigtable這樣的非關係數據庫要求您事先提供包含冗餘數據的模型,並且所有工作都是在插入而不是抓取中進行的。我已經構建了包含幾乎所有我需要查詢的數據的django模型,但是我不知道什麼是非常規模型,我希望從現在開始有一兩年的時間。因此,我覺得在未來的GAE數據存儲中進行復雜的查詢會非常困難,並且需要我在使用python處理之前從服務器中提取大量信息。

谷歌應用程序引擎數據存儲只是爲我想要做的錯誤?或者我只是想念一些東西。非常感謝!

更新: 感謝您的迴應。我意識到,我還應該提到,很多這些複雜的查詢都是我希望用戶能夠做的查詢,因此使離線數據庫不是真正的選擇。例如,用戶應該能夠看到各種特定球員在特定比賽或賽季期間在場上同時進行比賽的多種統計數據。雖然這些查詢不如標準彙總統計信息那麼頻繁,但它們仍會定期發生。

有一個關係型數據庫以及在GAE數據存儲將是巨大的,但Django不默認還不支持多分貝的和修補的解決方案一起聽起來困難和混亂。 Eric Florenzano對兩個使用django模型的數據庫都有nice solution,但如果我使用GAE數據存儲,則必須改用應用引擎的db模型。想出一個好的解決方案,就像他爲這個複雜的問題所做的那樣,在這一點上超出了我的技能水平。

現在我最喜歡的兩種選擇是使用GAE任務隊列來完成困難的查詢,或者轉到像webfaction這樣的更加標準的webhost,然後在數據增長時我的表格會非規範化,我需要提高性能。

回答

12

您所描述的實質上是OLAP - 在線分析處理。 OLAP是'傳統'RDBMS非常擅長的一件事,部分原因在於SQL的靈活性和強大功能 - 而像App Engine數據存儲這樣的非關係數據庫則不是。聽起來好像比較正常訪問,雖然你的OLAP類型的查詢會比較頻繁,所以我建議以下兩種方法之一:

  • 鏡像所有間隔數據從App Engine數據存儲到關係數據庫,並對關係數據庫執行分析查詢。面向用戶的流量仍由數據存儲提供服務,因此您可以獲得所有優勢,但您可以使用可以執行復雜查詢的離線副本。
  • 使用App Engine的Task Queue支持來執行檢查大型數據集的查詢。您可以用Python或Java編寫查詢,然後使用Task Queue在非常大的數據集中執行它,並在完成後異步獲取結果。顯然有一些基礎設施工作需要做到這一點(儘管如此,請關注my blog這個未來的項目)。
+0

我希望你能回答:)。感謝這兩個偉大的建議。我已更新了我的問題,以解決您的第一個建議中的潛在問題。至於你的第二,我甚至沒有意識到任務隊列存在!這需要一些研究,但我想知道這是否能解決我所有的問題。 – Spike 2009-11-11 06:09:19

+1

幾年後,是的..但這個答案仍然是黃金,但現在你可以使用谷歌雲數據庫而不是脫機數據庫,並有你的蛋糕和吃它! (http://stackoverflow.com/q/10905861/525541) – MindWire 2012-06-06 18:29:37

6

我要說的是,BigTable中類型的存儲是不太適合的統計應用,對於你提到的非常原因。但這是一個你必須做的傳統交易。我很少發現自己使用真正複雜的查詢的靈活性,但很多時候被迫提出更多專門的解決方案來處理那些本來不應該放在db中的東西。

如果您堅持使用RDBMS,可以通過Hibernates持久性策略和Hibernate Shards來實現邏輯分區和非規範化。如果您可以處理稍慢的處理,您也可以在bigtable類型的存儲上執行SQL查詢(請參閱hadoop pig latin)。

+0

感謝您的建議!我可能可以忍受某些事情的較慢處理,並且如果可能的話,真的很想使用bigtable。 – Spike 2009-11-11 06:11:57

2

GAE數據存儲是與RDBMS完全不同的動物。這是很容易在一個關係數據庫寫類似:

SELECT STDEV(player_score) 
FROM Table 
WHERE player_id = 1234 
    AND game_date BETWEEN '2007-01-01' AND '2009-11-10' 
    AND city <> 'London' 

GAE查詢有許多限制 - see here - 因此它是不容易翻譯這個。對於集合函數(sum,stdev等),您必須將所有數據提取到應用程序層,並計算或維護每個數據插入/更新時更新的聚合實體。

更新
您可以考慮使用GAE的UI和業務邏輯,但在像雲有不同的關係數據庫別處:微軟SQL,在亞馬遜,MySQL的DB2其他地方 - 而不是使用GAE的數據存儲爲預先計算的聚合和統計數據。因此統計數據仍然在RDBMS中計算,但是您將結果(部分,預先計算的統計數據)存儲在GAE存儲中;類似於分析立方體中的三維存儲。

+0

我真的很感激你的意見。我相當設置使用Django的UI而不是appengine。混合使用兩種不同的數據庫類型確實聽起來像是一種潛在的好方法,它聽起來非常難以設置... – Spike 2009-11-11 06:14:56