我想存储数百万条如下所示的数据：
key，value
key是（0到5,000,000）范围内的整数;所有价值观都是独特的
value是无符号的int16值（0到65535）
关键是在获取至少数量的磁盘空间时存储数据，然后能够查询数据。你能想到任何有用的数据存储算法/智能方案吗？
万一重要，我使用Linux。
答案 0 :(得分：3)
一个选项是，如果键值不是重要数据，而是仅使用平面文件位数（带有描述性标题）的索引数据。每16位是一个值，第n个值将是标题末尾的（n - 1）* 16位。
此外，如果键值很重要，大约10MB的设置平面文件将允许存储整个键空间而不存储实际键。 （n-1）* 16偏移处的16位将是该键的值。
这可能是空间密集度最低的存储方法，因为它只是字面上需要的数据。 （但是，如果你只对10万个值感兴趣而且有一个500万的密钥，那么你最终会浪费大量的空间，而实际的密钥，值寻址系统则不会存在。所以这种方法只有为一组紧密分组的值或许多数字（超过200万标记）实现最小磁盘存储。
答案 1 :(得分：3)
您打算如何使用存储数据？随机或顺序访问？对于顺序访问，您可以使用任何归档算法，例如， LZMA。随机访问不会给你留下很大的改进空间。
你能看到这些数据的模式吗？例如如果相邻键/值之间的差异通常小，则只能存储打包差异。以及其他数百万种可能的方法。 [编辑]您也可以检查网络通信中用于数据压缩的技术
[EDIT1]，您可以查看此Google代码Integer Array Compression项目
答案 2 :(得分：2)
这取决于操作和数据。我首先建议“只使用数据库”（一个简单的键值存储，如BDB / EhCache [read：Key Value store]，例如： - ）
如果使用了所有密钥，Mimisbrunnr也会有一个很好的答案。
如果密钥接近常量/只读且仅使用相对较小的密钥，请考虑使用（基于磁盘）{ {3}}数据结构（非常类似于基于数组的堆;堆不必是基于数组的）。罗伯特·塞奇威克（Robert Sedgewick）在80年代后期出版了一本很好的书，其中有一个非常精益实现，但我忘记了这个名字。与具有较小比例的使用密钥的平坦索引相比，堆将更有益，并且在满负载时将具有更差的存储要求。
（如果是抽象的，可以切换使用的方法和/或可以使用带有索引/顺序叶子节点值的混合堆[以及霍夫曼编码或诸如此类]，但只是增加了更多的复杂性。保持简单......因此首先建议现有的键/值存储; - ）
快乐的编码。
答案 3 :(得分：0)
您是否考虑过使用专为移动设备（如SQL Server Compact）或其他类似数据库设计的数据库？它们在磁盘上占用的空间很小，同时仍然提供您所需的全部搜索功能。
紧凑型数据库引擎的另一个例子是KeyDB for linux：