在C中持久化成员资格测试的大列表

每个项是17个32位整数的数组。我可能会为它们生成120位的唯一哈希

我有一个算法可以生成9731643264个这样的项目，我想看看其中有多少是独一无二的。我推测其中最多有1/36是独一无二的，但不能确定

在这种大小下，我无法在内存中真正做到这一点（因为我只有4个Gig），因此我需要一种方法来保存这些文件的列表，进行成员资格测试，并添加每个新文件（如果还没有）

我在Linux上使用C（gcc），因此如果解决方案可以在那里工作就好了

---

有什么想法吗？

这让我想起了多年前我在解决“骑士之旅”问题时遇到的一些问题。（这是一道数学题，现在已经解决了，但不是我解决的。）

即使是你的杂烩也帮不了什么忙。在几乎一个GUID大小的情况下，它们很容易在所有已知的宇宙中都是唯一的

仅将列表保存在磁盘上大约需要0.75 Terrabytes。4吉比特的内存或没有，你仍然需要一个巨大的磁盘来容纳它们。您需要两倍或更多的磁盘来执行我在下面讨论的排序/合并解决方案

如果您可以对列表进行排序，那么您可以一次只对列表中的一项进行排序，以查找彼此相邻的唯一副本。当然，对这么多数据进行排序需要一个自定义排序例程（您编写的），因为它是二进制的（转换为十六进制将使数据的大小加倍，但允许您使用标准例程）。虽然即使在那里，他们也可能会被这么多的数据窒息。因此，您可以回到自己的自定义例程

需要考虑的一些事情：

整理这么多的数据需要数周、数月甚至数年的时间。虽然您可以在内存中进行很好的堆排序或其他任何操作，但因为您只有这么多的磁盘空间，所以无论您在内存中执行什么操作，您都可能会对文件进行“气泡”排序

根据生成算法的不同，您可以生成“一个内存负载”的数据，对其进行排序，然后将其写入文件（已排序）中的磁盘。完成后，您只需“合并”所有这些单独排序的文件，这是一项容易得多的任务（即使有1000个文件，这仍然是一项相对容易的任务）

如果你的生成器可以告诉你关于你的数据的任何事情，那么就利用它为你带来好处。例如，在我的例子中，当我处理骑士的移动时，我知道我的输出值不断变大（因为我总是在每一个移动中添加一位），这一小小的知识让我能够以一些独特的方式优化排序。看看你的数据，看看你是否知道类似的事情

当然，缩小数据总是好的。例如，你说的是120散列，但它是可逆的吗？如果是，请对哈希进行排序，因为它较小。如果没有，哈希可能没有多大帮助（至少对我的排序解决方案是这样）

---

我对这类问题的机理很感兴趣，我很乐意就这一主题交换电子邮件，只是想提出一些想法和可能的解决方案。

如果您可以对输入数据进行一些限制，您的生活可能会轻松得多：即使假设只有120个有效位，大量重复值表明分布不均匀，因为对于给定的

10^10

:

2^120 = (2^10)^12 > (10^3)^12 = 10^36 >> 10^10

如果有连续的簇（而不是稀疏的、但重复的值），那么通过对范围而不是原子值进行操作可以获得很多

我要做的是：

• 用一批生成的值填充缓冲区
• 对内存中的缓冲区进行排序
• 将范围写入磁盘，即文件中的每个条目由一组连续值的起始值和结束值组成

---

然后，您需要合并各个文件，这可以在线完成-即当文件可用时-与基于堆栈的合并排序操作相同：为每个文件关联一个等于文件中范围数的计数器，并将每个新文件推送到堆栈上。当堆栈顶部的文件有一个大于或等于前一个文件的计数器时，将文件合并成一个新文件，计数器是合并文件中的范围数。

如果您对C++感到满意，请看一下，您是否已经使用了A？好，您在问题的类型上是正确的，我正在尝试解决17x17（）。我的120位哈希确实是可逆的。事实上，我可以通过更多的思考使它变小，这只是第一次近似。我的电子邮件是al3xgr@gmail.com发邮件给我你的，我可以给你更多的细节，我正在做。干杯，真棒，谢谢。考虑到我的数据，我认为34位就足够了，并且考虑到我每个独特的项目至少有36个副本（目标是看看是否有更多副本），这将使它降到29位。这是一个更好的目标数字。我不确定是否会有射程。