需要存储 128 *bit* 主键：我应该使用 SQL Azure 还是 Azure Table？或者只是在 Azure Blob 中使用链表答案

【问题标题】：Need to store 128 *bit* Primary Key: Should I use SQL Azure or Azure Table? Or Just use a linked list in Azure Blob需要存储 128 *bit* 主键：我应该使用 SQL Azure 还是 Azure Table？或者只是在 Azure Blob 中使用链表
【发布时间】：2011-03-26 17:24:39
【问题描述】：

我需要存储一个大型（128 位）PK。每个 int 都会有一些相应的列......现在没有定义模式......我希望未来的模式灵活。（我只需要保守的灵活性，例如不时添加新列）

在这一点上，我不太关心连接等的能力。我主要想选择一个随机的 PK 并向上或向下搜索到接下来的 10 条记录。由于搜索中可能存在大量空白，因此向上和向下搜索的成本可能会有所不同。

处理此请求的最佳技术是什么？我对可以为我省钱（每笔交易）和存储空间的东西感兴趣。我也对性能感兴趣。

你有什么推荐的？

更新

好的，那这是干什么用的？我想为 IPv6 地址创建数据历史记录。当然，这将是一个非常稀疏的表格......但我确实需要跟踪有关所见 IP 的某些事情。

【问题讨论】：

你会考虑内存中的稀疏矩阵吗？我不知道您的应用程序是什么，但我无法想象任何应用程序会消耗这么多有意义数据，而这些数据不能用稀疏矩阵轻松表示或用随机数生成器。
你知道2^128有多大吗？
实际上存储密钥的数量无论如何都会是一个“小问题”：2^128 * 128 位 = 大约。 5 * 10^39 字节 = 5 * 10^27 TB。
我不知道 azure 等的具体情况，但是在典型的数据库中，当您在 PK 上有索引时，我认为向上或向下搜索接下来的 10 条记录的成本应该' 变化不大（可能根本没有，取决于索引的类型）。
@Bob Kaufman 我需要将其保存在持久存储中以用于存档目的

标签： amazon-s3 azure ipv6 azure-sql-database azure-storage

【解决方案1】：

为了澄清，我认为您需要一个 128 位（而不是 2^128 位）的密钥。

我将此作为关于 Db Key 类型选择的问题，我不确定 Azure 角度会产生什么后果。 AFAIK 它建立在 MS-SQL 之上。

128 位或 16 字节与 Guid (UniqueIdentifier) 的大小相同，但我认为您不想使用它。尽管支持将其用作密钥。

直接选择类似于 binary(16)，但我不知道它是否适合作为 PK。

您可以将其编码为 char(32) 十六进制字符串，不过分。

对于实用性估计，关键因素是您的数据有多稀疏或更好：您预计需要存储多少个地址？

【讨论】：

维基百科说 IPv6 是 2^128...en.wikipedia.org/wiki/IPv6，我看错了吗？
它会随着时间的推移而增长，但是由于我们现在生活在 IPv4 世界中，就 PK 使用而言，要达到 2^32 还需要很长时间。我只是在为未来做打算。
IPV6 是一个 128 位地址，允许 2^128 个可能的值。如果您需要的不仅仅是 2^128 的一小部分，您就有麻烦了。
我按照您的建议更改了关键要求。是128位！对不起，我理解的延迟！在选择如何存储PK时，我的目标是向上/向下寻找并找到下一个更小/更大的值。

【解决方案2】：

Windows Azure Tables 是我的建议，但只定义了一种排序顺序，因此很难向前和向后搜索。您可能最终不得不将每个键存储两次，一次按正常顺序，一次反转（0xFFF...F - 键）以有效地支持两个扫描方向。

【讨论】：

嗨史蒂夫，很高兴看到你使用这个网站！如果是这种情况，我一半希望发布已宣布的二级索引。也许我可以存储 MaxValue 的第二个值 - System.int128？我想我需要将它存储为一个字符串，这仍然是真的吗？
是的，Azure 表中的分区键和行键都是字符串，如果您需要排序，这一点很重要。
是的，你们两个都是对的。这意味着对数字进行零填充很重要。（5 应存储为“000...5”，以确保字典的行为类似于数字排序。）
谢谢。是否有一个公式或计算器可以用来确定这将花费我多少（包括 XML 开销）？理想情况下，我希望将估算存储成本和估算网络成本分解为单独的订单项。

【解决方案3】：

首先，您在 2^128 整数键中的前提是错误的，因为您提到要存储 IP V6 地址。 IP V6 地址的长度为 128 位。要将其存储为整数，每个地址需要 128/32 或 4 个 32 位整数。所以正确的估计是 2^128 个可能的地址 * 4 个整数，总共 2^128 * 4 个 32 位整数的键......

无论如何，我希望以字节为单位，所以我们只需要 2^128 个可能的地址 * 4 个整数 * 每个整数 4 个字节 = 5.44 * 10^39 个字节。之后只要按照安德烈亚斯的计算，你会得到更多......

话虽如此，IP V6 的想法是我们拥有的地址比我们需要使用的要多。所以我非常怀疑 2^128 附近的任何地方都会被分配多年。最多如果我们现在去 IP V6，我们将分配 IP V4 地址空间，仅此而已，尽管 IP 地址的数量每年都在增加，但不会增加那么多。

无论如何，您似乎不知道要存储什么，因为未定义架构，因此 Azure 表可能就是您想要的。主要是键/值。对于每个 IP 地址，您可以存储完全不同的属性。使用更新/插入/合并操作添加另一个属性/删除另一个属性真的很容易。但是，如果您希望将某种统一性应用于您的数据而不是使用 SQL。确实，您必须在发生更改时修改架构，但这将强制每一行（以及因此 IP 地址）具有相同的数据。否则，如果您有多个应用程序，很容易遗漏“必需”列/属性或拼写错误。但这真的取决于你想做什么。您更看重数据完整性还是更看重属性的灵活性？即使确实需要更改模式，也有一些命令可以从模式中添加/删除列。您更希望每个 IP 地址都存储相同的属性，或者每个 IP 地址都可以具有不同的属性。如果您不使用给定 IP 地址的大多数属性，我相信 Azure Table 方式可能比 SQL 方式占用更少的每个地址的存储空间。所以这一切都取决于你在寻找什么。

【讨论】：

我在 20 分钟前更新了这个问题，以反映我在理解 IPv6 方面的错误，但也感谢您更正它。我最有兴趣找到 N 个最近的邻居。如果这需要一个固定的模式，那就这样吧。基于动态 XML 的模式也很好。我想找到所有记录的对等点，并跳过所有稀疏数据。
我在加载页面时没有看到位更新，但这是正确的。这取决于您为每个邻居存储的内容。对于 N 最近邻，您可以使用包含所有地理信息的模式。如果您想为每个邻居存储不同的东西，请使用 Azure 表。我绝对认为您可能永远不需要存储 2^128 个键附近的任何地方。如果你在我们的一生中击中了完整的 2^40 个键，我会感到惊讶。
@cervo 当我说最近的邻居时，我指的不是地理位置。如果 PK 是 128 位“数字”，我想简单地定位链中下一个/上一个分配的数字。
在那种情况下，我不确定 Azure Table 有什么样的索引。但是您可能需要 SQL，因为您可以只对 IP 地址进行聚集索引，然后查询让我获得小于此地址的最大地址或大于此地址的最小地址，这是非常有效的。我知道 Azure/Big Table 索引键，因此您可以说 get (key) 和 put (key)，但我不确定它们对按顺序排列键有什么优化。需要更多的研究。
另外他们也可能不会按顺序分配每个地址。我不确定完整的 ip 6 计划。但他们可能会将序列不同部分的地址块分配给人们，然后人们将从这些块中分配。因此，一个地址可能是 IP 27，之后分配的下一个地址可能是 50,000,000,001。我不太确定地址上最近的邻居会得到什么。