我正在構建一個使用gae的企業管理系統的應用程序。我已經使用gae和數據存儲構建了多個應用程序，但從未需要大量用戶輸入事務以及管理和管理報告。我最擔心的是，當我需要創建交叉表和其他詳細報告（或商業智能報告和數據處理）時，我將面臨gae的數據存儲區查詢和數據拉取限制問題。這真的只是建築偏好還是有定量的關注？GAE DataStore vs Google Cloud SQL企業管理系統
在過去，我已經構建了針對Oracle/MySql/MSSql使用C++/c＃/ Java的系統（爲了在複雜或頻繁訪問的數據庫結果上增加一些性能，緩衝層被分散）。
我一直在閱讀我們要拋棄關係數據的舊思維，轉移到天空中大型McHashTable的新世界......但新的並不總是更好......對上述任何見解或經驗會有幫助。
我應該使用谷歌雲SQL或App Engine數據存儲？
這取決於應用程序的要求。 Datastore提供高度可擴展的NoSQL鍵值>存儲，但不支持SQL數據庫提供的複雜查詢。 Cloud SQL支持複雜查詢和ACID事務，但這意味着數據庫充當「固定管道」，性能的可伸縮性較差。許多應用程序使用兩種類型的存儲。
如果您需要大量寫入（〜XXX每秒/秒）到db實體/分佈式密鑰，這就是Google App Engine數據存儲真正發光的地方。
如果您需要支持複雜和隨機的用戶製作查詢，那麼Google Cloud SQL更方便。
在這種情況下，聽起來像是兩者的組合。也許我可以分成兩個階段。我可以使用數據存儲作爲OLTP的應用程序接口，然後通過異步隊列或cron作業將該數據遷移到適用於OLAP的雲sql。有數據重複，但我可以使用遷移活動作爲在寫入更規範化的狀態之前轉換代碼本身中的數據並從數據存儲區清除「過時」數據的機會......我剛創建的工作我自己... – MindWire
我其實剛剛遇到這個，這給我早些時候的評論一些重量。 http://stackoverflow.com/a/1711757/525541 – MindWire
如果您擁有大量數據，則還可以考慮使用Big Query https://developers.google.com/bigquery/，更適合在大型一組導入的數據。 – proppy
在GAE數據存儲中更令我害怕的是索引號限制。例如，如果您需要通過某個字段進行搜索或排序 - 您需要+1索引。完全可以有200個索引。如果您的實體擁有10個可搜索字段，並且您可以按任何字段進行排序 - 則會有大約100個調和。所以你需要100個索引。我已經爲gae開發了幾個小型項目 - 這是成功案例。但是當大家來時 - 這不適合gae。
關於緩存 - 你可以用gae來做，但是他們分配緩存的速度非常慢。我更喜歡使用在內存中保存緩存值的RESTfull API創建永久後端的私有單一實例。前端實例調用此API來獲取/設置值。
也許可以用gae構建複雜的系統，但這將是一組小應用程序/服務。
正如本文所述https://developers.google.com/appengine/articles/indexselection，新的高級查詢計劃程序可以通過在單個屬性索引中使用鋸齒形合併連接而不是昂貴的方式大大減少複雜查詢的索引數量綜合指標的組合。 – proppy
是的，請閱讀。在限制方面有很大差異。 – MindWire
是的，我已經閱讀過，但仍然按照提供的公式來提供，如果您有10個字段中的1個搜索，並按照10個字段中的1個進行排序，您會得到100個相同的索引。所以，如果你的項目中沒有這樣的實體 - 是的，gae可以成爲你的項目。但有些項目包含大量這樣的實體。所以我仍然處於我的位置 - 與數據存儲的gae對於小型項目很有幫助。如果您通過小型項目進行分發，您可以使用gae構建巨大的內容。 – alexey28
關係模型已被證明是非常有用的，但現有產品無法在互聯網上提供它，這就是爲什麼我們有許多不同的解決方案和自己的問題。 NuoDB是一個有趣且有前途的「NewDB」數據庫的例子。在我們等待的時候，人們傾向於將特定用例的解決方案組合起來，將數據複製到單獨的數據庫中進行查詢和報告，在rdbms前使用gigaspaces等等。 – tesdal