물론 가장 건전한 결정은 알고리즘을 변경하는 것입니다. 그러나 알려지지 않았기 때문에 여기서 구체적인 것은 아무것도 제공할 수 없습니다. 일반적인 생각은 물론 전혀 아닐 수도 있습니다.
예를 들어 파일을 여러 번 읽어야 하는 경우 이 읽기는 내부 "루프"에서 발생할 수 있습니다. 판독값을 가장 바깥쪽 "루프"로 "전송"하려고 시도할 수 있습니다. 일반적으로 이러한 "전송"은 처음부터 완전히 새로운 알고리즘을 생성하는 것을 의미할 수 있기 때문에 따옴표가 사용됩니다.
또 다른 단서는 시프트를 사용한 직렬 읽기에 대한 언급에서 나옵니다. "시프트"만 읽어야 하는 일부 반복 알고리즘이 이 문제를 해결할 수 있습니다. 그러나 다시 말하지만 이것은 완전히 다른 알고리즘을 처음부터 구축하는 것을 의미할 수 있습니다.
물론 가장 건전한 결정은 알고리즘을 변경하는 것입니다. 그러나 알려지지 않았기 때문에 여기서 구체적인 것은 아무것도 제공할 수 없습니다. 일반적인 생각은 물론 전혀 아닐 수도 있습니다.
예를 들어 파일을 여러 번 읽어야 하는 경우 이 읽기는 내부 "루프"에서 발생할 수 있습니다. 판독값을 가장 바깥쪽 "루프"로 "전송"하려고 시도할 수 있습니다. 일반적으로 이러한 "전송"은 처음부터 완전히 새로운 알고리즘을 생성하는 것을 의미할 수 있기 때문에 따옴표가 사용됩니다.
또 다른 단서는 시프트를 사용한 직렬 읽기에 대한 언급에서 나옵니다. "시프트"만 읽어야 하는 일부 반복 알고리즘이 이 문제를 해결할 수 있습니다. 그러나 다시 말하지만 이것은 완전히 다른 알고리즘을 처음부터 구축하는 것을 의미할 수 있습니다.
당신이 찾고있는 것은 압축되어 압축으로 검색 될 수 있습니다. 데이터의 양과 모든 데이터를 RAM에 유지하는 기능을 줄입니다. (이론에 의하면)
당신이 찾고있는 것은 압축되어 압축으로 검색 될 수 있습니다. 데이터의 양과 모든 데이터를 RAM에 유지하는 기능을 줄입니다. (이론에 의하면)
ihmo - 압축된 형식으로 검색하려면 먼저 압축을 풀어야 합니다. - 이론적으로 압축된 형식으로 데이터를 검색하는 알고리즘을 작성하십시오. - fuck
문제는 RAM - mt4(32비트)에서 많이 저장할 수 없다는 것입니다.
---
어떤 데이터베이스에든 큰 볼륨을 넣고 쿼리를 사용하여 미리 만들어진 계산 데이터를 받는 것이 논리적입니다.
자체 데이터 처리 메커니즘을 작성하는 것보다 기성 솔루션을 적용하는 방법을 더 잘 생각하는 것은 없습니다.
SQL은 대용량 저장에 매우 적합하지만 SQL의 경우 20기가는 그리 많지 않습니다...
--
고유한 메커니즘을 작성하고 이 파일을 부분적으로 읽는 옵션은 속도를 위해 읽을 수 있는 조각에 최대 메모리 양을 할당합니다.
한 주기의 계산을 실행하려면 20기가에서 여러 조각을 읽어야 합니다.
문제는 - 데이터베이스를 데이터베이스로 구동하고 SQL 쿼리를 통해 처리하는 옵션보다 더 빠를 것입니까 - 제 생각에는 그렇지 않습니다
SQL에 데이터를 입력하면 거의 더 빠를 것이라고 생각합니다.
ihmo - 압축된 파일을 검색하려면 먼저 압축을 풀어야 합니다.
물론 가장 건전한 결정은 알고리즘을 변경하는 것입니다. 그러나 알려지지 않았기 때문에 여기서 구체적인 것은 아무것도 제공할 수 없습니다. 일반적인 생각은 물론 전혀 아닐 수도 있습니다.
예를 들어 파일을 여러 번 읽어야 하는 경우 이 읽기는 내부 "루프"에서 발생할 수 있습니다. 판독값을 가장 바깥쪽 "루프"로 "전송"하려고 시도할 수 있습니다. 일반적으로 이러한 "전송"은 처음부터 완전히 새로운 알고리즘을 생성하는 것을 의미할 수 있기 때문에 따옴표가 사용됩니다.
또 다른 단서는 시프트를 사용한 직렬 읽기에 대한 언급에서 나옵니다. "시프트"만 읽어야 하는 일부 반복 알고리즘이 이 문제를 해결할 수 있습니다. 그러나 다시 말하지만 이것은 완전히 다른 알고리즘을 처음부터 구축하는 것을 의미할 수 있습니다.
아니면 전혀 그렇지 않을 수도 있습니다. :)
필요하지 않습니다. 찾고 있는 것을 압축할 수 있습니다. 그게 다야! :)
---
많은 양의 정보가 있습니다(텍스트 파일의 경우 약 20GB).
정보는 동일한 유형의 시퀀스로 구성되며 약 백만 개가 있습니다.
모든 시퀀스 를 반복적으로 정렬하고 몇 가지 계산을 해야 합니다.
---
20GB 중에서 알고리즘에 데이터를 제출해야 합니다.
검색하지 않음 - 알고리즘에서 사용되는 파일 형식의 데이터가 계산 알고리즘에 제공됨
물론 가장 건전한 결정은 알고리즘을 변경하는 것입니다. 그러나 알려지지 않았기 때문에 여기서 구체적인 것은 아무것도 제공할 수 없습니다. 일반적인 생각은 물론 전혀 아닐 수도 있습니다.
예를 들어 파일을 여러 번 읽어야 하는 경우 이 읽기는 내부 "루프"에서 발생할 수 있습니다. 판독값을 가장 바깥쪽 "루프"로 "전송"하려고 시도할 수 있습니다. 일반적으로 이러한 "전송"은 처음부터 완전히 새로운 알고리즘을 생성하는 것을 의미할 수 있기 때문에 따옴표가 사용됩니다.
또 다른 단서는 시프트를 사용한 직렬 읽기에 대한 언급에서 나옵니다. "시프트"만 읽어야 하는 일부 반복 알고리즘이 이 문제를 해결할 수 있습니다. 그러나 다시 말하지만 이것은 완전히 다른 알고리즘을 처음부터 구축하는 것을 의미할 수 있습니다.
아니면 전혀 그렇지 않을 수도 있습니다. :)
---
많은 양의 정보가 있습니다(텍스트 파일의 경우 약 20GB).
정보는 동일한 유형의 시퀀스로 구성되며 약 백만 개가 있습니다.
모든 시퀀스 를 반복적으로 정렬하고 몇 가지 계산을 해야 합니다.
---
20GB 중에서 알고리즘에 데이터를 제출해야 합니다.
검색하지 않고 알고리즘에 사용되는 데이터베이스가 있습니다.
필요하지 않습니다. 찾고 있는 것을 압축할 수 있습니다. 그게 다야! :)
친구, 당신은 나를 놀라게
어떤 알고리즘을 압축할 것인가? 허프만, 렘펠 지브?
글쎄, 그것은 텍스트 편집기와 같이 4-8 배 압축을 줄 것입니다. 압축 알고리즘이 각 파일에 대해 자체 레코딩 트리를 생성한다는 사실을 고려하십시오.
즉, 소스 파일에 대해 하나의 트리가 있고 찾아야 하는 데이터의 일부에 대해 완전히 다른 자체 트리가 있습니다.
검색 수행을 제안하는 방법이 궁금하십니까? 이론적으로도
데이터 압축은 인코딩에 불과합니다. 암호화에 비유하면 서로 다른 키(기록 트리)로 암호화된 두 개의 서로 다른 메시지(압축 데이터)를 받게 됩니다.
검색 기능은 말할 것도 없고 어떻게든 비교하는 것조차 불가능합니다)))
친구, 당신은 나를 놀라게
어떤 알고리즘을 압축할 것인가? 허프만, 렘펠 지브?
글쎄, 그것은 텍스트 편집기와 같이 4-8 배 압축을 줄 것입니다. 압축 알고리즘이 각 파일에 대해 자체 레코딩 트리를 생성한다는 사실을 고려하십시오.
즉, 소스 파일에 대해 하나의 트리가 있고 찾아야 하는 데이터의 일부에 대해 완전히 다른 자체 트리가 있습니다.
검색 수행을 제안하는 방법이 궁금하십니까? 이론적으로도
데이터 압축은 인코딩에 불과합니다. 암호화에 비유하면 서로 다른 키(기록 트리)로 암호화된 두 개의 서로 다른 메시지(압축 데이터)를 받게 됩니다.
검색 기능은 말할 것도 없고 어떻게든 비교하는 것조차 불가능)))
오, 여기서 얼마나 많은 것들이 나를 놀라게 합니까?
아이가 이해해줘야 할 것 같습니다. 어떤 텍스트가 어떤 알고리즘에 의해 압축된다면, 그것은 오늘과 내일도 압축된 형태로 정확히 동일할 것입니다.
동일한 압축 알고리즘을 사용하고 출력에서 두 개의 다른 텍스트를 압축하면 두 개의 완전히 동일한 데이터 시퀀스를 얻을 수 있다는 말씀이신가요?
그냥 음모입니다. 물론 무엇이든 될 수 있지만 나는 그가 찾고 있다고 가정합니다. 라고 생각하기도 합니다.
내가 뭘 찾고 있는지 모르겠어...
>>> 모든 시퀀스 를 반복 하고 몇 가지 계산을 해야 합니다.
글쎄 - 그것은 - 찾고 -하지만 20 공연을 통해 정렬을 찾고 있습니다 ...
검색은 원칙적으로 약간의 열거 및 비교가 있다는 사실을 기반으로 합니다.
나는 저자가 쓴 것에서 진행한다데이터를 축소할 수 없음 - 압축 - 인덱싱됨
데이터를 SQL에 넣는 것이 논리적입니다.
즉, 비즈니스 로직을 서버 + 데이터로 전송
EA는 열거 및 계산을 위해 서버에 짧은 데이터만 보냅니다.
그리고 준비된 답변을 얻으십시오