应用程序引擎数据管道对话 - 对于扇入物化视图,为什么需要工作索引？

Question

我正在尝试了解谷歌i/o上提供的数据管道谈话:http: //www.youtube.com/watch？v = zSTC_TU7rtc

如果我要批量通过输入序列标记,我不明白为什么需要扇入工作索引.

乐观排队的任务不能抓住所有未应用的标记,通过尽可能多的标记(重复获取一批10个,然后事务更新物化视图实体),并在任务超时之前重新入队自己通过所有标记工作？

工作索引是否与查询所有未应用标记的效率有关？也就是说,最好查询"带有work_index =的标记"而不是"带有apply = False的标记"？如果是这样,为什么呢？

作为参考,引导我进入数据管道的问题+答案是: app engine datastore:逐步更新的地形高度图的模型

Answer 1

一些东西:

• 我的方法假设有多个工作者(请参阅ShardedForkJoinQueue:http://code.google.com/p/pubsubhubbub/source/browse/trunk/hub/fork_join_queue.py),其中任务的入站速率超过单个工作量线程可以做.考虑到这一点,您将如何使用简单的"applied = False"来分割N个线程的工作？可能会随机将模型上的另一个字段分配给worker的shard_number; 那么你的查询将是"shard_number = N AND applied = False"(需要另一个复合索引).好的,这应该工作.

• 但是,你怎么知道你需要多少工人分片/线程？使用上面的方法,您需要静态配置它们,以便您的shard_number参数介于1和N之间.您一次只能有一个线程查询每个shard_number,否则您会有争用.我希望系统在运行时找出分片/线程数.我的方法将一起工作分成合理大小的块(如10个项目),然后将连续任务排入队列来处理其余的事情.使用查询游标我知道每个延续都不会与最后一个线程重叠,因此没有争用.这给了我一个动态数量的线程在同一个分片的工作项上并行工作.

• 现在说你的队列备份了.您如何确保首先处理最早的工作项？换句话说:你如何防止饥饿？您可以将模型上的另一个字段分配给插入时间 - 将其命名为add_time.现在您的查询将是"shard_number = N AND applied = False ORDER BY add_time DESC".这适用于低吞吐量队列.

• 如果您的工作项目写入率上升了一下怎么办？你将要编写许多行,并使用大致相同的add_time.这需要您的实体的Bigtable行前缀,如"shard_number = 1 | applied = False | add_time = 2010-06-24T9:15:22".这意味着每个工作项插入都会击中相同的 Bigtable平板电脑服务器,该服务器当前是降序索引的词汇头的所有者.所以从根本上说,你只限于每个工作分片的数据存储区写入的单个机器的吞吐量.

• 使用我的方法,您唯一的Bigtable索引行的前缀是递增工作序列号的哈希值.每次序列号递增时,此work_index值分散在Bigtable的词法行空间中.因此,每个顺序工作项排队可能会转到不同的平板电脑服务器(给定足够的数据),将我的队列负载分散到一台机器上.使用这种方法,写入速率应该仅受到集群中物理Bigtable机器数量的有效约束.