Что лучший способ состоит в том, чтобы считать и проанализировать файл крупного текста по сети?
8 ответов
При чтении последовательного файла, Вы хотите считать его в линию за линией по сети. Вам нужен метод передачи, способный к потоковой передаче. Необходимо будет рассмотреть IO потоковая передача технологии для понимания этого.
Большие операции IO как это не извлекут выгоду очень многопоточностью, так как можно, вероятно, обработать объекты с такой скоростью, как можно считать их по сети.
Ваша другая большая опция состоит в том, чтобы поместить синтаксический анализатор журнала на сервер и загрузить результаты.
Самый легкий способ рассмотреть Вас уже копирует файл, должен был бы сжать его перед копированием и распаковкой, после того как копирование завершено. Вы получите огромные усиления, сжимающие текстовые файлы, потому что алгоритмы zip обычно работают очень хорошо над ними. Также Ваша существующая логика синтаксического анализа могла быть сохранена в целости вместо того, чтобы иметь необходимость сцепить его до средства чтения текста удаленной сети.
Недостаток этого метода - то, что Вы не сможете получить линию за линией обновления очень эффективно, которые являются хорошей вещью иметь для синтаксического анализатора журнала.
Я предполагаю, что это зависит от того, насколько "удаленный" это. 100 МБ на 100 МБ, LAN была бы приблизительно 8 secs... это к гигабиту, и у Вас будет она приблизительно через 1 секунду. 50$ * 2 для карт и 100$ для переключателя были бы очень дешевым обновлением, которое Вы могли сделать.
Но, принимая это еще дальше, чем который, необходимо смочь открыть его только с режимом чтения (поскольку Вы читаете его при копировании его). SMB/CIFS поддерживает чтение блока файла, таким образом, необходимо передавать файл потоком в той точке (конечно, Вы на самом деле не сказали, как Вы получали доступ к файлу - я просто принимаю SMB).
Многопоточность не поможет, поскольку Вы будете диском или сетью, связанной так или иначе.
Более оптимальный вариант, с точки зрения производительности, будет для выполнения парсинга в удаленном сервере. Кроме исключительных обстоятельств скорость Вашей сети всегда будет узким местом, таким образом ограничивая объем данных, который Вы отправляете по своей сети, собирается значительно улучшить производительность.
Это - одна из причин, что столько баз данных использует хранимые процедуры, которые выполняются в конце сервера.
Улучшения парсинга скорости (если таковые имеются) с помощью многопоточности будут затопляемыми сравнительной скоростью Вашей сетевой передачи.
Если Вы стремитесь передавать свои файлы прежде, чем проанализировать их, возможность, которую Вы могли рассмотреть, является использованием непрерывного сжатия при выполнении передачи файлов. Существуют, например, sftp серверы, доступные, который выполнит сжатие на лету. В местном конце Вы могли использовать что-то как libcurl, чтобы сделать сторону клиента передачи, которая также поддерживает непрерывную распаковку.
Используйте сжатие для передачи.
Если Ваш парсинг действительно замедляет Вас, и у Вас есть несколько процессоров, можно разбить задание парсинга, просто необходимо сделать это умным способом - имеют детерминированный алгоритм, для которого рабочие ответственны за контакт с неполными записями. Принятие Вас может решить, что строка является частью середины записи, например, Вы могли повредить файл в сегменты N/M, каждый ответственный за строки M; когда одно из заданий решает, что его запись не закончена, оно просто должно продолжать читать, пока оно не достигает конца записи. Когда одно из заданий решает, что читает запись, для которой оно не имеет начала, оно должно пропустить запись.
Если можно скопировать файл, можно считать его. Таким образом, нет никакой потребности скопировать его во-первых.
Править: используйте класс FileStream, чтобы иметь больше контроля над режимами доступа и режимами совместного использования.
new FileStream("logfile", FileMode.Open, FileAccess.Read, FileShare.ReadWrite)
должен добиться цели.
Я использовал SharpZipLib для сжатия больших файлов прежде, чем передать их по Интернету. Таким образом, это - одна опция.
Другая идея для 1) состояла бы в том, чтобы создать блок, который работает на удаленной машине и делает парсинг там. Вы могли получить доступ к блоку от локальной машины с помощью дистанционной работы.NET. Удаленный блок должен был бы быть службой Windows или быть размещен в IIS. Это позволило бы Вам сохранять свои копии файлов журнала на той же машине, и в теории потребуется меньше времени для обработки их.