One of the problems with reading 50,000 records is that you run the risk of hitting other governors, such as the heap governor, which, although increased in an async context, can still be hit depending on the processing being performed. Take a look at the following contrived example to generate attachments on each Race Data record:

List<Attachment> attachments = new List<Attachment>(); 
for(RaceData__c raceData : 
     [select Id from RaceData__c limit 10000]) 
  attachments.add( 
    new Attachment(
       Name = 'Some Attachment', 
      ParentId = raceData.Id, 
      Body = Blob.valueOf('Some Text'.repeat(1000)))); 
insert attachments; 

If you try to execute the preceding code from an Execute Anonymous window, you will receive the following error, as the code quickly hits the 6 MB heap size limit:

System.LimitException: Apex heap size too large: 6022466  

The solution to this problem is to utilize what is known as SOQL FOR LOOP (as follows); this allows the record data to be returned to the Apex code in chunks of 200 records (a size set by the platform) so that not all the Attachment records will build up on the heap:

for(List<RaceData__c> raceDataChunk : 
       [select Id from RaceData__c limit 10000]) { 
  List<Attachment> attachments = new List<Attachment>(); 
  for(RaceData__c raceData : raceDataChunk) 
    attachments.add( 
      new Attachment( 
        Name = 'Some Attachment', 
        ParentId = raceData.Id, 
        Body = Blob.valueOf('Some Text'.repeat(1000)))); 
  insert attachments; 
} 

Once this code completes, it will have generated over 80 MB of attachment data in one execution context! Note that in doing so, the preceding code does technically break a bulkification rule, in that there is a DML statement contained within the outer chunking loop. For 10,000 records split over 200 record chunks, this will result in 50 chunks, and thus, this will consume 50 out of the available 150 DML statements. In this case, the end justifies the means, so this is just something to be mindful of.