그리고 이 시퀀스를 한 번 거쳐야 한다면 그렇게 할 것입니다. 그러나 조금씩 앞으로 나아갈 때마다 반복해서 통과해야 합니다.
...
그리고 조각으로 가공한다면?
두 조각을 세고 각각 1GB라고 가정해 보겠습니다. 첫 번째 조각이 처리되고 다음 단계에서 두 번째 조각에서 "... 조금 앞으로 이동"을 추가합니다. 동시에 첫 번째 조각의 시작 부분을 잘라냅니다(결국 더 이상 필요하지 않습니다. 왜냐하면 항상 "...조금 앞으로 움직이기 때문입니다." 두 번째 조각이 끝나면 세 번째 조각을 세고 - 지금 세 번째 조각에서 추가 "... 조금 앞으로 이동." 따라서 RAM에는 항상 두 개의 조각(최대 2GB)이 있고 하드 디스크에 대한 액세스는 훨씬 더 적습니다.
찻주전자를 용서하십시오. x64에 제한이 있습니까? 다음은 x64 시스템에서 SQL SERVER 2008을 위한 RAM의 한계를 발견한 첫 번째 기사입니다.
어쩌면 우리는 시도해야합니다.
ps가 유용할 수 있습니다 . 32비트 Windows 8/8.1에서 4GB 메모리 제한을 제거합니다.
많은 양의 정보가 있습니다( 텍스트 파일의 경우 약 20GB).
그럼 왜 텍스트로? 바이너리 형태로 데이터를 추월하기 시작하는 것이 더 쉽지 않습니까? 거기에 크기가 적합합니다.
정보량도 속상하네요... 그곳에서 Gig 10 하고 램디스크로(사실은 메모리로) 옮기고 맘에드는대로 읽어봅니다
그럼 왜 텍스트로? 바이너리 형태로 데이터를 추월하기 시작하는 것이 더 쉽지 않습니까? 거기에 크기가 적합합니다.
64비트 버전으로 전환하십시오. 최대 16TB의 RAM을 사용할 수 있습니다.
파일을 더 빨리 읽을 수 있도록 바이너리 형식으로 저장합니다 .
RAM 크기에 따라 파일을 청크로 처리합니다.
중복 정보를 제거하기 위해 데이터를 사전 처리하십시오.
많은 양의 정보가 있습니다(텍스트 파일의 경우 약 20GB).
...
그리고 이 시퀀스를 한 번 거쳐야 한다면 그렇게 할 것입니다. 그러나 조금씩 앞으로 나아갈 때마다 반복해서 통과해야 합니다.
...
그리고 조각으로 가공한다면?
두 조각을 세고 각각 1GB라고 가정해 보겠습니다. 첫 번째 조각이 처리되고 다음 단계에서 두 번째 조각에서 "... 조금 앞으로 이동"을 추가합니다. 동시에 첫 번째 조각의 시작 부분을 잘라냅니다(결국 더 이상 필요하지 않습니다. 왜냐하면 항상 "...조금 앞으로 움직이기 때문입니다." 두 번째 조각이 끝나면 세 번째 조각을 세고 - 지금 세 번째 조각에서 추가 "... 조금 앞으로 이동." 따라서 RAM에는 항상 두 개의 조각(최대 2GB)이 있고 하드 디스크에 대한 액세스는 훨씬 더 적습니다.
64비트 버전으로 전환하십시오. 최대 16TB의 RAM을 사용할 수 있습니다.
파일을 더 빨리 읽을 수 있도록 바이너리 형식으로 저장합니다 .
RAM 크기에 따라 파일을 청크로 처리합니다.
중복 정보를 제거하기 위해 데이터를 사전 처리하십시오.
이것은 어떤 축/버전입니까? XPro x64도 최대 128개의 물리적, 최대 16TB의 가상을 지원합니다.
이것은 어떤 축/버전입니까? XPro x64도 최대 128개의 물리적, 최대 16TB의 가상을 지원합니다.
많은 양의 정보가 있습니다(텍스트 파일의 경우 약 20GB).
정보는 동일한 유형의 시퀀스로 구성되며 그 중 약 백만 개가 있습니다.
모든 시퀀스 를 반복적으로 정렬하고 몇 가지 계산을 해야 합니다.
가장 먼저 떠오르는 것은 파일의 전체 내용을 읽고 구조 배열로 채우고 메모리에서 작업하는 것입니다.
그러나 다음 크기 조정에서 MT는 "메모리 처리기: 5610000바이트의 메모리를 할당할 수 없습니다"라고 맹세합니다.
동시에 디스패처는 terminal.exe가 3.5GB의 RAM(16개의 물리적 메모리 중)을 사용한다고 말합니다. 프로세스가 4GB만 받을 수 있기 때문인 것으로 알고 있습니다.
EA는 "메모리가 충분하지 않습니다( 4007Mb 사용, 88Mb 사용 가능, 4095Mb 총계)!!!"라고 말합니다.
그리고 이것은 필요한 볼륨의 15.3%에 불과합니다(앞으로 더 늘리고 싶습니다).
그리고 더 이상 상상력이 부족합니다.
많은 조각을 얻을 수 있도록 이러한 시퀀스를 재구성하려고 시도하지만 각 조각에는 현재 필요한 정보만 포함되어 있습니까?
여전히 데이터를 압축하려면(가능한 경우 문자가 있는 부동 소수점으로 이미 전환했습니다)? 그러나 이것은 또 다른 최대 10-20%를 줄 것이고, 나는 크기를 한 단계 더 줄여야 합니다.
어떻게 생각하는지 말해봐 친구들. 내 뒤에 녹슬지 않을거야)
그리고 DB의 사용을 향하여 보지 않았습니까? 우리는 데이터베이스를 넣고 거기에 텍스트 파일의 데이터를 로드합니다. 후속 계산을 위해 사전에 데이터 집계를 수행할 수 있습니다.
그런 다음 전문가의 SQL 쿼리 ...
DBMS를 별도의 서버에 설치하여 거래처의 성능을 높일 수도 있습니다.
참여해주신 모든 분들께 진심으로 감사드립니다!
지금은 주말 동안 오프라인으로 달리고 있지만 월요일에 나는 확실히 모든 사람에게 대답하고 조언을 사용하려고 노력할 것입니다.
그리고 DB의 사용을 향하여 보지 않았습니까? 우리는 데이터베이스를 넣고 거기에 텍스트 파일의 데이터를 로드합니다. 후속 계산을 위해 사전에 데이터 집계를 수행할 수 있습니다.
그런 다음 전문가의 SQL 쿼리 ...
DBMS를 별도의 서버에 설치하여 거래처의 성능을 높일 수도 있습니다.
그것에 대해 생각했다. 의견에 관심:
또 다른 생각은 모든 것을 DB(MySQL?)로 옮기고 작업하는 것입니다. 이론적으로 데이터베이스는 이러한 볼륨과 지속적인 삽질에 맞게 조정됩니다.
전문가가 있습니까? 누가 뭐라고 할까요?
파일을 읽는 것과 비교할 때 가속은 무엇이며 메모리에서 작업하는 것과 비교하여 느려지는 것은 무엇입니까?