我需要存储一个大的（128 位）PK。每个 int 都会有一些相应的列......现在没有定义模式......我希望未来的模式灵活。（我只需要保守的灵活性，例如不时添加新列）
在这一点上，我不太关心连接等的能力。我主要想选择一个随机的 PK 并向上或向下搜索到接下来的 10 条记录。由于搜索中可能存在大量空白，因此向上和向下搜索的成本可能会有所不同。
处理此请求的最佳技术是什么？我对可以为我省钱（每笔交易）和存储空间的东西感兴趣。我也对性能感兴趣。
你有什么建议吗？
更新
好的，那这是干什么用的？我想为 IPv6 地址创建数据历史记录。当然，这将是一个非常稀疏的表格……但我确实需要跟踪有关所见 IP 的某些事情。
为了澄清，我认为你需要一个 128 位的密钥（不是 2^128 位）。
我将此作为关于 Db Key 类型选择的问题，我不确定 Azure 角度会产生什么后果。AFAIK 它建立在 MS-SQL 之上。
128 位或 16 字节与 Guid (UniqueIdentifier) 的大小相同，但我认为您不想使用它。尽管支持将其用作密钥。
直接选择类似于 binary(16) 但我不知道它是否适合作为 PK。
您可以将其编码为 char(32) 十六进制字符串，不过分。
对于实用性估计，关键因素是您的数据有多稀疏，或者更好：您希望存储多少个地址？
首先，您在 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 方式占用更少的每个地址的存储空间。所以这一切都取决于你在寻找什么。
我建议使用 Windows Azure 表，但只定义了一种排序顺序，因此很难向前和向后搜索。您最终可能不得不将每个键存储两次，一次按正常顺序，一次反转（0xFFF...F - 键）以有效地支持两个扫描方向。