2011-08-07 44 views
3

我有一個應用程序只有一個模型與兩個StringProperties。谷歌應用程序引擎:高效的大型刪除(約90000 /天)

實體的初始數量約爲1億(我將使用批量加載器上載這些數據)。

每24小時我必須刪除約70000個實體並添加100000個實體。我現在的問題是:刪除這些實體的最佳方式是什麼?

無論如何避免在刪除它之前獲取實體?我無法找到做這樣的事情的一種方式:

DELETE from xxx WHERE foo1 IN ('bar1', 'bar2', 'bar3', ...) 

我認識到,應用引擎提供IN子句(雖然爲30的最大長度(因爲各個請求的每個GQL查詢1的最大數量) ),但對我來說,仍然看起來很奇怪,因爲我將不得不獲取x實體,然後再次刪除它們(每個實體進行兩次RPC調用)。

注意:如果未找到該實體,則應忽略該實體。

編輯:有關問題

補充信息這些實體只是域。第一個字符串是SLD,第二個字符串是TLD(沒有子域)。該應用程序可用於執行如下http:// [...] /available/stackoverflow.com的請求。該應用程序將返回一個True/False json對象。

爲什麼我有這麼多實體?因爲數據存儲包含所有註冊的域(現在爲.com)。由於TOS和延遲,我無法在每種情況下執行Whois請求。因此,我最初使用整個區域文件填充數據存儲,然後每天添加/刪除已註冊/刪除的域...問題是,這些數量非常大,我必須找出一種方法來降低成本並每天添加/刪除2 *〜100000個域名。

注意:幾乎沒有任何計算正在進行,因爲可用性請求只是簡單地檢查數據存儲中是否存在域!

1:'任何單個GQL查詢最多允許30個數據存儲查詢。' (http://code.google.com/appengine/docs/python/datastore/gqlreference.html

回答

2

如果不這樣做,你就應該使用key_names這一點。

你會希望有一個模型是這樣的:

class UnavailableDomain(db.Model): 
    pass 

然後,你將填充您的數據存儲,如:

UnavailableDomain.get_or_insert(key_name='stackoverflow.com') 
UnavailableDomain.get_or_insert(key_name='google.com') 

然後,你將可用的域名查詢的東西,如:

is_available = UnavailableDomain.get_by_key_name('stackoverflow.com') is None 

然後當你需要刪除一堆域名,因爲它們已經可用了,你可以建立鍵,而不必查詢數據庫中的大名單首先想:

free_domains = ['stackoverflow.com', 'monkey.com'] 
db.delete(db.Key.from_path('UnavailableDomain', name) for name in free_domains) 

我還是建議刪除配料成類似200元RPC,如果你的free_domains名單真的

+0

對於這種情況,這應該具有最佳性能/最低成本? – o1iver

+0

使用Keys直接執行數據存儲操作的成本儘可能便宜,並且將操作批處理放在一起是減少多個操作的CPU負載的最佳方式。您需要一次性使用批量大小進行刪除,以便在不超過每個RPC限制1MB或超過任何超時的情況下刪除儘可能多的密鑰。另外值得注意的是,定價在不久的將來不會以CPU爲基礎。 –

+0

啊。這是新的定價的好消息。是的,我會玩的大小,雖然除了最初的名單,這不是太大(每50000域約1MB)。謝謝! – o1iver

0

你有沒有考慮過appengine-mapreduce庫。它配備了流水線庫,你可以同時利用到:

  • 創建,你將通過cron運行的總任務管道每24小時
  • 的「整體」管道將啓動過濾你的實體映射器並在刪除映射器完成後產生刪除操作
  • 「總體」管道可以調用「導入」管道來開始運行實體創建部分。
  • 管道API可以向您發送一封電子郵件,報告它的狀態
+0

我只是快速瀏覽了管道庫(不知道它是否存在,非常感謝),事實是,我認爲它有點過分了。我從來沒有對這些實體進行任何計算(它們只在那裏需要,以便我可以檢查它是否存在)。 未詳細查看lib:在過濾時是否仍然需要創建數據存儲RPC? 我只是想最大限度地減少CPU時間... – o1iver

+0

也許你需要解釋更多關於你的過程,因爲它聽起來像你應該做的事情與keys/key_names。 –

+0

我已經添加了一些關於我上面的當前用例的更多信息!謝謝您的幫助! – o1iver