是否出于计费目的将ndb缓存的读取操作仍计为数据存储读取操作? [英] Are ndb cached read ops still counted as datastore read ops for billing purposes?

问题描述

来自 NDB缓存:

NDB为您管理缓存.有两个缓存级别: 上下文缓存和通向App Engine标准缓存的网关 服务，内存缓存.默认情况下，所有实体均启用两个缓存 类型，但可以进行配置以满足高级需求.

NDB manages caches for you. There are two caching levels: an in-context cache and a gateway to App Engine's standard caching service, memcache. Both caches are enabled by default for all entity types, but can be configured to suit advanced needs.

我的应用程序未更改任何ndb缓存配置，因此必须使用默认值-启用了两个缓存级别.

My app doesn't make any ndb caching configuration change, so it must be using the defaults - both caching levels enabled.

我正在我的登台环境(一个单独的专用GAE项目)上进行一些测试，在这里我可以将活动序列与任何虚假的外部请求完全隔离.

I'm running some tests on my staging environment (a separate, dedicated GAE project) where I can totally isolate sequences of activity from any spurious external requests.

每个活动序列都由一连串的推送任务组成，它们相互触发，创建了数百个易失性实体，对其中一些进行了可变次数的修改，对它们进行了可变次数的读取，最后将它们全部删除.

Each sequence of activity consists of a cascade of push tasks triggering each-other, creating some hundreds of volatile entities, modifying some of them a variable number of times, reading all of them a variable number of times and finally deleting them all.

在序列期间仅访问少数几个其他已经存在的实体，所有这些实体在序列结束后都将保留.对持久性实体的访问次数应大大低于对易失性实体的访问次数.

Only a handful of other already existing entities are accessed during the sequence, all of them persisting after the sequence ends. The number of accesses to the persistent entities should be significantly lower than the number of accesses to the volatile ones.

绝大多数读取操作是通过键或ID从keys_only查询或其他相关实体获得的实体查找.

The vast majority of read operations are entity lookups by key or ids, obtained from keys_only queries or from other related entities.

我没有使用实体血统.这些任务大多数执行跨组事务，而且我确实经常看到由于一些热门"实体上的数据争用而导致的事务失败/重试(我估计这次运行中约有200-400个，很难算在内). Stackdriver日志页面).

I'm not using entity ancestry. Most of these tasks perform cross-group transactions and I do see quite often transaction failures/retries due to data contention on a few "hot" entities (I'd estimate some 200-400 of them in this run, hard to count in the Stackdriver log page).

每天重新设置配额后，立即执行一个这样的〜20分钟的序列后，该应用程序的仪表板显示的Cloud Datastore读取操作(0.03百万)比Cloud Datastore实体写入(0.01百万)多3倍.如果重要的话，易失性实体的数量由Cloud Datastore Entity Deletes(0.00089百万)指示.

After executing one such ~20 minutes sequence freshly after the daily quota reset, the app's dashboard shows 3x more Cloud Datastore Read Operations (0.03 Millions) than Cloud Datastore Entity Writes (0.01 Millions). The number of volatile entities is indicated by the Cloud Datastore Entity Deletes (0.00089 Millions), if that matters.

memcache的命中率为81％，但我不知道这是仅用于我的应用程序的显式memcache用途，还是它包括ndb的memcache用途.

The memcache hit rate was 81%, but I don't know if that is for my app's explicit memcache use only or if it includes the ndb's memcache use.

一些较早的类似测量，但是在干净的环境中却没有得到类似的结果，我做了一次干净的测量以作为验证.

Some earlier similar measurements but not in as clean environment produced similar results, I did this clean one as a verification.

出现这些观察结果 ，表明从缓存中读取的实体仍视为数据存储读取.但是我在这里假设:

These observations appear to suggest that the entity reads from the cache still count as datastore reads. But here I'm assuming that:

• 在大约20分钟内没有太多的内存缓存驱逐(该应用程序没有专用的内存缓存存储区).
• 每个写操作都会使高速缓存无效，因此需要读取数据存储以更新高速缓存，但是后续的读操作应来自高速缓存(直到下一个写操作为止)，这应该导致总体上具有可比性如果不计算缓存的读取次数，则读取和写入计数
• 我的(相当复杂的)应用程序代码确实符合我的描述:)

我在文档中没有找到关于此的任何信息，所以想知道是否有人知道是否将缓存的ndb读取确实算作数据存储读取，或者可以指出我的解释或某些官方文档中的缺陷关于这个问题.

I didn't find anything about this in the docs, so wondering if someone knows if the cached ndb reads indeed count as datastore reads or can point me to flaws in my interpretation or some official documentation on the subject.

推荐答案

memcache命中率包括由ndb编写的实体的命中.它不包括ndb在上下文中命中的命中次数.

The memcache hit rate includes the hits for entities written by ndb. It does not include the number of in-context cache hits by ndb.

每次写入数据存储区都会使缓存无效，因此下一次读取将不会缓存在内存缓存或上下文缓存中.

Each write up to datastore invalidates the caches, so the next read will not be cached in memcache or in the in-context cache.

另一件事是，ndb为每个事务创建了一个新的上下文内缓存，因此，面对事务时，上下文内缓存不是很有效.

One other thing is that ndb creates a new in-context cache for each transaction, so the in-context cache isn't very effective in the face of transactions.

快速的答案是，针对数据存储实体的Memcache命中不计入为计费目的而读取的数据存储.

The quick answer is that a memcache hit for a datastore entity is not charged as a datastore read for billing purposes.

这篇关于是否出于计费目的将ndb缓存的读取操作仍计为数据存储读取操作?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！