每个 Fetch、Count 和 Query 操作消耗多少数据存储读取?
我正在阅读有关 Google App Engine 分组许多用户的信息 (Fig1, 图2,图3)无法弄清楚其计费报告中大量数据存储读取的来源。
您可能知道,数据存储区读取上限为每天 5 万次操作,超过这个预算你就必须付费。
50K 操作听起来像是很多资源,但不幸的是,似乎每个操作(查询、实体获取、计数..)都隐藏了多个数据存储读取。
是否可以通过 API 或其他方法知道有多少数据存储读取隐藏在常见的 RPC.get 、 RPC.runquery 调用后面?
Appstats 在这种情况下似乎毫无用处,因为它只提供 RPC细节而不是隐藏的读取成本。
有一个像这样的简单模型:
class Example(db.Model):
foo = db.StringProperty()
bars= db.ListProperty(str)
以及数据存储中的 1000 实体,我对此类操作的成本感兴趣:
items_count = Example.all(keys_only = True).filter('bars=','spam').count()
items_count = Example.all().count(10000)
items = Example.all().fetch(10000)
items = Example.all().filter('bars=','spam').filter('bars=','fu').fetch(10000)
items = Example.all().fetch(10000, offset=500)
items = Example.all().filter('foo>=', filtr).filter('foo<', filtr+ u'\ufffd')
I'm reading on Google App Engine groups many users (Fig1, Fig2, Fig3) that can't figure out where the high number of Datastore reads in their billing reports come from.
As you might know, Datastore reads are capped to 50K operations/day, above this budget you have to pay.
50K operations sounds like a lot of resources, but unluckily, it seems that each operation (Query, Entity fetch, Count..), hides several Datastore reads.
Is it possible to know via API or some other approach, how many Datastore reads are hidden behind the common RPC.get
, RPC.runquery
calls?
Appstats seems useless in this case because it gives just the RPC details and not the hidden reads cost.
Having a simple Model like this:
class Example(db.Model):
foo = db.StringProperty()
bars= db.ListProperty(str)
and 1000 entities in the datastore, I'm interested in the cost of these kind of operations:
items_count = Example.all(keys_only = True).filter('bars=','spam').count()
items_count = Example.all().count(10000)
items = Example.all().fetch(10000)
items = Example.all().filter('bars=','spam').filter('bars=','fu').fetch(10000)
items = Example.all().fetch(10000, offset=500)
items = Example.all().filter('foo>=', filtr).filter('foo<', filtr+ u'\ufffd')
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
只是为了确保:
我几乎可以肯定:
这个使用小型数据存储操作(不需要获取实体,只需获取键),因此这将算作 1 次读取 + 10,000(最大)小操作。
Just to make sure:
I'm almost sure:
This one uses small datastore operations (no need to fetch the entities, only keys), so this would count as 1 read + 10,000 (max) small operations.
请参阅 http://code.google.com/appengine/docs/billing.html# Billable_Resource_Unit_Cost 。
查询需要 1 次读取加上每个返回实体的 1 次读取。 “返回”包括按偏移量或计数跳过的实体。
因此,每个读取次数为 1001 次:
对于这些读取次数,收费的读取次数为 1 加上与过滤器匹配的实体数量:
您应该考虑将计数存储在数据存储中,而不是使用计数,如果需要更新,则进行分片每秒计数一次以上。 http://code.google.com/appengine/articles/sharding_counters.html
只要有可能,您应该使用游标而不是偏移量。
See http://code.google.com/appengine/docs/billing.html#Billable_Resource_Unit_Cost .
A query costs you 1 read plus 1 read for each entity returned. "Returned" includes entities skipped by offset or count.
So that is 1001 reads for each of these:
For these, the number of reads charged is 1 plus the number of entities that match the filters:
Instead of using count you should consider storing the count in the datastore, sharded if you need to update the count more than once a second. http://code.google.com/appengine/articles/sharding_counters.html
Whenever possible you should use cursors instead of an offset.