我目前正在研究一个需要使用千兆字节的科学数据集的项目。数据集的形式是非常大的数组（30,000个元素）的整数和浮点数。这里的问题是它们太大，太适合内存，所以我需要磁盘解决方案来存储和使用它们。为了使这个问题变得更加有趣，我仅限于使用32位体系结构（因为这是为了工作），我需要尝试最大限度地提高此解决方案的性能。在磁盘C++上存储科学数据集的最佳方法
到目前为止，我已经和HDF5一起工作了，但是我发现它工作起来有点复杂。所以，我认为下一个最好的尝试是尝试一个NoSQL数据库，但是我找不到将数组存储在数据库中的一种好方法，并且不会将它们转换为字符数组并将它们存储起来，这导致了很多糟糕的指针头痛。
所以，我想知道你们的建议。也许你在使用HDF5时不那么痛苦，同时最大限度地提高性能。或者，也许你知道一个适用于存储这种类型数据的NoSQL数据库。或者，也许我正朝着这个完全错误的方向前进，而你想对我产生一些感觉。
无论如何，我会很感激的智慧任何话，你们可以给我:)
假设你的数据集还真是够大功德（例如，而不是30000元，一30,000x30,000阵列双打），你可能要考虑STXXL。它提供了旨在（并在很大程度上成功）模仿C++标准库中的集合的接口，但是它们打算处理的数据太大而不适合内存。
是的，我的数据集是这个口径（30,000 * 1,000,000），应该指定，我的坏:)在任何情况下，我已经尝试过STXXL事实上，但遇到bad_alloc错误，我明白当试图写入不存在的内存（我认为...）为了使我的需求更清晰一些，从stxxl的角度来看，我需要大约20个映射来保存整型键和int对数组和浮点数组作为值，我得到了在声明地图时出现错误的分配错误，但是只有在声明特定数字（17或18我相信）之后才有任何建议？ – Andrewziac
您的问题似乎只是图书馆的滥用，也许如果您分享一些代码，我们可能会帮助您检测到哪里出了问题。 – Havenard
对不起，这么晚回到你身边。实际上，我似乎已经解决了我的bad_alloc问题，但现在我真正的问题是获取boost :: noncopyable错误...使用此语句构造映射：'stxxl :: map
在你自己身上体会一些感觉，并使用HDF5等生产级库。所以你发现它太复杂了，但你有没有发现它的high-level APIs？
如果您不喜欢该答案，请尝试使用新兴阵列数据库之一，如SciDB,rasdaman或MonetDB。不过，我怀疑，如果你在HDF5中被阻止，你会在任何这些方面阻挠。
在我看来，和经验，如果你要在大量的科学数据集中工作很长时间，学习如何正确使用HDF5等工具是值得的。如果你拿起一个NoSQL数据库这样的工具，而这个数据库不是专为手头的任务而设计的，那么，尽管它最初可能会更容易使用，但最终（在很长时间之前是我的猜测）它将缺少你需要的功能或者想要，你会发现自己不得不围绕缺陷编程。
为工作选择合适的工具之一，并学习如何正确使用它。
感谢您的建议，但我猜错了一点，对不起hehe ...这不是说HDF5太复杂了，它是要充分优化它，它需要更多的工作（据我所知）。我可以将所有阵列添加到h5文件中，并且读取它很好，但速度不在那里。我知道在内存中安排数据的方法以及可用于提高性能的各种其他功能的方法，但我看到的方式是，如果我可以通过不太复杂的库获得类似或更好的性能，我将保存我自己从未来头疼 – Andrewziac
我一直在从事科学计算多年，我认为HDF5或NetCDF是一个很好的数据格式供您使用。它可以提供高效的并行读/写，这对于处理大数据很重要。
另一种解决方案是使用数组数据库，如SciDB，MonetDB或RasDaMan。但是，如果您尝试将HDF5数据加载到数组数据库中，那将会很痛苦。我曾尝试将HDF5数据加载到SciDB中，但它需要一系列数据转换。你需要知道你是否会经常查询数据。如果不经常，那么耗时的负载可能是不值得的。
您可能也有兴趣this paper。 它可以让你使用SQL直接查询HDF5数据。
30,000个元素可能没有（完全）适合Apple II的内存，但当然应该适合于任何现代和有能力的内存。 –
是的，你是正确的，但是数组对应于数据集中的一个元素，将会有数百万个这样的数组，所以它会更像30000 * 1,000,000，这将难以存储在内存中 – Andrewziac