Python GAE查找表与事务不兼容？

我的Python高复制数据存储应用程序需要一个包含100000到1000000个条目的大型查找表。我需要能够向某个方法提供一个代码，该方法将返回与该代码相关联的值（如果没有关联，则没有）。例如，如果我的表包含可接受的英语单词，那么如果找到单词，我希望函数返回True，否则返回False（或None）

我当前的实现是为每个表条目创建一个无父实体，并使该实体包含任何关联数据。我将该实体的数据存储密钥设置为与查找代码相同。（我将所有实体放在它们自己的名称空间中以防止任何键冲突，但这对于这个问题不是必需的。）然后我只需在代码上调用get_by_key_name（），就可以得到相关的数据

问题是我无法在事务期间访问这些实体，因为我将尝试跨越实体组。回到我的例子，假设我想检查聊天会话中使用的所有单词的拼写。我可以访问聊天中的所有消息，因为我会给它们一个共同的祖先，但我无法访问我的word表，因为那里的条目是无父的。在交易过程中，我必须能够引用该表

请注意，我的查找表是固定的，或者很少更改。同样，这与拼写检查示例相匹配

一种解决方案可能是在一个事务期间加载聊天会话中的所有单词，然后对它们进行拼写检查（保存结果），然后启动第二个事务，根据保存的结果进行拼写检查。但这不仅效率低下，而且可能会在事务之间添加聊天会话。这似乎是一个笨拙的解决方案

理想情况下，我想告诉GAE，查找表是不可变的，因此我应该能够对它进行查询，而不会抱怨它在事务中跨越了实体组。然而，我看不出有什么办法可以做到这一点

将表项存储在memcache中很诱人，但这也有问题。这是一个很大的数据量，但更麻烦的是，如果GAE启动memcache条目，我将无法在事务期间重新加载它

有人知道适合大型全局查找表的实现吗

---

请理解，我不是在寻找拼写检查web服务或类似的东西。我使用word lookup作为示例只是为了澄清这个问题，我希望为任何类型的大型查找表找到一个通用的解决方案。

首先，如果您认为名称空间将有助于避免键冲突，那么是时候退一步了。键由实体种类、名称空间、名称或id以及实体可能具有的任何父级组成。两种不同的实体类型具有相同的名称或id是完全有效的。因此，如果您有一个匹配的

LookupThingy

，并且通过指定一个唯一的名称创建了每个成员，则该键不会与其他任何内容发生冲突

至于在事务中对未加密的查找表执行相当于拼写检查的挑战，是否可以将查找表保留在代码中

---

或者你能想出一个更接近你需要的类比吗？一种促使在事务中进行查找的方法？

如果可以，请尝试将数据放入实例内存中。如果它不适合实例内存，您可以使用一些选项

您可以将数据存储在与应用程序一起上载的资源文件中（如果它只是偶尔更改），然后从磁盘访问它。这假设您可以构建一个允许轻松查找磁盘的数据结构—实际上，您正在实现自己的基于磁盘的只读表

同样，如果它太大，无法作为静态资源使用，您可以采用与上面相同的方法，但将数据存储在blobstore中

如果数据绝对必须在数据存储中，则可能需要模拟自己的读-修改-写事务。将“修订”属性添加到记录中。要修改它，请获取记录（在事务外部），执行所需的更改，然后在事务内部再次获取记录以检查修订值。如果没有更改，则在您自己的记录上增加修订并将其存储到数据存储中

请注意，底层RPC层理论上确实支持多个独立事务（和非事务操作），但API目前没有公开任何从事务中访问该事务的方法，不幸的是，除了可怕的（我指的是非常可怕的）黑客攻击之外

---

最后一个选项：您可以运行配置了更多内存的后端，公开“SpellCheckService”，并从前端对其进行URLFetch调用。请记住，内存中的速度总是比任何基于磁盘的选项快得多。

是的，您必须正确地认识到，单独的命名空间没有添加任何保护。我原以为这样可以避免键冲突，但即使在默认名称空间中，这种类型也应该充分做到这一点。另一个例子：假设您希望将数据与每个邮政编码关联；例如，您可能有平均收入数字或其他人口统计数据。您如何从事务中查阅此表？这似乎是一个极其普遍的问题。一百万条硬连线到Python代码中？我想那会管用的，但似乎很笨拙。这是唯一的解决方案吗？为什么必须使用事务进行查找表的匹配？您是否试图隔离对查找表的不频繁更改？此处没有足够的空间来充分解释事务的需要，但这与查找表无关。这是出于通常的原因：我正在对一个实体组进行更改，并且必须以原子方式处理数据。我尝试表示所有的表数据