Эффективный шаблон для обработки файлов фиксированной ширины

Question

У меня есть случай, когда мне нужно прочитать плоский файл с почти 100000 логических записей. Каждая логическая запись состоит из nx128 символьных частей. т. е. тип A: 3x128, тип B: 4-5 X 128 и т. д., где максимально возможное n равно 6.

Приложение должно прочитать файл и обработать записи. Проблема в том, что 'n' может быть определена только тогда, когда мы читаем первые 52 символа каждого раздела nx128.

Не могли бы вы предложить какие-либо образцы дизайна, которые я могу использовать повторно, или какие-либо эффективные алгоритмы для этого?

Примечание: 1. Производительность является важным критерием, поскольку приложение должно обрабатывать тысячи файлов, как это каждый день. 2. Данные не разделены линиями. Это длинная строка, как узор

Answer 1

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

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

• Эффективная и производительная реализация будет опираться на способность предоставлять рабочему потоку указатели файлов и длину данных, с которыми должен работать рабочий. Проще говоря, ожидается, что рабочий поток фактически прочитает файл в режиме произвольного доступа, вместо того, чтобы мастер считывал (который является последовательным). Если вы не можете выполнить произвольный доступ, мало что можно сделать, чтобы оптимизировать шаблон мастер-работник.
• Создание новых рабочих потоков не рекомендуется. Используйте пул потоков. Это также означало бы, что вы можете ограничить количество дескрипторов открытых файлов в зависимости от размера пула.
• Поставить в очередь дальнейшие запросы для обработки диапазонов символов в случае исчерпания пула. Таким образом, мастер может продолжать выполнять свою работу, пока не будет прочитана последняя запись.
• Зависимости между записями потребуют от вас сериализации обработки записей. Если каждая запись может быть обработана в своем собственном потоке, не требуя предоставления результатов из других потоков, то вы не должны столкнуться с какими-либо трудностями при принятии этого подхода.

Answer 2

Если вы не можете изменить формат, вы должны обойти это.

Вы можете создать индекс для каждого файла, но вам придется прочитать его один раз, чтобы построить индекс (но это избавит от необходимости делать это более одного раза)