我需要存储一个大的（128位）PK。每个int都会有一些相应的列......现在没有定义架构......我希望将来架构灵活。 （我只需要保守的灵活性，例如不时添加新的列）
此时我并不太关心连接等的能力。我主要想选择随机PK并向上或向下搜索下10条记录。由于搜索中可能存在大量空白区域，因此向上和向下搜索的成本可能会有所不同。
处理此请求的最佳技术是什么？我对能为我省钱（每笔交易）和存储空间的东西感兴趣。我也对表现感兴趣。
你推荐什么？
更新
好的，这是为了什么？我想为IPv6地址创建数据历史记录。当然这将是一个非常稀疏的表...但我确实需要跟踪有关IP的某些事情。
答案 0 :(得分：3)
为了澄清，我认为你需要一个128位的密钥（不是2 ^ 128位）。
我将此作为关于Db键类型选择的问题，我不确定Azure角度有什么后果。 AFAIK它建立在MS-SQL之上。
128位或16字节与Guid（UniqueIdentifier）的大小相同，但我认为您不想使用它。虽然有人支持它作为关键。
直接选择就像二进制（16），但我不知道它是多么适合作为PK。
您可以将其编码为char（32）十六进制字符串，但这并不过分。
对于实用性估算，关键因素是您的数据是多么稀疏或更好：您希望存储多少个地址？
答案 1 :(得分：1)
首先，你在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地址，您可以存储完全不同的属性。并且使用update / insert / merge操作添加另一个属性/删除另一个属性非常容易。但是，如果您希望对数据应用一些统一性而不是使用SQL。确实，您必须在发生更改时修改架构，但这将强制每行（以及IP地址）具有相同的数据。否则，如果您有多个应用程序，很容易省略“必需”列/属性或拼错它们。但这真的取决于你想做什么。您更重视数据完整性还是重视属性的灵活性？即使需要更改架构，也有一些命令可以从架构中添加/删除列。您希望每个IP地址存储相同的属性，或者每个IP地址都具有不同的属性。我相信如果您没有使用给定IP地址的大部分属性，Azure Table方式可能比SQL方式占用更少的每个地址存储空间。所以这一切都取决于你在寻找什么。
答案 2 :(得分：1)
Windows Azure Tables将是我的推荐，但是只定义了一个排序顺序，因此很难向前和向后搜索。您可能最终必须按正常顺序存储每个键两次，然后反转（0xFFF ... F - 键）以有效支持两个扫描方向。