【问题标题】:Service Fabric - How could we generate a partitionKey?Service Fabric - 我们如何生成 partitionKey?
【发布时间】:2019-01-20 01:51:00
【问题描述】:

我有一个有状态的服务,其中包含一系列来自
的分区键 -9223372036854775808 到 9223372036854775807(UniformInt64Partition)。

如何在调用服务时生成足够的分区键以改善所有分区之间的工作负载分布?

谢谢你

【问题讨论】:

  • 你可以创建一个哈希。请参阅the docs 处的选择哈希算法部分
  • 这正是我要找的,谢谢你

标签: azure-service-fabric partitioning service-fabric-stateful


【解决方案1】:

对于这么大范围的分区键,最好的方法是在字段或字段集合的顶部使用hashing algorithm 来生成尽可能少的冲突的键(数字)。

假设您正在存储客户信息,例如,来自“John Smith”的客户名称的哈希值可能会生成 32 的哈希值,因为任何与“John Smith”同名的用户都会生成相同的哈希值,如果它不频繁,那不是问题,因为 32 不是 id 并且它们可以重复,具有相同的散列,它们将存储在同一个分区上。

如果您真的想尽可能均匀地分配这些值,您可以使用连接的另一个字段来区分“John Smith”和“John Smith”,例如出生日期,除非两者出生在同一日期,否则您会发现每个都有不同的值。

在您的情况下,由于范围非常大,您必须使用散列算法对这些值进行散列,以适应 -9223372036854775808 到 9223372036854775807 的范围。

你需要那么多钥匙吗?

如果您的系统不希望有非常多的分区,管理此问题的一种简单方法是使用一个自然数,该自然数密切反映您选择的散列函数提供的键范围,您可能会决定选择一个更好的性能,或更低的碰撞,或两者兼而有之。

【讨论】:

  • 标记为已接受,谢谢。我不知道我们是否真的需要那么多钥匙,但对我来说看起来太多了,我会问我的经理。再次感谢你
【解决方案2】:

如果您已经使用 GUID 作为密钥来识别您的数据,这并不难。要知道的关键是 GUID,虽然(实际上)全球唯一,但在一个范围内甚至没有接近均匀分布。我使用 SHA1 散列算法对 GUID 进行散列,因为尽管它有 shortcomings as a cryptographic algorithm,但它可以很好地生成均匀分布的散列,而不需要过多的服务器(在计算和 RAM 方面)。

附带说明,从 GUID 变为 long 会造成数据丢失(GUID 相当于 128 位整数)。由于目标是跨分区分布数据,这没关系……不要为小事操心。事实上,您可以使用比 Int64 更小的范围,但如果您已经有了 GUID,那何必再费心呢。

有关从 GUID 创建分区键的扩展方法,请参见前面的代码。我的实现代码将其折叠为两行,但我将其分解为下面以便我可以对其进行注释。

public static ServicePartitionKey ToPartitionKey(this Guid id)
{
    // Hash algorithms need byte arrays, so we're converting the Guid here
    byte[] guidBytes = id.ToByteArray();

    // SHA1 is light weight and good at creating distribution across the range.
    // Do not use for encryption!
    SHA1CryptoServiceProvider hasher = new SHA1CryptoServiceProvider();

    // Hash the Guid's bytes.
    byte[] hashedBytes = hasher.ComputeHash(guidBytes);

    // Now that our data is repeatibly but distributed evenly, we make it a long
    long guidAsLong = BitConverter.ToInt64(hashedBytes, 0);

    // return the partition key
    return new ServicePartitionKey(guidAsLong);
}

【讨论】:

    猜你喜欢
    • 2016-08-12
    • 2017-12-30
    • 2016-09-30
    • 2018-07-16
    • 1970-01-01
    • 2021-01-09
    • 1970-01-01
    • 1970-01-01
    • 2019-11-30
    相关资源
    最近更新 更多