Hay quienes preguntan cómo cargar con R un csv de 8GB en un portátil de 4GB de RAM. La verdad, he leído respuestas la mar de extravagantes a este tipo de cuestiones: p.e., recomendar SQLite.
Yo recomendaría Scalable Strategies for Computing with Massive Data. Entre otras cosas, porque para eso lo escribieron sus autores: para que se lea. Y porque está cargado de razón y buenos consejos.
Una cosa con la que tropezará enseguida quien lo hojee es:
[…] R no está preparado para operar con estructuras de datos que ocupan más del 10-20% de la RAM del ordenador. Con datos que ocupan más del 50% es prácticamente imposible trabajar porque el el consumo adicional de memoria de cualquier transformación no trivial consume enseguida toda la RAM disponible. […] llamamos grande a un conjunto de datos si ocupa más del 20% de la RAM y masivo si ocupa más del 50%.
En realidad, los límites no son tan serios: ahora mismo, R está ocupando 17 de los 24GB de RAM de mi servidor y va como un tiro. Pero es un aviso para navegantes: a partir de cierto umbral, hay que olvidarse de read.table y demás. Alternativas, haylas. La más simple es conseguir (¿alquilándola?) una máquina más grande. Seguramente es la opción más barata si se tienen todos los factores en cuenta.
El artículo discute una estrategia basada en la combinación de bigmemory (y los paquetes relacionados) y foreach. Yo confieso no haber utilizado ninguno. Para paralelizar, con parallel me ha bastado (aunque igual cambio de parecer cuando me decidad, de una vez por todas, a montar un clúster). Y con data.table y un poco de cuidado, resuelvo casi todos mis problemas de espacio. Pero a algún maestrillo le puede gustar adoptar ese librillo.
Dicho lo cual, reitero que uno de mis proyectos más a corto para dejar solucionados de una vez por todas este tipo de problemas es comenzar a trabajar con Spark.