使用C的更大文件流#

扩展CasperOne的答案

简单地说,没有办法一次可靠地将100GB的文件放入内存。在32位机器上,根本没有足够的寻址空间。在64位机器中,有足够的寻址空间,但在实际将文件放入内存所需的时间内,您的用户会因沮丧而终止您的进程。

诀窍是逐步处理文件。基础系统。IO.Stream()类旨在处理不同数量的可变(可能是无限)流。它有几个Read方法,这些方法只会在流中前进特定数量的字节。您需要使用这些方法来划分流。

我不能提供更多信息,因为你的场景不够具体。你能给我们更多的细节,或者你的记录交付表,或者文件中的一些示例行吗?

更新

如果它们是固定长度的记录,那么系统。IO.Stream将正常工作。你甚至可以使用文件。打开()以访问底层Stream对象。流。Read有一个重载,请求从文件中读取的字节数。由于它们是固定长度的记录,因此这应该适用于您的场景。

只要你不调用ReadAllText(),而是使用Stream。Read()方法采用显式字节数组,内存不会成为问题。底层Stream类会注意不要将整个文件放入内存中(当然,除非你要求它:)。

你没有具体列出你需要克服的问题。一个文件可以是100GB,处理它不会有任何问题。

如果你必须处理文件 整体而言 那么这将需要一些创造性的编码,但如果你可以一次简单地处理文件的各个部分,那么移动到文件中你需要开始的位置,分块处理你需要处理的数据,然后关闭文件就相对容易了。

这里的更多信息肯定会有所帮助。

你目前遇到的主要问题是什么?要记住的一件大事是从流的角度思考,即尽可能在内存中保留最少的数据量。LINQ非常擅长处理序列(尽管有一些缓冲操作需要避免,比如OrderBy)。

例如, here's 一种高效处理大文件中简单记录的方法(注意迭代器块)。

为了对文件中的大数据执行多个聚合/分析,请考虑 Push LINQ 在……里面 MiscUtil .

你能为你正在思考的问题添加更多的背景吗?

扩展JaredPar的答案。

如果文件是二进制文件(即存储为4字节的整数、固定长度字符串等),则可以使用BinaryReader类。比提取n个字节然后试图查询它更容易。

另请注意,System上的读取方法。IO.Stream是一个非阻塞操作。若你们要求100个字节,它可能会返回小于100个字节的值,但仍然没有到达文件末尾。

BinaryReader。ReadBytes方法将一直阻塞,直到它读取到请求的字节数或文件末尾(以先到者为准)。

很好的合作伙伴:)

嘿,伙计们,我意识到这篇文章已经有一段时间没有被提及了,但我只是想发布一个能解决你们问题的网站。

http://thedeveloperpage.wordpress.com/c-articles/using-file-streams-to-write-any-size-file-introduction/

希望它能有所帮助!

-CJ