#c# #.net #parallel-processing #filesize #.net-framework-4.8
Вопрос:
У меня есть большой файл (около 8 ГБ) с тысячами записей (размер записи может достигать 1100 байт).
Мне нужно прочитать каждую запись и подумать о распараллеливании этого процесса путем разделения большого файла на несколько файлов меньшего размера.
Для чтения файлов я использую C# ( FileStream объект).
Насколько я понял, имеет смысл, чтобы каждый файл меньшего размера имел одинаковый размер.
Теперь вопрос в том, каков оптимальный размер для этих файлов меньшего размера или имеет ли вообще значение, если все они имеют размер 20 МБ или 50 МБ.
В ходе своих исследований я придумал разные размеры 20 МБ, 8 КБ, 10 МБ или 8 МБ, но всегда без дальнейших объяснений.
Обновить
Записи имеют фиксированный размер в байтах в зависимости от типа записи, который описан в первых 23 байтах каждой.
Итак, я читаю первые 23 байта, затем получаю информацию о том, сколько байтов мне нужно прочитать, пока запись не закончится. Благодаря этому мне удалось разделить файл по типу записи (34 файла).
Поскольку не каждый файл имеет одинаковый размер, различные задачи для файлов завершаются в разное время.
Комментарии:
1. О какой оптимизации мы говорим? Скорость? Память? IO? В чем ваше узкое место?
2. Эффективное распараллеливание ввода-вывода диска также может зависеть от того, где расположены файлы … так что ваша задача не так тривиальна, как может показаться. «Идеальный» размер также может зависеть даже от чистого металла (вид диска, его форматирование, файловая система,…).
3. В общем, ввод-вывод не сильно выигрывает от распараллеливания, и вам не нужно разделять большой файл на несколько меньших, вполне возможно читать один файл одновременно с правильной конфигурацией. Но вам нужен какой-то способ узнать, где начинается каждая запись, вы не можете просто разделить файл в произвольной позиции. Но первое, что вам следует сделать, — это составить профиль , чтобы иметь некоторое представление о реальных узких местах.
4. Интуитивно я бы не ожидал, что решение с разделением файлов будет быстрее, но было бы интересно услышать, каковы ваши фактические результаты.
5. Хм, значит, ваш вопрос не в том, как оптимизировать чтение большого файла объемом 8 ГБ и разделить его на несколько файлов меньшего размера. Очевидно, вы в порядке, если это займет целую вечность. Вы спрашиваете об оптимальном размере этих файлов меньшего размера, чтобы оптимизировать производительность последующей обработки этих файлов (характер обработки не описан). Мой ответ на этот вопрос таков: разделите большой файл на несколько небольших файлов, равных количеству имеющихся у вас аппаратных устройств хранения, а затем поместите каждый файл меньшего размера в отдельное хранилище. Если у вас есть только один, не разделяйте файл.