什麼是GAE的最佳遷移策略CloudSQL

Question

我不能在我的生活中找到有關如何使用Google App Engine和CloudSQL處理遷移的文檔。我正在使用Go運行時。

很明顯，應用程序的模式會隨着時間的推移而改變和發展，並且需要運行遷移。目前我手動運行遷移。這不可擴展。

有沒有人有解決方案？

我看到一些具體的挑戰：

• 我可以使用VersionID當前app.yaml部署版本的版本。但是，如何檢查此版本是否發生遷移？我將不得不在一個數據庫表中保留一個版本號，並在init()函數中檢查該版本號？

• 但是，當您上傳應用程序的新版本，新的架構GAE會慢慢migrate your traffic這意味着一旦init()在新版本的第一個實例運行，遷移完成後，流量舊版本會在這些數據庫事務中失敗。

• 我可以通過版本控制API來緩解上述問題。但是，這最後會限制遷移策略，如刪除表等

，我很失望，也沒有這方面的documentation據我可以告訴。

Answer 1

我不得不同意Robert的看法，雖然這是一個具有挑戰性的情況，但與CloudSQL幾乎沒有關係。幾乎任何你需要用不同的SQL模式遷移兩個版本的應用程序的情況都會造成這種情況。

你基本上有兩種選擇

• 進行所有變更至少暫時向後兼容。這可能涉及您的應用程序的中間版本，它可以優雅地處理任何版本的模式。

• 像您描述的那樣版本您的應用/ API，將給定版本與給定架構相關聯，並使用不同的數據庫，這可能需要在兩個數據庫之間複製數據，這可能會使用比您想要的更多的存儲空間。

向後兼容的方法通常是最好的，儘管你得到一些難看的代碼來處理不同的模式。但通常可以完成。

您在問如何知道給定版本是否具有給定的遷移，但請記住遷移是數據庫的屬性，版本是應用程序的屬性。所以問題是版本正在與哪個數據庫交談，以及該數據庫的模式是什麼。您對數據庫中遷移的「版本」編號的想法實際上非常合理，許多ORM具有某種功能。

存在這個問題的原因是，爲什麼在首次創建應用程序原型時（允許更多空值，不使用外鍵或僅使用像Datastore這樣的NoSQL方法），您通常更適合使用更靈活的數據建模方法，以及一旦您對數據模型更有信心，就可以實現更多的數據完整性。

最後，我在Google Cloud文檔上工作，如果您對我們沒有更清楚地解決這個問題感到失望，我很抱歉，但希望您瞭解這是一個通用數據庫操作問題而不是特定問題的觀點Google Cloud或App Engine。如果您確實想出了您喜歡的解決方案，那麼您應該考慮寫博客，我們很樂意幫助推廣您的解決方案！