URL Shortener键/值分区/行密钥策略

时间:2014-07-10 18:55:39

标签: azure azure-storage

我希望为项目创建URL缩短服务。这将是一项非常基本的服务,需要存储以下内容:

  1. 一个随机的6个字符([a-z][A-Z][0-9])短字符串(唯一)。 id / key。
  2. 长网址。价值。
  3. 我选择将Azure表存储用于此服务,因为它适用于我们的堆栈。

    当请求带有短字符串(键)时,我只需要查找实体并返回长URL(值)。

    这只是基本的键/值存储。由于ATS需要分区和行键来定义实体,我试图考虑分区和行键的最佳策略。

    到目前为止,我已经提出了以下选项:

    1. 使用短字符串作为分区键。空(否)行键。
    2. 使用短字符串的第一个字母定义分区,然后使用剩余的5个字符作为行键。这将创建最多62个分区,理论上可以在所有分区上均匀分布实体。

      • 这两种方法中的任何一种都是个好主意吗?
      • 各自的优点和缺点是什么?
      • 是否有更好的方法进行简单的键/值对存储?

2 个答案:

答案 0 :(得分:1)

我选择了选项1.

使用缩短的URL作为分区键。这使得服务后面的机器可以决定如何最好地对您提供的密钥进行分区。你真的不需要一个行键,所以它可以保持空白,或者,如果你不介意重载行键,那就把长URL放在那里。

具有相同分区键的所有行必须由同一台计算机处理,因此当您提供较少的分区键时,表服务的负载平衡选项会受到限制。此外,如果您使用由许多行共享的公共分区键(例如,短URL的第一个字母),则后备服务器可能必须使用该分区键读取所有行,并过滤您的行键以返回目标行。

在进行交易时使用通用分区键或快速写入数据比快速读取更重要。

如果我使用Azure表做同样的事情,我会使用您在选项1中概述的相同方案。

答案 1 :(得分:1)

Thinkable有一个很好的总结。我们还有一篇关于如何充分利用Azure表的博客文章http://blogs.msdn.com/b/windowsazurestorage/archive/2010/11/06/how-to-get-most-out-of-windows-azure-tables.aspx。查看“可伸缩性”部分,查看与您的方案直接相关的讨论。