我正在設計一個簡單的web應用程序，每天向用戶組織每日聖經閱讀。 讀數平均每天約300-400字。AppEngine應用程序的數據存儲或本地文件
因此，例如user1今天註冊，所以day1的讀數會返回給它們。 User2註冊了一週後，但仍然是第1天，因此他們再次獲得day1的讀數，依次類推。
我期待大約100個用戶在發佈時可能會在稍後進行擴展。
現在有，我能想到的這樣做的兩種方法：
1）存儲整本聖經中的數據存儲總量（約30000詩句）和日常（查詢讀數〜50節），而可能是緩存已經查詢日期爲文件。
2）有一個本地腳本存儲讀取文件中的每一天（所以總共365個文件）並呈現文件並將其返回給用戶而不用觸摸數據存儲。
請記住，在那之後會有不同的讀數，所以如果我選擇了2，我必須上傳一組新文件。
我真的不知道我想要什麼，每個選項的效率如何。 任何想法？我錯過了別的嗎？
這取決於你想要你的網站是如何「動態」的。如果您嚴格按照每頁返回一首詩歌，將所有頁面預呈現爲HTML將會非常節省成本。
當您收到用戶的請求時，您可以在訪問頁面時獲取用戶實體，計算適當的詩句以顯示它們，然後將它們重定向到詩歌頁面。作爲一個額外的好處，如果詩歌頁面是靜態的，它們可以緩存在Google的邊緣緩存中，並且您不需要爲頁面提供服務。
但是，如果你想動態地創建你的頁面，這種機制不是那麼有益。
雖然一般來說，由於這些經文不是一個會改變的數據集，所以將它作爲一個文件存儲並索引這些經文會更便宜。
謝謝你提供有見地的答案。對於我來說編寫一個能夠創建所有頁面的腳本非常容易，所以看起來我會使用靜態頁面。 – MinaHany
抽象這一點，用戶有一系列的項目來處理。對於讀者是以自己的速度進行處理還是以讀者開始日期所抵消的恆定速度進行處理，我並不清楚。無論哪種方式，都可以直接處理。
您需要一個代表用戶的實體。爲此，您需要要求用戶登錄。然後，您可以使用他們的電子郵件地址作爲此實體的密鑰。如果用戶以自己的速度讀取數據（但不能快於每天一個數據），那麼您可以記錄最近一次訪問的日期以及它們在該日期提交的項目（閱讀）的索引。當他們在新的日期訪問時，索引提前，並且他們得到一個新的項目（閱讀）。
如果根據用戶的開始日期確定讀數，則實體需要記錄開始日期，以便通過計算當前日期與開始日期之間的差異來確定讀數（相應地調整1 - 基於索引）。
兩種方式都假定您的讀數是按數字索引的，可以是按鍵值，也可以是某個索引字段。
謝謝你的回答，但這不是我的問題。 我不是在說存儲用戶數據我在說存儲讀數數據。我想在web應用中將讀數顯示爲HTML，並詢問什麼是存儲它們的最佳方式。 – MinaHany
這兩種方式中的任何一種都有效，就像在一次文件中上傳多年讀數的混合方法一樣，然後將後臺任務分解爲單個數據存儲實體。我的猜測是，這種方法將平衡方便與快速訪問。 –
問題並不適用於SO。但一些快速點。您無法編寫文件系統，因此緩存將是memcache和數據存儲。如果你沿着文件路徑走，你仍然可能需要保存數據存儲區中每個文件的元數據，以允許你發展系統。您最好保留數據存儲中的所有數據。只是我的2c值得。這類數據和您提取的數據量對於您正在討論的數字類型的appengine而言不會很慢或昂貴。 –