在 GAE 上实施许可证密钥管理系统：Datastore 还是 Cloud SQL？答案

【问题标题】：Implementing a license key management system on GAE: Datastore or Cloud SQL?在 GAE 上实施许可证密钥管理系统：Datastore 还是 Cloud SQL？
【发布时间】：2014-09-29 23:50:46
【问题描述】：

我正在 Google AppEngine 上实施许可证密钥系统。密钥会提前生成并通过电子邮件发送给用户。然后他们登录系统并输入激活产品的密钥。

我可能有数百人同时提交他们的密钥进行验证。我需要交易保持高度一致，这样同一个许可证密钥就不能被多次使用。

选项 1：使用数据存储区

要使用数据存储，我需要它具有强一致性，因此我将使用 EntityGroup 作为许可证密钥。但是，实体组的写入限制为 1 次/秒。 Appengine 请求必须在 60 秒内完成，因此这意味着要么在激活密钥时通知用户离线，要么让他们循环轮询直到他们的密钥被接受。

选项 2：使用 Google Cloud SQL

即使是最小的 Google Cloud SQL 层也可以处理 250 个并发连接。我不希望这些查询需要很长时间。这似乎会快很多，并且可以毫无问题地同时处理成百上千的许可证密钥请求。

Google Cloud SQL 的缺点是每个实例的大小限制为 500GB。如果我用完了空间，我将不得不创建一个新的数据库实例，然后同时查询提交的许可证密钥。我想我还需要很长时间才能用完这 500GB，而且看起来你甚至可以通过联系 Google 来增加大小。

似乎 Option2 是可行的方法 - 但我想知道其他人的想法。您认为 Entity Group 的交易表现可以接受吗？

【问题讨论】：

标签： google-app-engine google-cloud-datastore google-cloud-sql

【解决方案1】：

在您的情况下，选项 2 似乎更可行、整洁和干净，但您必须自己处理数据库连接，如果未正确使用连接池，则会增加负载。

Datastore 也可用于许可证密钥系统，方法是根据密钥的前导或尾随数字定义多个具有虚拟祖先的 EntityGroup，以处理对实体组的 1 次写入/秒。通过这种方式，您还可以轻松确定生成或提供的许可证密钥的 EntityGroup。

例如 4321 G42T 531P 8922 是许可证密钥，因此 4321 可以用作 EntityGroup，所有以 4321 开头的密钥都将成为该 EntityGroup 的一部分。这是一种类似于分片的机制，可以避免同时写入单个实体组的可能性。

如果您需要对许可证密钥以外的某些列执行查询，则可以在没有 EntityGroup 的情况下维护单独的映射表。

【讨论】：

非常聪明的数据存储解决方案！我想知道是否有类似的东西。我想我会先尝试 Cloud SQL 方法，但最好选择使用数据存储而没有每秒 1 次写入的限制。

【解决方案2】：

您可以混合使用它们，Google Cloud SQL 只有密钥和电子邮件，我相信您可以使用 500G 存储地球上所有人的密钥。另一方面，您可以要求 google 增加数据大小限制。

【讨论】：

为地球上的每个人提供足够的存储空间。我觉得500G也够了。

【解决方案3】：

我将使用选项 1 数据存储，它更快且可扩展。

而且我不知道您为什么需要创建 EntityGroup，您可以将“许可证密钥”本身作为 Key，因此每个实体都在它自己的 EntityGroup 中......只有这样才能使事情具有可扩展性。

【讨论】：

我想过这样做，但我想要一个非常简单且特定的密钥格式。