R数据框的实际限制

Posted 2023-04-18

【中文标题】R数据框的实际限制

【英文标题】：Practical limits of R data frame

【发布时间】：2011-03-08 14:24:46

【问题描述】：

我一直在阅读有关 read.table 对大型数据文件的效率不高的信息。还有 R 是如何不适合大型数据集的。所以我想知道在哪里可以找到实际限制是什么以及任何性能图表（1）读取各种大小的数据（2）使用不同大小的数据。

实际上，我想知道性能何时下降以及何时遇到障碍。此外，与 C++/MATLAB 或其他语言的任何比较都会非常有帮助。最后，如果对 Rcpp 和 RInside 有什么特别的性能对比，那就太好了！

【问题讨论】：

high performance task view 几乎肯定会回答其中一些问题。

Rcpp 是一个 C++ 库，它封装了 R C API，RInside 提供了从 C++ 代码调用 R 的功能。即，它们都受 R 约束。

***.com/questions/1727772/…

【参考方案1】：

R 适用于大型数据集，但您可能需要根据入门教科书的内容改变您的工作方式。我在Big Data for R 上发表了一篇文章，它处理了一个 30 GB 的数据集，您可能会发现它对启发很有用。

通常的入门信息来源是High-Performance Computing Task View 和R-SIG HPC 的R-SIG HPC 邮件列表。

您必须解决的主要限制是将向量长度限制为 2^31-1 个元素的历史限制，如果 R 不将矩阵存储为向量，这不会那么糟糕。 （限制是为了与某些 BLAS 库兼容。）

我们会定期使用 R 分析数百万客户的电信呼叫数据记录和营销数据库，如果您有兴趣，我们很乐意多谈。

【讨论】：

你有关于你使用 R 处理多少数据以及它比 C++ 类语言慢多少的统计数据吗？ Thnx - 埃贡

@Egon：我的背景是，我对任何数据分析问题的第一反应都是启动文本编辑器和 Fortran 编译器。但是这些天来，我发现分析中的限制因素更多的是我找出正确的方法并将其转化为代码的时间。为此，R 对我来说效率更高。当然，在使用 R 时我必须仔细考虑性能，但实际上你必须使用已编译的代码。我确实有一些我们已经编译的元素，但它们相对较少，而且它们几乎都是首先在 R 中设计和测试的。这就是 R 更快的原因。

【参考方案2】：

物理限制源于对向量使用 32 位索引。因此，最多允许 2^31 - 1 的向量。矩阵是有维度的向量，所以nrow(mat)和ncol(mat)的乘积必须在2^31 - 1之间。数据框和列表是通用向量，所以每个组件可以取2^31 - 1个条目，对于数据框意味着您可以拥有那么多行 和 列。对于列表，您可以有 2^31 - 1 个组件，每个组件有 2^31 - 1 个元素。本文摘自 Duncan Murdoch 最近的 posting 对 R-Help 上的 Q 的回复

现在，所有内容都必须适合标准 R 的 RAM，因此这可能是一个更紧迫的限制，但其他人提到的 High-Performance Computing 任务视图包含可以规避内存中问题的包的详细信息。

【讨论】：

请注意，2^31 - 1 个元素的限制仅适用于 R 2.x.y。在 R 3.x.y 中，限制更高（请参阅 cran.r-project.org/doc/manuals/R-ints.html#Long-vectors）。

【参考方案3】：

1) R 导入/导出手册应该是有关导入数据问题的第一站 - 有很多选项，适合您的选项可能非常具体。

http://cran.r-project.org/doc/manuals/R-data.html

read.table 如果使用提供给它的选项，特别是colClasses、comment.char 和nrows，则特别显着提高了性能 - 这是因为必须从数据本身推断出这些信息，这可以代价高昂。

2) data.frame 或列表中的任何向量、矩阵、数组、列的长度（元素总数）都有特定限制。这是由于在后台使用了 32 位索引，对于 32 位和 64 位 R 也是如此。数字是 2^31 - 1。这是 data.frame 的最大行数，但是它是如此之大，在您开始收集其中几个之前，您甚至更有可能耗尽单个向量的内存。

请参阅help(Memory-limits) 和help(Memory) 了解详情。

该长度的单个向量将占用许多 GB 的内存（取决于每个向量的类型和存储模式 - 数字为 17.1），因此除非您真的在推动事情，否则它不太可能成为适当的限制。如果您确实需要将内容推送到可用系统内存之外（这里必须使用 64 位），那么导入/导出手册中讨论的标准数据库技术或内存映射文件选项（如 ff 包）是值得的考虑。 CRAN 任务视图高性能计算是这方面的一个很好的资源。

最后，如果您有大量 RAM（16Gb 或更多）并且需要 64 位索引，它可能会出现在 R 的未来版本中。http://www.mail-archive.com/[e-mail]/msg92035.html

此外，Ross Ihaka 在论文和演讲中讨论了类似 R 语言的一些历史决策和未来方向： http://www.stat.auckland.ac.nz/~ihaka/?Papers_and_Talks

【参考方案4】：

我只能回答关于read.table 的问题，因为我没有任何大型数据集的经验。如果您不提供 colClasses 参数，read.table 的性能会很差。没有它，read.table 默认为 NA 并尝试猜测每一列的类别，这可能会很慢，尤其是当您有很多列时。

【参考方案5】：

在读取大型 csv 文件时x GB <=> y.1e6 rows 我认为data.table::fread（从版本 1.8.7 开始）是最快的替代方案，您可以使用它来完成install.packages("data.table", repos="http://R-Forge.R-project.org")

您通常会获得 5 到 10 的系数（并且所有 sep、row.names 等都由函数本身处理）。如果您有很多文件和一台足够好的计算机（几个内核），我建议使用parallel 包（作为 R.2.14 的一部分）为每个内核加载一个文件。

上次我在使用 read.csv 的单线程加载和使用 fread 的 4 核上的多线程加载之间执行此操作，我从 5 分钟缩短到 20 秒