Komposter에게: Andrey, 차원 문제가 발생하면 문제 공식화에 오류가 있는 것입니다.
여기에는 세 가지 옵션이 있습니다.
1 스스로 생각하라
2 공개적으로 작업을 엽니다.
3 개인에게 작업을 공개합니다(비공개를 신뢰할 수 있고 해결할 수 있다고 생각하는 모든 사람).
내가 의미하는 바를 설명하겠습니다. 뉴스를 저장하면 전체 뉴스의 문자열을 작성하거나 일반적인 문구(압축)를 암호화할 수 있습니다. "계정 잔액"은 1로, "계정 자산"은 2로 변환됩니다. 일반적인 문제의 또 다른 변형은 이미 정렬된 데이터를 채우려는 욕구입니다. 큰 차원의 경우 죽음과 같으므로 끝에 추가하고 인덱스로 조건부 정렬을 수행하는 것이 더 쉽습니다.
문제의 공식화에 오류가 있다고 말함으로써 내가 말하고자 하는 바는 명확하다고 생각한다.
글쎄, 그러한 대체는 좋은 텍스트 편집기에서 만들 수 있습니다. 나는 모든 조건(뉴스에 대해 말함)에서 40% 이상의 중복 정보가 있을 것이라고 믿습니다.
그러나 이것은 텍스트 데이터 처리 기능을 작성하지 않아도 됩니다. 볼륨 문제가 해결되면 성능 문제가 몰래 나올 수 있습니다.
그러나 일반적으로 문제에 대한 설명은 완전히 공개되지 않았습니다. 이것은 사실입니다 ... 적은 데이터이지만 더 많은 옵션))
Komposter에게: Andrey, 차원 문제가 발생하면 문제 공식화에 오류가 있는 것입니다.
여기에는 세 가지 옵션이 있습니다.
1 스스로 생각하라
2 공개적으로 작업을 엽니다.
3 개인에게 작업을 공개합니다(비공개를 신뢰할 수 있고 해결할 수 있다고 생각하는 모든 사람).
내가 의미하는 바를 설명하겠습니다. 뉴스를 저장하면 전체 뉴스의 문자열을 작성하거나 일반적인 문구(압축)를 암호화할 수 있습니다. "계정 잔액"은 1로, "계정 자산"은 2로 변환됩니다. 일반적인 문제의 또 다른 변형은 이미 정렬된 데이터를 채우려는 욕구입니다. 큰 차원의 경우 죽음과 같으므로 끝에 추가하고 인덱스로 조건부 정렬을 수행하는 것이 더 쉽습니다.
문제의 공식화에 오류가 있다고 말함으로써 내가 말하고자 하는 바는 명확하다고 생각한다.
글쎄, 그러한 대체는 좋은 텍스트 편집기에서 만들 수 있습니다. 나는 모든 조건(뉴스에 대해 말함)에서 40% 이상의 중복 정보가 있을 것이라고 믿습니다.
그러나 이것은 텍스트 데이터 처리 기능을 작성하지 않아도 됩니다. 볼륨 문제가 해결되면 성능 문제가 몰래 나올 수 있습니다.
그러나 일반적으로 문제에 대한 설명은 완전히 공개되지 않았습니다. 이것은 사실입니다 ... 적은 데이터이지만 더 많은 옵션))
"그녀는 빨간색입니까? 아니요, 그녀는 흑인입니다. 왜 백인입니까? 녹색이기 때문입니다."
여기서 우리는 다른 것에 대해 이야기하고 있습니다.
>>> 두 개의 압축된 시퀀스를 비교하는 것에 대해 이야기하십시오.
시퀀스가 없기 때문에 고유한 요소가 압축되지 않으면 검색이 실패합니다.
실제 체크인
예 - RAR 두 파일 압축
요소 - 08:01:
및 시퀀스
08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10시 56분 12초.
10시 56분 12초.
10시 56분 12초.
10:56:13.
10시 56분 39초.
10시 56분 39초.
10시 56분 39초.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10시 57분 52초.
11시 44분 50초.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.
---
HEX 편집기에서 두 RAR 파일을 모두 열고
08:01: 요소가 줄어들지 않았음을 알 수 있습니다.
두 번째 파일에 들어간 것과 어떤 식으로든 일치하지 않습니다.
각 레코드를 압축하면(각 열을 별도로) 크기가 증가하지 않습니다.
반대로 아카이버의 제어 데이터로 인해 데이터 양이 증가합니다.
실제 체크인
예 - RAR 두 파일 압축
요소 - 08:01:
및 시퀀스
08:01:33.
08:01:38.
08:01:38.
08:01:39.
08:01:40.
08:01:49.
08:01:57.
08:16:53.
08:16:59.
10:09:28.
10:09:29.
10:09:29.
10:09:29.
10:09:30.
10:32:23.
10:32:24.
10:56:11.
10시 56분 12초.
10시 56분 12초.
10시 56분 12초.
10:56:13.
10시 56분 39초.
10시 56분 39초.
10시 56분 39초.
10:56:48.
10:56:48.
10:56:48.
10:57:03.
10:57:04.
10:57:04.
10:57:07.
10:57:07.
10:57:07.
10:57:51.
10시 57분 52초.
11시 44분 50초.
11:44:52.
11:44:52.
11:44:52.
11:44:53.
12:57:35.
12:57:46.08:01:
12:57:46.
12:57:46.
14:01:41.
14:01:46.
14:20:06.
14:20:08.
---
HEX 편집기에서 두 RAR 파일을 모두 열고
08:01: 요소가 줄어들지 않았음을 알 수 있습니다.
그리고 일치하지 않습니다
각 레코드를 압축하면(각 열을 별도로) 크기가 증가하지 않습니다.
반대로 데이터의 양이 증가합니다.
각 레코드는 개별적으로 압축해야 합니다. 당연히 이것은 압축이 실제로 압축될 만큼 레코드가 충분히 클 때만 의미가 있습니다.
각 레코드는 개별적으로 압축해야 합니다. 당연히 이것은 압축이 실제로 압축될 만큼 레코드가 충분히 클 때만 의미가 있습니다.
글쎄, 우리는 블록으로 작업해야한다는 결론에 도달했습니다. 따라서 블록의 크기와 일치하지 않는 정보의 일부를 찾을 수 없습니다.
왜 이런거야? 에서 무엇을? 문제가 무엇입니까? 그것에 오지 않았다.
왜 이런거야? 에서 무엇을? 문제가 무엇입니까? 그것에 오지 않았다.
각 레코드는 개별적으로 압축해야 합니다. 당연히 이것은 압축이 실제로 압축될 만큼 레코드가 충분히 클 때만 의미가 있습니다.
Dmitry - 각 레코드를 압축하는 경우 - 한 줄
오히려 볼륨이 커집니다. 확인하세요!
201 a1.rar가 됨 -- 압착
535 이었다 aaaa1
77 이 되었습니다. a2.rar 하나의 요소가 압축되었습니다 - 보다 정확하게는 축소되지 않았지만 ... 파일 + 제어 바이트에 들어갔습니다.
8 이었다 aaaa2
---
데이터 양이 20GB에서 20GB로 증가할 것입니다. 검색 요소 + 제어 바이트
그리고 요점이 무엇입니까?
Dmitry - 각 레코드를 압축하는 경우 - 한 줄
오히려 볼륨이 커집니다. 확인하세요!
201 a1.rar -- 압착
535 화
77 a2.rar 하나의 요소가 압축되었습니다. 더 정확하게는 압축되지 않았지만 ... 파일 + 제어 바이트에 들어왔습니다.
8 aaaa2
---
데이터 양이 20GB에서 20GB로 증가할 것입니다. 검색 요소 + 제어 바이트
그리고 요점이 무엇입니까?
예, 데이터가 짧으면 보관 중에 크기가 증가한다는 것을 알고 있습니다.
예 - 그래서 당신이 제안한 것은 좋지 않습니다