问题标签 [on-disk]

初始问题：

我有以下问题：我正在使用 Java 加入 2 个 CSV。虽然我可以“流式传输”其中一个 CSV（读入、处理、逐行写出），但较小的一个驻留在内存中（HashMap准确地说是），因为我需要查找每一行的键大CSV，同时通过它。问题：如果“小 CSV”太大而无法保存在内存中，我会遇到 OutOfMem 错误。

虽然我知道我可以通过将两个 CSV 读入数据库并在那里执行连接来避免这些问题，但在我的应用程序中这样做是不可行的。是否有 Java 包装器（或某种其他类型的对象）允许我只将HashMap' 的键保留在内存中，并将其所有值放入磁盘上的临时文件中（以自我管理的方式）？

更新：

在ThomasKläger和JacobG的评论之后，我通过以下方式解决了这个问题：

使用 aHashMap来存储一行的键，以及使用RandomAccessFile's来存储该行的开始和结束位置.getFilePointer()。

在浏览大型 CSV 时，我现在使用HashMap来查找匹配行的位置.seek(pos)，并读取它们。

这是一个可行的解决方案，非常感谢。

我想知道是否有一个带有 Python 绑定的快速磁盘键值存储，它支持数百万次对单独键的读/写调用。我的问题涉及在一个非常大的语料库（维基百科）中计算单词共现，并不断更新共现计数。这涉及使用 64 位密钥和 64 位值读取和写入约 3 亿个值 70 次。

我还可以将我的数据表示为尺寸约为 2M x 2M 的上三角稀疏矩阵。

到目前为止，我已经尝试过：

• Redis（64GB RAM 不够大）
• TileDB SparseArray（无法添加到值）
• Sqlite（太慢了）
• LMDB（批量处理 3 亿次读/写事务需要多个小时才能执行）
• Zarr（基于坐标的更新非常慢）
• Scipy .npz（不能将矩阵保存在内存中以供添加部分使用）
• 带有memmapped坐标和数据的稀疏COO（添加矩阵时RAM使用量很大）

目前唯一运行良好的解决方案是 LMDB，但运行时间约为 12 天，这似乎不合理，因为我感觉我处理的数据不多。使用 .npz 将子矩阵（约 300M 值）保存到磁盘几乎是即时的。

有任何想法吗？

我正在阅读Cormen 等人的算法简介中的B-Tree主题。人。而且我在实际程序中实现伪代码的磁盘操作时遇到了困难。这可能是这种情况，因为我在这里不清楚对对象的描述。任何人都可以指导我如何进行。

以下为正文节选，介绍发展情况：

我们在伪代码中对磁盘操作进行建模，如下所示。设x是指向对象的指针。如果对象当前在计算机的主内存中，那么我们可以像往常一样引用对象的字段：key[x]例如。但是，如果 引用的对象x驻留在磁盘上，那么我们必须先执行将Disk-Read (x)对象读x入主存的操作，然后才能引用其字段。（我们假设如果x已经在主内存中，则Disk-Read (x)不需要磁盘访问；它是“无操作”。）类似地，该操作Disk-Write(x)用于保存对 object 字段所做的任何更改x。处理对象的典型模式如下：

所以很明显，如果x要在磁盘上存储一个对象，除非我们将它带入主存，否则我们无法引用它，但是我们如何x首先指向磁盘中的对象，这个是什么，我在实施时遇到了问题。

我无法理解如何在实际程序中实现这些磁盘操作。

创建一个空的 B 树

要构建 B 树T，我们首先使用B-Tree-Create创建一个空的根节点。该过程使用一个辅助过程Allocate-Node，它及时分配一个磁盘页面作为新节点使用O(1)。（我知道在堆上分配，但这里他们是在谈论直接在磁盘上分配吗？此外，如果x持有对分配在磁盘上的对象的引用，那么如果不将其带入主内存，我们就不可能按照前面的摘录处理它的属性）。我们可以假设由创建的节点Allocate-Node不需要Disk-Read，因为磁盘上还没有存储该节点的有用信息。（如果不看，怎么设置属性x？）

我知道如何在堆上分配并说使用fwrite()inC programming language将其写入磁盘，但是如何将链接合并到磁盘中？应该ftell()用于获取文件中对象的开始并相应地进行链接？

我不太明白如何优雅地将对象写入磁盘，保持链接结构。（ Aaron M. Tenenbaum 等人撰写的使用 C 和 C++ 的文本数据结构。仅以图形方式处理该主题，没有核心实现。而且我还没有学习正式的 DBMS 课程）

请指导我，如果可能的话。谢谢..

[注意我和这个问题一样，但建议的答案包含大量代码，没有任何文档或生动的评论，谷歌搜索这些东西会产生在主内存中维护的 B-tree（这不是它们的设计目的）。任何人都可以用一种更简单的编程语言（例如碎片整理等] [此外这里有一个关于该主题的视频讲座，但可惜没有实现的细节]C

为需要大量磁盘的 Kubernetes 作业/部署提供大型“临时”存储的好方法是什么？

我阅读了有关临时卷的信息，似乎最适合这种情况的是挂载emptyDir卷。我的问题是emptyDir卷/var默认安装在主机上（请参阅此处），并且我对/var分区的大小有硬性限制，因此我无法获得足够的空间来用作昂贵的磁盘 pod 的“临时”空间.

有没有办法更改安装临时存储的默认位置？

我在任何地方都找不到它。

emptyDir我在规范中找不到任何有用的选项。

我不想使用持久性卷声明，因为我不需要持久化任何东西。

我也不想将空目录挂载/var在主机之外的大分区中作为hostPath卷，因为这会滥用hostPath语义与我需要的不同的 s。（虽然这会起作用，但它似乎有点像黑客）。

还有其他可以采用的解决方案吗？