HashMap替代内存高效的数据存储

Question

我目前有一个电子表格类型程序,它将数据保存在HashMaps的ArrayList中.当我告诉你这没有被证明是理想的时候,你无疑会感到震惊.开销似乎比数据本身多5倍的内存.

这个问题询问有效的集合库,答案是使用Google Collections. 我的跟进是" 哪一部分？ ".我一直在阅读文档,但不觉得它非常好地了解哪个类适合这个.(我也对其他图书馆或建议开放).

所以我正在寻找能够以最小的内存开销存储密集的电子表格类型数据的东西.

我知道H2和Derby等选项,但在这种情况下我不打算使用嵌入式数据库.

编辑:如果你建议图书馆,我也很感激你,如果你能指出我在这里适用的特定的一两节课.虽然Sun的文档通常包含哪些操作是O(1)的信息,哪些是O(N)等,但我在第三方库中没有看到太多,也没有真正描述哪些类最适合什么类.

Answer 1

有些列会有很多重复的值

无论您为收藏品选择何种解决方案,我都会立即向我建议使用FlyWeight模式.

Answer 2

Trove集合应特别关注占用的空间(我认为如果你坚持原始类型,它们也有定制的数据结构).看看这里.

否则你可以试试Apache系列 ..只需做你的基准测试!

在任何情况下,如果你有很多参考相同的元素尝试设计一些适合的模式(如flyweight)

Answer 3

Chronicle Map每个条目的开销可能少于 20 个字节（请参阅证明这一点的测试）。为了进行比较，java.util.HashMap 的开销从 37-42 字节-XX:+UseCompressedOops到 58-69 字节（没有压缩 oops ）不等（参考）。

此外，Chronicle Map 将键和值存储在堆外，因此它不存储 Object 标头，这些标头不计入上述 HashMap 的开销。Chronicle Map与Chronicle-Values 集成，这是一个用于生成接口的享元实现的库，这是 Brian Agnew在另一个答案中建议的模式。

Answer 4

所以我假设你有一张的地图Map<ColumnName,Column>，其中的列实际上类似于ArrayList<Object>。

几种可能性——

您完全确定内存有问题吗？如果您只是普遍担心大小，那么值得确认这确实是正在运行的程序中的一个问题。需要大量的行和映射来填满 JVM。
您可以使用集合中不同类型的地图来测试数据集。根据您的数据，您还可以使用可能有帮助的预设大小/负载系数组合来初始化地图。我过去曾尝试过这个问题，如果幸运的话，你可能会减少 30% 的内存。
如何将数据存储在单个类似矩阵的数据结构（现有的库实现或类似列表列表的包装器）中，并使用将列键映射到矩阵列的单个映射？