有一个二进制数组，此数组中的元素数量大约为10 ^ 20。
＆＃34;的数量＆＃34;在数组中大约是10 ^ 10，这些数字是随机分布的。
生成并保存数据后，不会对其进行编辑：它将在整个生命周期内保持只读模式。
保存此数据后，将收到请求。每个请求都包含数组的索引，响应应该是该特定索引中的值。这些请求的索引不是有序的（它们可能是随机的）。
问题是：如何对此信息保存空间进行编码，同时在提供请求时效果良好？
到目前为止，我的想法是：
为每个＆＃34;＆＃34;提供一系列索引。所以，我将有一个10 ^ 10个元素的数组，包含范围内的索引：0 - 10 ^ 20。也许不是最好的压缩方法，但它很容易解码。
压缩的最佳解决方案：枚举每个组合（从一组10 ^ 20个可用数字中选择10 ^ 10个数字），然后，数据只是＆＃34; id＆＃34;这个枚举...但是，我想这可能是一个解码的问题。
答案 0 :(得分：1)
查找“稀疏数组”。如果访问速度很重要，一个好的解决方案是索引的哈希表。您应该分配大约2倍的空间，需要180 GB的表。访问时间为O（1）。
你可能只有一个90 GB的表并对索引进行二进制搜索。如果你对这个速度感到满意，访问时间将是O（log n）。
您可以更紧密地打包索引，小于84 GB，以最大限度地减少单表方法的大小。
您可以将其分解为多个表格。例如。如果你有八个表，每个表代表索引可能的高三位，那么这些表将占用80 GB。
你可以进一步分解。例如。如果你有2048个表，每个表代表索引的高11位，那么总数将是70 GB，加上一些非常小的数量用于指向子表的指针。
更进一步，对于524288表，每个条目可以为60 GB做六个字节，加上表开销表。相比之下，这仍然很小，只有几兆字节。
256的下一个倍数应该仍然是胜利。有1.34亿个子表，你可以将它降低到50 GB，加上表格表不到1 GB。所以不到51 GB。然后，您可以将表格保存在内存中，并将子表格加载到内存中以进行每次二进制搜索。你可以在内存中拥有一个子表缓存，在空间不足时丢弃旧表。每个子表平均只有75个条目。然后二元搜索大约七步，经过一步找到子表。假设您没有64 GB的RAM，大部分时间都花在将子表放入内存中。然后，也许你这样做。