There are several reasons that make MapReduce preferable over a parallel RDBMS for log processing. First, there is the sheer amount of data involved. For example, China Mobile gathers 5 – 8 TB of phone call records per day [4]. At Facebook [7], almost 6 TB of new log data is collected every day, with 1.7 PB of log data accumulated over time. Just formatting and loading that much data into a parallel RDBMS in a timely manner is a challenge. Second, the log records do not always follow the same schema. Developers often want the flexibility to add and drop attributes and the interpretation of a log record may also change over time. This makes the lack of a rigid schema in MapReduce a feature rather than a shortcoming. Third, all the log records within a time period are typically analyzed together, making simple scans preferable to index scans. Fourth, log processing can be very time consuming and therefore it is important to keep the analysis job going even in the event of failures. While most parallel RDBMSs have fault tolerance support, a query usually has to be restarted from scratch even if just one node in the cluster fails. In contrast, MapReduce deals more gracefully with failures and can redo only the part of the computation that was lost because of a failure. Last but not least, the Hadoop [8] implementation of MapReduce is freely available as open-source and runs well on inexpensive commodity hardware. For non-critical log data that is analyzed and eventually discarded, cost can be an important factor. In comparison, a commercial parallel RDBMS can cost hundreds of thousands of dollars, even on a moderate size cluster.