在实践中，“最终一致性"的最终程度如何?在人力资源开发? [英] In practice, how eventual is the "eventual consistency" in HRD?

问题描述

我正在将应用程序从 Master/Slave 迁移到 HRD.我想听听已经完成迁移的人的评论.

I am in the process of migrating an application from Master/Slave to HRD. I would like to hear some comments from who already went through the migration.

1. 我尝试了一个简单的例子，只是发布一个没有祖先的新实体，然后重定向到一个页面以列出该模型中的所有实体.我试了几次，它总是一致的.他们我把 500 个索引属性，再一次，始终保持一致......

1. I tried a simple example to just post a new entity without ancestor and redirecting to a page to list all entities from that model. I tried it several times and it was always consistent. Them I put 500 indexed properties and again, always consistent...

我还担心有人声称每个实体组每秒只能执行 1 个 put().我 put() 30 个具有相同祖先的实体(相同的 HTTP 请求但 put() 一个一个)，这与放置 30 个没有祖先的实体基本上没有区别.(我正在使用 NDB，它会做某种优化吗?)

I was also worried about some claims of a limit of one 1 put() per entity group per second. I put() 30 entities with same ancestor (same HTTP request but put() one by one) and it was basically no difference from puting 30 entities without ancestor. (I am using NDB, could it be doing some kind of optimization?)

我用一个没有任何流量的空应用程序进行了测试，我想知道实际流量对最终一致性"的影响有多大.

I tested this with an empty app without any traffic and I am wondering how much a real traffic would affect the "eventual consistency".

我知道我可以测试本地开发的最终一致性".我的问题是:

I am aware I can test "eventual consistency" on local development. My question is:

我真的需要重构我的应用程序来处理最终一致性吗?

Do I really need to restructure my app to handle eventual consistency?

或者保持原样是可以接受的，因为最终的一致性在实践中实际上是一致的 99%?

Or it would be acceptable to leave it the way it is because the eventual consistency is actually consistent in practice for 99%?

推荐答案

如果您有一个小型应用程序，那么您的数据可能位于同一磁盘的同一部分，并且您有一个实例.您可能不会注意到最终的一致性.随着您的应用程序的增长，您会注意到更多.通常需要几毫秒才能达到一致性，但我见过需要一个小时或更长时间的情况.

If you have a small app then your data probably live on the same part of the same disk and you have one instance. You probably won't notice eventual consistency. As your app grows, you notice it more. Usually it takes milliseconds to reach consistency, but I've seen cases where it takes an hour or more.

通常，查询是您最关注的地方.减少影响的一种方法是仅通过键查询，然后使用 ndb.get_multi() 加载实体.通过键获取实体可确保您获得该实体的最新版本.但是，它并不能保证密钥列表是高度一致的.因此，您可能会得到与查询条件不匹配的实体，因此遍历实体并跳过不匹配的实体.

Generally, queries is where you notice it most. One way to reduce the impact is to query by keys only and then use ndb.get_multi() to load the entities. Fetching entities by keys ensures that you get the latest version of that entity. It doesn't guarantee that the keys list is strongly consistent, though. So you might get entities that don't match the query conditions, so loop through the entities and skip the ones that don't match.

据我所知，最终一致性的痛苦随着您的应用程序的增长而逐渐增加.在某些时候，您确实需要认真对待它并更新代码的关键区域来处理它.

From what I've noticed, the pain of eventual consistency grows gradually as your app grows. At some point you do need to take it seriously and update the critical areas of your code to handle it.

这篇关于在实践中，“最终一致性"的最终程度如何?在人力资源开发?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！