簡體   English   中英

Google App Engine高效的數據存儲區讀/寫操作以節省配額

[英]Google App Engine Efficient Data store Read/Write Operation to Save Quota

我使用Python創建了一個Google App Engine應用。該應用處理許多用戶名。

它有一個數據庫以50K用戶名。 每個用戶名都有一個唯一的哈希值。 哪些也存儲在數據存儲中。

任何應用程序用戶提交任何用戶名。 應用程序首先檢查用戶名是否存在於數據庫中。

如果應用程序使用新的用戶名,則該應用程序將為新名稱計算新的哈希,並將名稱和哈希存儲在DataStore中。

如果數據存儲中已經存在用戶名,它將從數據存儲中檢索舊哈希。

樣例代碼:

class Names(db.Model):
    name = db.StringProperty(required=True)
    hash = db.StringProperty(required=True)

username = "debasish"
user_db = db.GqlQuery("SELECT * FROM Names WHERE name=:1", username)
user = user_db.get()
if user == None:
    #doesn't exist in DB..so calculate new hash for that name and store it in DB
    e = Names(name=username,hash="badasdbashdbhasbdasbdbjasbdjbasjdbasbdbasjdbjasbd")
    e.put()
else:
    #retrieve the old hash.
    self.response.out.write('{"name":"'+user.name+'","hash":"'+user.hash+'"}')            

我面臨的問題是GAE的免費數據存儲讀取操作配額,該配額過快並且我的應用程序停止運行。

我也曾嘗試實現memcache,像這樣,在memcache中添加整個數據庫。 但這也是一個失敗,結果更加糟糕。

def get_fresh_all(self):
    all_names = db.GqlQuery("SELECT * FROM Names")
    memcache.add('full_db', all_names, 3600)
    return all_names

所以,你們能不能建議我,我做錯什么了嗎? 如何使數據存儲讀取操作更有效?

感謝高級。

您可以:

  • 切換到自動緩存的NDB
  • 查詢鍵而不是實體SELECT __key__ FROM ...
  • 減少相關索引(確保減少寫操作,甚至可能減少讀操作)
  • 使用用戶名作為key_name重寫所有實體,並使用方法get_or_insert()
user = Names.get_or_insert("debasish", hash="badasdbashdbhasbd")

您應該僅緩存用戶名=哈希,而不是全部。 再加上一個內存緩存(這僅適用於每個實例緩存。應該有更多幫助,只需在全局模塊級別上創建一個字典即可)。 根據您的獨特點擊數,它可能會迅速增長,但是您可以添加邏輯以僅保留某些數字。 這是一個示例:

cache = {}

def get_user_hash(username):
    if username in cache:
         return cache[username]
    hash = memcache.get(username)
    if not hash:
        hash = # retrieve from db
        if not hash:
            # put to db & assign hash=new_hash

        cache[username] = hash
        memcache.set(username, hash)
    return hash

@Faisal的方法應該可以正常工作,它為查詢添加了兩個緩存級別。

另一種選擇是將用戶名和哈希存儲在會話中。 每個會話僅檢查一次數據庫,然后從會話變量中檢索值。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM