Question

我正在尝试提出一种基于DateTime的分区键策略，该策略不会导致最佳实践指南中经常描述的仅附加写入瓶颈。

基本上，如果您使用YYYY-MM-DD之类的内容进行分区，那么特定日期的所有写操作都会以相同的分区结束，这会降低写入性能。

理想情况下，分区键甚至应该在尽可能多的分区上分配写入。

为了实现这一目标，同时仍然将关键字关闭DateTime值，我需要想出一种方法来分配日期行值的桶数量，其中桶的数量是每个时间间隔的预定数量 - 比如每天50个。为存储桶分配日期行应尽可能随机 - 但对于给定值始终相同。原因是我需要能够在给定原始DateTime值的情况下始终获得正确的分区。换句话说，这就像一个哈希。

最后，关键的是，我需要分区键在某个聚合级别上是顺序的。因此，虽然给定时间间隔（例如1天）的DateTime值将随机分布在X个分区键上，但当天的所有分区键都将位于可查询范围之间。这将允许我查询所有行的聚合间隔，然后按DateTime值对它们进行排序以获得正确的顺序。

思考？这必须是已经解决的一个众所周知的问题。

Answer 1

如何使用日期时间戳的毫秒组件，模式50.那将在一天中为您提供随机分布，值本身将是连续的，并且您可以在给定原始时间戳的情况下轻松计算未来的PartitionKey？

Answer 2

要添加到Eoin的答案，下面是我用来模拟他的解决方案的代码：

   var buckets = new SortedDictionary<int,List<DateTime>>();
   var rand = new Random();

   for(int i=0; i<1000; i++)
   {
          var dateTime = DateTime.Now; 
          var bucket = (int)(dateTime.Ticks%53);
          if(!buckets.ContainsKey(bucket))
                 buckets.Add(bucket, new List<DateTime>());

          buckets[bucket].Add(dateTime);
          Thread.Sleep(rand.Next(0, 20));
   }

因此，这应该模拟大约1000个请求，每个请求相隔0到20毫秒。

这导致了53个“桶”之间相当好/均匀的分布。正如预期的那样，它也导致避免仅附加或仅前置的反模式。

Azure表分区策略

2 个答案: