Чтение из одного большого файла и запись во многие (десятки, сотни или тысячи) файлов в Java?

Unix-подобная система обычно имеет ограничение на количество дескрипторов файлов, открытых в любой момент времени; в моем Linux, например, в настоящее время это 1024, хотя я мог бы изменить его в разумных пределах. Но для этих ограничений есть веские причины, так как открытые файлы являются бременем для системы.

Вы еще не ответили на мой вопрос о том, есть ли несколько вхождений одного и того же ключа во входных данных, а это означает, что может потребоваться объединение нескольких отдельных пакетов данных в каждый файл. Если это не так, ответ Пейса будет самым лучшим, что вы можете сделать, поскольку всю эту работу необходимо выполнить, и нет смысла создавать огромную администрацию вокруг такой простой последовательности событий.

Но если в вашем вводе есть несколько сообщений для одного и того же ключа, было бы эффективно держать открытыми большое количество файлов. Однако я бы посоветовал не пытаться держать все 6000 открытыми одновременно. Вместо этого я бы выбрал что-то вроде 500, открытых в порядке живой очереди; то есть вы открываете файлы для первых 500 (или около того) отдельных ключей сообщений, а затем просматриваете весь входной файл в поисках материала, который можно добавить в эти 500, а затем закрываете их все при нажатии EOF при вводе. Вам также нужно будет сохранить HashSet уже обработанных ключей, потому что затем вы снова перечитаете свой входной файл, обрабатывая следующую партию из 500 ключей, которые вы не уловили в первом раунде.

Обоснование: открытие и закрытие файла (обычно) является дорогостоящей операцией; вы НЕ хотите открывать и закрывать тысячи файлов более одного раза каждый, если можете помочь. Таким образом, вы держите как можно больше дескрипторов открытыми, и все они в конечном итоге заполняются за один проход через ваш ввод. С другой стороны, последовательная потоковая передача по одному входному файлу весьма эффективна, и даже если вам придется сделать 12 проходов по вашему входному файлу, время, необходимое для этого, будет практически незначительным по сравнению со временем, необходимым для открытия/закрытия 6000 других файлов. файлы.

Псевдокод:

processedSet = [ ]
keysWaiting = true
MAXFILE = 500
handlesMap = [ ]
while (keysWaiting) {
  keysWaiting = false
  open/rewind input file
  while (not EOF(input file)) {
    read message
    if (handlesMap.containsKey(messageKey)) {
       write data to handlesMap.get(messageKey)
    } else if (processedSet.contains(messageKey) {
       continue // already processed
    } else if (handlesMap.size < MAXFILE) {
       handlesMap.put(messageKey, new FileOutputStream(messageKey + ".dat")
       processedSet.add(messageKey)
       write data to handlesMap.get(messageKey)
    else
       keysWaiting = true
    endif
  }
  for all handlesMap.values() {
     close file handle
  }
  handlesMap.clear
}

Вам может не понадобиться хэш-карта. Ты мог бы просто...

1. Прочитать сообщение
2. Откройте новый файл в режиме добавления
3. Запишите сообщение в новый файл
4. Закройте новый файл

Не уверен, что это будет быстрее, потому что вы будете делать много открытий и закрытий.

Я бы порекомендовал какое-то интеллектуальное объединение: держите открытыми самые большие/наиболее часто используемые файлы для повышения производительности и закрывайте остальные для экономии ресурсов.

Если основной файл состоит в основном из записей типов 1–5, держите эти файлы открытыми до тех пор, пока они необходимы. Остальные можно открывать и закрывать по мере необходимости, чтобы не истощать ресурсы системы.

Я собираюсь сделать некоторые предположения по вашему вопросу:

• Каждое сообщение начинается с типа сообщения в виде поля фиксированного размера.
• У вас есть гетерогенный входной файл, содержащий смесь сообщений; вам нужны N однородных выходных файлов, где каждый выходной файл содержит только сообщения данного типа.

Подход, который приходит на ум, основан на функторах: вы создаете сопоставление типов сообщений с объектами, которые обрабатывают это конкретное сообщение. Ваш main() — это цикл диспетчеризации, который считывает фиксированный заголовок сообщения, находит соответствующий функтор на карте, а затем вызывает его.

Вы, вероятно, не сможете держать одновременно открытыми 6000 файлов (по одному на тип сообщения); большинство операционных систем имеют ограничение примерно в 1024 одновременно открытых файла (хотя в Linux вы можете изменить параметры ядра, которые контролируют это). Таким образом, это означает, что вы будете многократно открывать и закрывать файлы.

Вероятно, лучший подход — установить буфер с фиксированным количеством для каждого функтора, чтобы он открывался, записывался и закрывался, скажем, после 10 сообщений. Если ваши сообщения имеют максимальный размер 50 байт, то это 500 байт (10 x 50) x 6000, которые останутся в памяти в любой момент времени.

Я бы, вероятно, написал свои функторы для хранения массивов байтов фиксированного размера и создал универсальный класс функторов, который считывает N байтов за раз в этот массив:

public class MessageProcessor
{
    int _msgSize;                   // the number of bytes to read per message
    byte[] _buf = new byte[1024];   // bigger than I said, but it's only 6 Mb total
    int _curSize;                   // when this approaches _buf.length, write

Обычно в системе есть ограничения на количество открытых файлов, и в любом случае доступ к тысячам маленьких файлов в более или менее случайном порядке очень сильно затормозит вашу систему.

Попробуйте разбить большой файл на файл (или какую-то таблицу в памяти, если у вас есть память) отдельных сообщений и отсортировать их по типу сообщения. Как только это будет сделано, запишите сообщение в соответствующие файлы.

Поскольку вы выполняете много небольших операций записи во многие файлы, вы хотите свести к минимуму количество операций записи, особенно с учетом того, что простейший дизайн в значительной степени гарантирует, что каждая новая запись будет включать открытие/закрытие нового файла.

Вместо этого, почему бы не сопоставить каждый ключ с буфером? в конце запишите каждый буфер на диск. Или, если вы обеспокоены тем, что у вас будет слишком много памяти, вы можете структурировать свои буферы так, чтобы записывать каждые 1 КБ, или 5 КБ, или любые другие строки. например

public class HashLogger {

          private HashMap<String,MessageBuffer> logs;

          public void write(String messageKey, String message)
          {
              if (!logs.contains(messageKey)) { logs.put(messageKey, new MessageBuffer(messageKey); }
              logs.get(messageKey).write(message);
          }

         public void flush()
         {
             for (MessageBuffer buffer: logs.values())
             {
                buffer.flush();
             }
            // ...flush all the buffers when you're done...
         }

    private class MessageBuffer {
             private MessageBuffer(String name){ ... }
             void flush(){ .. something here to write to a file specified by name ... }
             void write(String message){
             //... something here to add to internal buffer, or StringBuilder, or whatever... 
             //... you could also have something here that flushes if the internal builder gets larger than N lines ...
     }
}

Вы даже можете создать отдельные регистраторы Log4j, которые можно настроить для использования буферизованного ведения журнала, я был бы удивлен, если бы более современные среды ведения журналов, такие как slf4j, также не поддерживали это.