实际上，最终的“最终一致性”如何呢？在HRD？

问题描述

我正在将应用程序从主/从应用程序迁移到HRD。我想听听那些已经完成迁移的人的一些评论。

1. 我试过一个简单的例子来发布一个新的没有祖先的实体并重定向到页面以列出来自该模型的所有实体。我试了几次，总是一致的。他们把500个索引的属性放在一起，并且总是保持一致......我还担心一些关于每个实体一个put（）的限制的说法每秒组数。我把30个实体放在同一个祖先（相同的HTTP请求，但是一个接一个地放）（），这与把30个没有祖先的实体放在一起没有任何区别。 （我正在使用NDB，是否可以进行某种优化？）
   





我用一个空应用测试了这个没有任何流量，我想知道真正的流量会对最终一致性产生多大影响。





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



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





或者可以接受这种方式，因为最终的一致性实际上在99％的实践中是一致的？





通常，查询是您最注意的地方。减少影响的一种方法是仅查询按键，然后使用ndb.get_multi（）加载实体。通过键获取实体可确保您获得该实体的最新版本。尽管如此，它并不能保证密钥列表的一致性。因此，您可能会得到与查询条件不匹配的实体，因此循环遍历实体并跳过不匹配的实体。



从我注意到的情况来看，随着应用程序的增长，最终一致性的痛苦会逐渐增加。在某些情况下，您需要认真对待并更新代码的关键区域来处理它。


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. 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...

2. 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?

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.

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.

这篇关于实际上，最终的“最终一致性”如何呢？在HRD？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！