出于计费目的，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.3 百万)比 Cloud Datastore 实体写入(0.01 百万)多 3 倍.易失实体的数量由 Cloud Datastore Entity Deletes (0.00089 Millions) 指示，如果这很重要的话.

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.

内存缓存命中率为 81%，但我不知道这是否仅用于我的应用程序的显式内存缓存使用，还是包括 ndb 的内存缓存使用.

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 分钟内没有多少内存缓存驱逐(该应用没有专用的内存缓存存储桶).
• 每个写操作都会使缓存失效，因此需要读取数据存储区来更新缓存，但后续的读操作应该来自缓存(直到下一个写操作)，这应该导致总体上相当可比如果不计算缓存读取，则读取和写入计数
• 我的(相当复杂的)应用代码确实符合我的描述:)

• there weren't many memcache evictions during those ~20 min (the app doesn't have a dedicated memcache bucket).
• each write op invalidates the cache thus requiring a datastore read to update the cache, but subsequent read ops should come from the cache (until the next write op), which should lead to rather comparable overall read and write counts if cached reads aren't counted
• my (fairly complex) app code really does what I'm describing :)

我在文档中没有找到任何关于此的内容，所以想知道是否有人知道缓存的 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.

快速回答是，数据存储实体的内存缓存命中不作为计费目的的数据存储读取收费.

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

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