磁盘支持的 STL 容器类？ [关闭]答案

【问题标题】：Disk-backed STL container classes? [closed]磁盘支持的 STL 容器类？ [关闭]
【发布时间】：2010-09-14 01:13:17
【问题描述】：

我喜欢使用 STL 开发算法，但是，我经常遇到这个问题，即我的数据集对于堆来说太大了。

我一直在寻找 STL 容器和磁盘支持的算法的直接替代品，即存储在磁盘上而不是堆上的数据结构。

一位朋友最近将我指向stxxl。在我过多参与之前...是否还有其他可用的磁盘支持的 STL 替代品我应该考虑？

注意：我对持久性或嵌入式数据库不感兴趣。请不要提及 boost::serialization、POST++、关系模板库、Berkeley DB、sqlite 等。我知道这些项目并在适合我的目的时使用它们。

更新：有几个人提到了内存映射文件和使用自定义分配器，顺便说一句很好的建议，但我会把他们指向讨论 here，其中 David Abraham 建议磁盘需要自定义迭代器 -支持的容器。这意味着自定义分配器方法不太可能奏效。

【问题讨论】：

如果您的数据集对于堆来说太大，您应该考虑您的系统架构是否正确（例如，是否迁移到 64 位系统；这些现在比问题更常见问）。您还应该考虑 STL 是否是正确的方法；它可能对数据集大小做出了不适合您的假设。
@Donal 他可能没有保留正确的内存量。

标签： c++ algorithm data-structures stl on-disk

【解决方案1】：

我已经实现了一些非常相似的东西。实现迭代器是最具挑战性的。我使用 boost::iterator_facade 来实现迭代器。使用boost::iterator_facade，您可以轻松适应任何缓存在磁盘数据结构上的 STL 容器接口。

【讨论】：

我使用 Boost，但 iterator_facade 对我来说是新的。我得看看那个，谢谢分享。
愿意分享实现吗？
很遗憾，我无法共享该代码。但是，如果您有任何问题，我将非常乐意提供帮助。

【解决方案2】：

我从来没有做过这样的事情，但是通过编写一个使用内存映射文件来支持数据的自定义分配器，也许可以做你想做的事情。

请参阅boost::interprocesses 了解有关其易于使用的内存映射文件实现的文档，this Dr. Dobbs article 了解有关编写分配器的详细讨论，this IEEE Software column 了解问题描述和example code。

【讨论】：

我知道 DDJ 的文章，不错的文章。然而，Terpstra、Kuehl 和 Abraham 之间就 boost 的邮件列表进行了讨论，建议需要自定义迭代器来处理磁盘上的数据结构......这会排除自定义分配器方法。

【解决方案3】：

如果（如您所写）您对持久性不感兴趣，最简单的解决方案是增加堆大小并使用操作系统的虚拟内存设施。不适合计算机物理内存的堆部分最终将在磁盘上进行分页，从而为您提供所需的内容：对通常存储在磁盘上的数据进行正常的 STL 访问。操作系统将负责缓存物理内存中最常用的页面，并将不经常使用的页面逐出磁盘。您的代码将保持不变，您只需添加更多物理内存即可提高其性能。

要增加堆大小，请检查操作系统的参数，例如 Unix 系统上的 ulimit(1) 和 Windows XP 上的系统属性 - 高级 - 性能 - 高级 - 虚拟内存。如果您已达到 32 位 4GB 的限制，请考虑迁移到 64 位架构或将您的程序编译为 64 位。

【讨论】：

我是一名熟练的系统管理员，我已经考虑过您建议的方法。我有一台运行 unix 的 amd64 机器。我负担不起添加更多的物理内存。我的交换空间是 2GB，我的数据集是 42GB，我的硬盘是 1TB...
那么，增加交换空间怎么样？
当然，我考虑过重建我的服务器以适应这个项目。然而，这不是专用硬件，而是用于一般研究的机器。除此之外，最终合作者也需要运行代码，我认为要求他们重新构建机器是行不通的。

【解决方案4】：

我对这个主题了解不多，但也许可以为内存映射文件编写类似 STL 的接口？

edit：如果您尝试获取大文件的特定部分，则此方法可能适用。如果您尝试对整个文件执行某些操作，则在读取文件的未缓存部分时可能会产生大量页面错误。

【讨论】：

我已经考虑过这样做......但如果已经完成了一些有用的事情，我宁愿不自己写。
我很感激不想重新发明轮子。我不熟悉执行此操作的库；希望有人能推荐一个。
我相信 Boost.Interprocess 可以用来写入内存映射文件。不过还没有真正尝试过。