1

큰 로그 파일 (정보의 시작 부분을 표시)에 제목이 있고 그 다음 정보가 다음과 같습니다.이 파일은 무작위로 전체 파일에 걸쳐 있습니다. 정보는 로그 파일의 어느 위치에서나 발생할 수 있습니다). 또한 부모 자식 계층도 있습니다. 구문 분석하고 섹션/제목의 시작 패턴을 식별하기 위해 작성된 정규 표현식을 기반으로이 로그의 정보를 처리해야하므로 따라야 할 정보를 처리해야합니다. 여기의 문제는 모든 정규 표현식과 일치해야합니다. 로그 파일의 각 행에 대한 섹션을 작성하여 어떤 섹션이 트리거되는지 판별하십시오. 이 접근법은 로그에서 다음에 오는 것이 무엇인지에 대한 지능적인 아이디어가 없기 때문에 매우 느리며 문제가 발생합니다. 계층이있을 때 증폭됩니다. 파일을 인덱싱하여 접근 방식을 생각했습니다. (분할 및 정복)을 반복하여 여러 액터 (스칼라)에 할당하고 각 행을 모든 정규 표현식 (섹션의 시작 부분을 나타냄)과 비교할 수 있습니다. 접근 방법이 얼마나 효율적인지 알고 싶습니다. 성능 향상을위한 더 많은 인풋을 원합니다. 여기에 로그 파일이 나타날 수있는 패턴이 있습니다 :거대한 로그를 효율적으로 구문 분석

Section1 
-------------- 
Info for section1 
.. 
... 
.... 
. 
. 
Section2 
-------------- 
Info for section2 
.. 
... 
.... 
. 
. 
Section3 
================= 
Info for section3 

Child1 of section3 
-------------- 
Info for child of section3 

Child2 of section3 
---------------- 
Info for child of section3 

Child1 of child2 which is child of section3 
......................... 
Info for child1 of child2 which is child of section3 

Section1 
--------------  //Section1 reappears 
Info for section1 
.. 
... 
.... 
. 
. 

답변

-1

파일 형식을 변경해야합니다. 이것을 RDBMS 또는 MongoDB에 구조화 된 데이터로 저장하는 것이 가장 쉬운 해결책이지만, 자체 로그 형식을 사용하려면 각 청크의 시작과 끝을 알 수 있도록 구조화해야하며, 하위 번호는 정규식을 사용할 필요가 없도록 구조화되어 있습니다.

가능한 해결책은 다음과 같습니다. 각각의 개별 청크는 JSON 객체이며 자체 행에 저장됩니다. 파일의 행은 다음과 같이 표시 될 수 있습니다.

{"section": "1", "path": "/", "info": "Info for section1\nNext Line of info\nAnd so on..."} 
{"section": "3", "path": "/child2/child1", "info": "Info for child1 of child2 which is child of section3"} 
+0

제한 사항은 원시 로그이며이를 재구성 할 수 없다는 것입니다. 또한 파일이 거대하면 읽고 다시 구조화 한 다음 ** 프로세스/광산 ** 데이터를 다시 읽음으로써 그 파일을 읽으면 실제 속도가 느려집니다. –

+0

내가 가지고있는 유일한 다른 생각은 모든 정규식을'Section (\ d +)'와 같은 것으로 일반화하려고 시도하는 것입니다. 현재 시스템에서 청크의 끝을 표시하는 것은 무엇입니까? 새로운 것의 시작에 불과합니까? – wingedsubmariner

+0

새로운 정규식이나 정규식 정규식을 정의 할 수 있지만 정규 표현식은 선택 사항이며 보존해야합니다. –

관련 문제