使用Sharded Counter值作为实体ID以保持GAE Long ID较短是很好的做法 [英] Is it good to use Sharded Counter value as Entity ID to keep GAE Long ID short

问题描述

使用由 GAE Sharded Counter 代码生成的Long值的可行性。就跨数据中心拥有唯一的Long ID而言？

为什么我需要使用计数器值作为ID？ GAE会生成非常长的Long值作为实体ID，在我的应用程序中，我需要有一个简短的ID就像Sharded计数器生成的那个ID一样。

问题：在某些时候，分片计数器是否会为不同的请求生成相同的值，从而导致ID可能发生冲突？

解决方案

这是不可行的，因为分片计数器的目标是保持最终一致的计数，有助于避免争用，同时增加或减少计数器的值通过将该作品分成不同的碎片。 get_count方法将总结所有分片计数器以返回总计数，但该值不能被视为唯一的ID，因为它只能确定它最终会计算您对其执行的所有增加或减少操作，因此它可以返回即使每个请求涉及增加操作，对于不同的请求也是相同的值。

可以设计一种类似的方法，其中包含保留标识池的分片，您将不得不修改分片计数器的代码，而不是分割增加或减少的计数器，操作会在一组预定义的分片池中随机选择，并从其中一个返回一个id并确保它不再被返回。每个分片的池可以是适合您特定需求的数字范围，并且当其中一个池超出保留范围时您必须管理这种情况，并且必须再次重新填充它。

我建议看看这篇文章，以获得一些这类问题的选择： http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram

What is the viability of using a Long value generated by the GAE Sharded Counter code. In terms of having a unique Long id across datacenters?

Why do I need to use the counter value as ID? GAE generates very long Long values as entity id, which in my app I need to have short ID's like the one generated by the Sharded counter at first.

Question: Would the sharded counter at some point will generate the same value for a different request such that ID's might collide?

解决方案

It is not viable since the sharded counter goal is to keep an eventually consistent count that helps avoid contention while increasing or decreasing the value of the counter by dividing that work in different shards. The get_count method will sum up all the sharded counters to return the total count, but that value cannot be considered as a unique id because it's only sure that it will eventually count all the increase or decrease operations you performed over it, so it can return the same value for different requests, even if each request involves an increase operation.

A similar approach can be designed that would have a shard of reserved id's pools, you would have to modify the code of the sharded counters but instead of sharding the increase or decrease of the counter the operation would randomly select among a predefined set of sharded pools of id's and from one of them return an id and make sure that it's not returned again. The pools for each shard can be number ranges that fit your particular needs, and you would have to manage the situation when one of the pools runs out of reserved ranges and you have to 'refill' it again.

I recommend taking a look at this article, to get some options to this kind of problem: http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram

这篇关于使用Sharded Counter值作为实体ID以保持GAE Long ID较短是很好的做法的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！