我正在将应用程序从主/从迁移到 HRD。我想听听已经经历过迁移的人的一些评论。
我尝试了一个简单的示例来发布一个没有祖先的新实体并重定向到一个页面以列出该模型中的所有实体。我尝试了几次，它总是一致的。他们我放置了 500 个索引属性，并且始终保持一致......
我还担心每个实体组每秒限制为 1 个 put() 的一些说法。我 put() 30 个具有相同祖先的实体（相同的 HTTP 请求但 put() 一个接一个），这与放置 30 个没有祖先的实体基本上没有区别。（我正在使用 NDB，它可以进行某种优化吗？）
我用一个没有任何流量的空应用程序对此进行了测试，我想知道真正的流量会对“最终一致性”产生多大影响。
我知道我可以测试本地开发的“最终一致性”。我的问题是：
我真的需要重组我的应用程序来处理最终的一致性吗？
还是因为最终的一致性实际上在实践中 99% 是一致的，所以保持原样是可以接受的？
如果您有一个小型应用程序，那么您的数据可能位于同一磁盘的同一部分，并且您有一个实例。您可能不会注意到最终的一致性。随着您的应用程序的增长，您会注意到它。通常需要几毫秒才能达到一致性，但我见过需要一个小时或更长时间的情况。
通常，查询是您最注意到的地方。减少影响的一种方法是仅通过键查询，然后使用 ndb.get_multi() 加载实体。通过键获取实体可确保您获得该实体的最新版本。但是，它不能保证键列表是强一致的。因此，您可能会得到与查询条件不匹配的实体，因此遍历实体并跳过不匹配的实体。
根据我的观察，最终一致性的痛苦会随着你的应用程序的增长而逐渐增加。在某些时候，您确实需要认真对待它并更新代码的关键区域来处理它。
如果结果不一致，最坏的情况是什么？
用户是否看到一些过时的不重要信息？那可能没问题。
你会误算一些重要的事情，比如某样东西的价格吗？或者商店中的库存商品数量？在这种情况下，您会希望避免这种偶然发生。
仅从观察来看，随着您的数据集变大，最终一致的结果似乎会越来越多，我怀疑您的数据分散在更多的平板电脑上。
此外，如果您通过 key/id 的 get() 请求读取实体，它将始终保持一致。确保您正在执行查询以获得最终一致的结果。
复制速度将主要取决于服务器工作负载。通常在卸载的系统上，复制延迟将是毫秒。
但是“最终一致”的想法是您需要编写您的应用程序，以便您不依赖它；任何复制延迟都需要在应用程序的限制范围内允许。