获取并迭代大型数据集，什么是好的？为什么管理日志/appstas有区别？
获取并迭代大型数据集，什么是好的？为什么管理日志/appstas有区别？
提问于 2011-09-13 11:11:05
当试图优化基于位置获取存储记录的查询时，我抛出了一些奇怪的东西(我认为)，获取大型数据集需要花费大量的cpu时间。
基本上，我有> 1000条记录需要迭代才能在3000米的用户位置内找到商店，而且我在管理控制台中得到了相当多的数字。
这导致了一些数据存储测试，产生了一些有趣的数字，以获得1000条记录。
我有6个测试方法分别运行，并从管理控制台和appstats获取cpu时间，结果(在生产中)：
r = db.GqlQuery("SELECT __key__ FROM StoreRecords").fetch(1000)
# appstats: real=120ms cpu=182ms api=845ms
# admin console: 459ms 1040cpu_ms 845api_cpu_ms
r = db.GqlQuery("SELECT __key__ FROM StoreRecords").fetch(100)
# appstats: real=21ms cpu=45ms api=95ms
# admin console: 322ms 134cpu_ms 95api_cpu_ms
r = db.GqlQuery("SELECT * FROM StoreRecords").fetch(1000)
# appstats: real=1208ms cpu=1979ms api=9179ms
# admin console: 1233ms 10054cpu_ms 9179api_cpu_ms
r = db.GqlQuery("SELECT * FROM StoreRecords").fetch(100)
# appstats: real=57ms cpu=82ms api=929ms
# admin console: 81ms 1006cpu_ms 929api_cpu_ms
r = model.StoreRecords.all().fetch(1000)
# appstats: real=869ms cpu=1526ms api=9179ms
# admin console: 1061ms 9956cpu_ms 9179api_cpu_ms
r = model.StoreRecords.all().fetch(100)
# appstats: real=74ms cpu=86ms api=929ms
# admin console: 97ms 1025cpu_ms 929api_cpu_ms在这里，我只取1000条记录，但需要全部提取(约4-5000条)。
我的问题是：
- 应该抓取1000个记录真的要花费将近20秒(10054cpu_ms + 9179api_cpu_ms)？
- 为什么在应用程序和管理控制台时间之间存在差异？什么是计算我的配额？
通过将获取的记录推入memcache作为一个原型，可以轻松地绕过这一问题。但我对appstas和管理控制台之间的高使用率和时间差感到好奇。
奖金问题：为什么获取1000条记录总是导致9179api_cpu_ms？
回答 1
Stack Overflow用户
回答已采纳
发布于 2011-09-14 00:28:36
为什么检索大量记录需要大量资源是令人惊讶的呢？这是一个O(n)进程，您不应该在每次请求的基础上这样做。按顺序回答你的问题：
- 使用多少CPU时间取决于记录的性质，但这个结果并不令人惊讶。请注意，这是近20秒的CPU，而不是挂钟秒。还请注意，当新的计费模式推出时，您将被收取数据存储操作和实例时间的费用，这就是您应该优化的内容。
- 管理控制台显示您所依据的权威数据。appstats的数字较低，因为它们只计算在API调用期间花费的时间，而不是计算执行自己的代码所花费的时间。
如果您的记录集很小且相当静态，则应该在实例内存中缓存它们，而不是每次获取它们或将它们存储在memcache中。如果它们更大、更动态，您应该使用类似于GeoModel的东西，这样就可以执行地理查询，并且只获取相关的记录。
获取1000条记录总是占用相同数量的API CPU时间，因为这是数据存储访问成本的表示方式--这实际上并不是占用的时间。新模型通过将其分解为单独的可计费操作来解决这一问题。
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/7400892
复制相关文章
相似问题
腾讯云开发者
