什么是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。如果您确实想出了您喜欢的解决方案，那么您应该考虑写博客，我们很乐意帮助推广您的解决方案！