Often times I think it is just good practice to keep larger databases inside a database (e.g. Postgres). I don't use anything too much larger than (nrow * ncol) ncell = 10M, which is pretty small; but I often find I want R to create and hold memory intensive graphs only while I query from multiple databases. In the future of 32 GB laptops, some of these types of memory problems will disappear. But the allure of using a database to hold the data and then using R's memory for the resulting query results and graphs still may be useful. Some advantages are:

(1)数据一直加载在数据库中。当重新打开笔记本电脑时，只需在pgadmin中重新连接所需的数据库。

(2) R的确可以比SQL做更多漂亮的统计和绘图操作。但是我认为SQL比R更适合于查询大量的数据。

# Looking at Voter/Registrant Age by Decade

library(RPostgreSQL);library(lattice)

con <- dbConnect(PostgreSQL(), user= "postgres", password="password",
                 port="2345", host="localhost", dbname="WC2014_08_01_2014")

Decade_BD_1980_42 <- dbGetQuery(con,"Select PrecinctID,Count(PrecinctID),extract(DECADE from Birthdate) from voterdb where extract(DECADE from Birthdate)::numeric > 198 and PrecinctID in (Select * from LD42) Group By PrecinctID,date_part Order by Count DESC;")

Decade_RD_1980_42 <- dbGetQuery(con,"Select PrecinctID,Count(PrecinctID),extract(DECADE from RegistrationDate) from voterdb where extract(DECADE from RegistrationDate)::numeric > 198 and PrecinctID in (Select * from LD42) Group By PrecinctID,date_part Order by Count DESC;")

with(Decade_BD_1980_42,(barchart(~count | as.factor(precinctid))));
mtext("42LD Birthdays later than 1980 by Precinct",side=1,line=0)

with(Decade_RD_1980_42,(barchart(~count | as.factor(precinctid))));
mtext("42LD Registration Dates later than 1980 by Precinct",side=1,line=0)

而不是传统的阅读。我觉得fread是一个更快的函数。 指定额外的属性，如只选择所需的列，指定colclasses和字符串作为因素，将减少导入文件的时间。

data_frame <- fread("filename.csv",sep=",",header=FALSE,stringsAsFactors=FALSE,select=c(1,4,5,6,7),colClasses=c("as.numeric","as.character","as.numeric","as.Date","as.Factor"))

我想以最简单的形式贡献基于spark的解决方案:

# Test Data ---------------------------------------------------------------

set.seed(123)
bigdf <-
    data.frame(
        dim = sample(letters, replace = T, 4e7),
        fact1 = rnorm(4e7),
        fact2 = rnorm(4e7, 20, 50)
    )
tmp_csv <- fs::file_temp(pattern = "big_df", ext = ".csv")
readr::write_csv(x = bigdf, file = tmp_csv)

# Spark -------------------------------------------------------------------

# Installing if needed
# sparklyr::spark_available_versions()
# sparklyr::spark_install()

library("sparklyr")
sc <- spark_connect(master = "local")

# Uploading CSV
system.time(tbl_big_df <- spark_read_csv(sc = sc, path = tmp_csv))

Spark生成了相当不错的结果:

>> system.time(tbl_big_df <- spark_read_csv(sc = sc, path = tmp_csv))
   user  system elapsed 
  0.278   0.034  11.747 

这是在32GB内存的MacBook Pro上测试的。

讲话

Spark，通常不应该能够“赢得”针对速度优化的软件包。尽管如此，我还是想用Spark给出一个答案:

对于一些评论和回答，如果流程无法工作，使用Spark可能是一个可行的替代方案 从长远来看，将尽可能多的数据敲入data.frame可能会在以后出现问题，因为在该对象上尝试其他操作并达到体系结构的性能极限

我认为对于这样的问题，任务是处理1e7或更多行，应该考虑Spark。即使有可能将这些数据“锤击”到单个数据框架中，但这感觉还是不对。在部署模型时，该对象可能难以使用并产生问题，等等。

上面这些我都试过了，[1]做得最好。我只有8gb的内存

循环20个文件，每个5gb, 7列:

read_fwf(arquivos[i],col_types = "ccccccc",fwf_cols(cnpj = c(4,17), nome = c(19,168), cpf = c(169,183), fantasia = c(169,223), sit.cadastral = c(224,225), dt.sitcadastral = c(226,233), cnae = c(376,382)))

一开始我没有看到这个问题，几天后我问了一个类似的问题。我将记下我之前的问题，但我认为我应该在这里添加一个答案，以解释我如何使用sqldf()来做到这一点。

关于将2GB或更多的文本数据导入R数据帧的最佳方法，已经有了一些讨论。昨天我写了一篇关于使用sqldf()将数据导入SQLite作为暂存区，然后将它从SQLite吸到r的博客文章，这对我来说真的很好。我能够在不到5分钟的时间内提取2GB(3列，40mm行)的数据。相比之下，read.csv命令运行了一整夜，始终没有完成。

下面是我的测试代码:

设置测试数据:

bigdf <- data.frame(dim=sample(letters, replace=T, 4e7), fact1=rnorm(4e7), fact2=rnorm(4e7, 20, 50))
write.csv(bigdf, 'bigdf.csv', quote = F)

在运行以下导入例程之前，我重新启动R:

library(sqldf)
f <- file("bigdf.csv")
system.time(bigdf <- sqldf("select * from f", dbname = tempfile(), file.format = list(header = T, row.names = F)))

我让下面这行写了一整晚，但始终没有写完:

system.time(big.df <- read.csv('bigdf.csv'))

另一种选择是使用vroom包。现在在CRAN。 Vroom不加载整个文件，它索引每条记录所在的位置，并在稍后使用它时读取。

只按使用付费。

请参阅vroom介绍，开始使用vroom和vroom基准。

基本的概述是，对一个大文件的初始读取将会快得多，而对数据的后续修改可能会稍微慢一些。所以根据你的用途，这可能是最好的选择。

查看下面vroom基准测试的简化示例，关键部分是超快的读取时间，但稍微播种操作，如聚合等。

package                 read    print   sample   filter  aggregate   total
read.delim              1m      21.5s   1ms      315ms   764ms       1m 22.6s
readr                   33.1s   90ms    2ms      202ms   825ms       34.2s
data.table              15.7s   13ms    1ms      129ms   394ms       16.3s
vroom (altrep) dplyr    1.7s    89ms    1.7s     1.3s    1.9s        6.7s