도움이 필요하다! 숙제가 풀리지 않아 철의 한계에 부딪혀 - 페이지 7

새 코멘트
 
YuraZ :

아이디어가 명확하다...

그러나 산업 데이터베이스에는 이에 대한 방법론(빠른 검색 포함)이 없습니다.

분명히 이유가있다

데이터베이스는 RAM에 모든 데이터를 로드하지 않고 검색을 훌륭하게 수행하기 때문입니다.
 
Integer :

예, 아무도 압축 데이터에서 검색에 대해 말하지 않습니다. 두 개의 압축된 시퀀스를 비교하는 것에 대해 이야기하십시오.

배열 "aaa", "bbb", "www"를 가정해 보겠습니다. 세 가지 배열 요소 각각은 다른 요소와 독립적으로 자체적으로 압축할 수 있습니다. 압축하여 배열 "a", "b", "c"를 얻었다고 가정해 보겠습니다.

배열에서 찾아야 하는 원하는 문자열 "bbb"가 있습니다. 검색하기 전에 압축하고 "b"를 얻습니다. 이제 우리는 찾고 찾습니다.

귀하의 경우 반복 횟수를 생략했기 때문에 압축된 형식으로 3a, 3b 및 3c여야 함을 명확히 합시다.

그러한 알고리즘이 70-80% 압축을 제공할 것이라고 생각한다면 오산입니다. 숫자는 말할 것도 없고 러시아어 텍스트에서도 이 접근 방식은 데이터를 부풀리기만 합니다.

예를 들어 "Expert"라는 단어는 "1E1k1s1p1e1r1t"로 다시 코딩되고 단일 비트로 압축되지 않지만 두 배로 늘어납니다. "1"을 생략하면 여전히 압축이 되지 않습니다.

Datetime 2014.08.18 13:45:45 압축을 하지 않습니다.

인용문은 말할 것도 없고... 따라서 이러한 기록의 효율성은 이 경우 0에 가깝습니다. 이것이 소위입니다. PCX 형식에서 사용되는 RLE 알고리즘.

 
elugovoy :

1. 귀하의 경우 반복 횟수를 생략했기 때문에 압축 된 형태로 3a, 3b 및 3c이어야 함을 명확히합시다.

그러한 알고리즘이 70-80% 압축을 제공할 것이라고 생각한다면 오산입니다. 숫자는 말할 것도 없고 러시아어 텍스트에서도 이 접근 방식은 데이터를 부풀리기만 합니다.

예를 들어 "Expert"라는 단어는 "1E1k1s1p1e1r1t"로 다시 코딩되고 단일 비트로 압축되지 않지만 두 배로 늘어납니다. "1"을 생략하면 여전히 압축이 되지 않습니다.

Datetime 2014.08.18 13:45:45 압축을 하지 않습니다.

인용문은 말할 것도 없고... 따라서 이러한 기록의 효율성은 이 경우 0에 가깝습니다. 이것이 소위입니다. PCX 형식에서 사용되는 RLE 알고리즘.

1. 사실이 아닙니다. 아마도 데이터는 모든 것이 세 번 진행되는 것과 같을 것이므로 이것은 간단한 압축 알고리즘입니다.

나머지 ... 오, 감사합니다. 세상에 눈을 뜨게 해 주셔서 감사합니다. 짧은 데이터 시퀀스를 압축하면 크기가 증가한다는 것을 당신 없이는 몰랐습니다.

 
Integer :
데이터베이스는 모든 데이터를 RAM에 로드하지 않고 검색을 훌륭하게 수행하기 때문입니다.

글쎄, 실제로 잘 구축되고 올바르게 구축 된 SQL 서버 - (예를 들어 철에 64g - 128RAM이있는 경우)

운영 체제의 요구 사항을 뺀 거의 모든 것을 차지합니다. 64g ... 128g

20GB(미리 캐시된 데이터)의 데이터 검색 - 실제로 메모리에서 발생합니다...

따라서 압축 -이 상황에서는 의미가 없습니다.

--

 
Integer :

어떻게 암시합니까?

검색을 수행하는 방법은 조금 일찍 썼습니다.

음, 첫째, "힌트"와 "설명"은 다른 개념입니다.

둘째, 내 말로는 이것에 대한 힌트조차 없습니다. 다시 한 번 반복 합니다. 소스 파일에는 하나의 트리가 있고, 찾아야 하는 데이터 부분에는 자체적으로 완전히 다른 트리가 있습니다.

그리고 다소 심각한 압축 알고리즘(클래식, Huffman 포함)을 사용하면 검색을 수행할 수 없습니다. 이론적으로도 말이죠.

 
Integer :
데이터베이스는 RAM에 모든 데이터를 로드하지 않고 검색을 훌륭하게 수행하기 때문입니다.
그렇기 때문에 SQL 데이터베이스에 20GB를 넣는 것이 합리적입니다.
 
elugovoy :

음, 첫째, "힌트"와 "설명"은 다른 개념입니다.

둘째, 내 말로는 이것에 대한 힌트조차 없습니다. 다시 한 번 반복 합니다. 소스 파일에는 하나의 트리가 있고, 찾아야 하는 데이터 부분에는 자체적으로 완전히 다른 트리가 있습니다.

그리고 다소 심각한 압축 알고리즘(클래식, Huffman 포함)을 사용하면 검색을 수행할 수 없습니다. 이론적으로도 말이죠.

동일한 데이터가 압축된 경우 데이터의 일부에 대해 갑자기 다른 트리가 있는 이유는 무엇입니까? 데이터가 다르면 다른 트리를 갖도록 합니다. 동일한 데이터가 압축되었을 때 압축된 데이터를 일치시키는 것이 중요합니다.
 
Integer :
동일한 데이터가 압축된 경우 데이터의 일부에 대해 갑자기 다른 트리가 있는 이유는 무엇입니까? 데이터가 다르면 다른 트리를 갖도록 하십시오. 동일한 데이터가 압축되었을 때 압축된 데이터를 일치시키는 것이 중요합니다.

드미트리 - 가능하다면

오래 전에 그들은 산업용 SQL 데이터베이스를 만들었을 것입니다. (FAST) 검색을 통해 잘(80%-90%) 압축된 데이터 ...

또한 삽입 업데이트 삭제와 함께

 
Integer :

1. 사실이 아닙니다. 아마도 데이터는 모든 것이 세 번 진행되는 것과 같을 것이므로 이것은 간단한 압축 알고리즘입니다.

나머지 ... 오, 감사합니다. 세상에 눈을 뜨게 해 주셔서 감사합니다. 짧은 데이터 시퀀스를 압축하면 크기가 증가한다는 것을 당신 없이는 몰랐습니다.

글쎄, 눈을 뜨게 하기 위해 하나 더 작은 논쟁. 모든 코딩에는 특정 목적이 있습니다.

압축 해제 인코딩이 있습니다. 목적은 텔레타이프(예: 이메일로 사진)만 지원하는 통신 채널을 통해 이진 데이터를 전송하는 것이며, 일반적으로 Radix 알고리즘을 기반으로 Base64가 사용됩니다.

데이터 수정과 관련된 중복 코딩(예: CD Aduio) 목적 - 물리적 매체의 손상으로부터 데이터를 최대한 보호합니다.

압축 코딩, 목적 - 데이터 저장/보관 .

 
YuraZ :

드미트리 - 가능하다면

오래 전에 그들은 산업용 SQL 데이터베이스를 만들었을 것입니다. (FAST) 검색을 통해 잘(80%-90%) 압축된 데이터 ...

2차로 가셨나요? 5-6페이지부터 다시 읽기 시작합니다. 게시물 을주의 깊게 읽으십시오.

내가 제안한 것을 나에게 돌리지 마십시오. 서로 독립적으로 압축된 압축 시퀀스를 비교할 것을 제안했습니다. 큰 파일에 따로 압축된 작은 텍스트를 찾는 대신 한 번에 따로 압축합니다.

1234567891011121314...21
새 코멘트