在云数据存储中使用整数 ID 作为字符串键是个好主意吗？答案

【问题标题】：Is using integer ids as string keys in cloud datastore a good idea?在云数据存储中使用整数 ID 作为字符串键是个好主意吗？
【发布时间】：2020-05-25 09:17:52
【问题描述】：

我想将 SQL 数据库移动到云数据存储。 sql 数据库使用整数 id，而数据存储使用字符串键名。我知道有一种分配 id 和东西的方法，但是对于字符串键名来说没有必要这样做。所以我可以简单地将整数 id 转换为字符串并将其用作键名：

key('Entity', '342353425')

这种方法有问题吗？我想如果应用引擎要求字符串键名，它仍然可以提供良好的查找性能。

【问题讨论】：

【解决方案1】：

键名的分配是随机且均匀分布的。如果您使用的是自定义 ID，则必须确保它们不是单调递增的值，因为之前指出，它会直接导致 Datastore 延迟。

本文档包含 Datastore 的最佳实践，并具体描述了有关 Keys Best Practices on Datastore 的最佳实践

“如果应用程序产生大量流量，这种顺序编号可能会导致影响数据存储延迟的热点。为避免顺序数字 ID 的问题，请从 allocateIds() 方法获取数字 ID。allocateIds() 方法可以很好地生成 -数字 ID 的分布式序列。”

【讨论】：

【解决方案2】：

默认情况下，数据存储区为每个实体提供一个整数 ID。您可以选择指定一个字符串名称而不是这个整数 ID，或者指定您自己的整数 ID。

如果您指定自己的字符串名称或整数 ID，则可能会损害您的应用扩展到大量实体的能力。

从本质上讲，数据存储的扩展要求名称或 ID 分布在一个范围内，而不是顺序的、集群的以及我可能不知道的其他事情。

如果您的 SQL ID 是连续的，那么您的应用将无法很好地扩展。如果 SQL ID 看起来是随机的，那么应该没问题。

【讨论】：

这是否记录在某处？实体文档首先提到字符串名称，然后就在它自动生成 id 之后，并且没有提到缩放问题：cloud.google.com/datastore/docs/concepts/…
@Tom，我不相信它的文档记录很好，这是我多年来阅读 Stack Overflow 时学到的东西。尝试搜索“热门平板电脑”以获取有用信息。