Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
정수 :
좋은 생각.
그리고 여기에서 시도할 수 있습니다
>>> 예를 들어 이런 경우에는 군더더기 없는 DBMS를 사용합니다. 그리고 개발에 소요되는 시간이 줄어들고 제품이 안정적입니다.
나는 아직도 노력하고 있다.
세 개의 파일이 있습니다.
1. L. 톨스토이. 전쟁과 평화, 1권.
2. L. 톨스토이. 전쟁과 평화, 2권.
3. F. 도스토야프스키. 범죄와 처벌.
하나하나 포장해 드립니다.
이름이 없는 세 개의 묶음 파일이 있습니다(이름 없는 파일을 어떻게 상상하는지 묻지 마십시오). 우리는 또한 하나의 포장되지 않은 halyard가 있습니다. "Crime and Punishment"로 설정합니다.
이 세 가지 압축 파일에서 이 파일을 찾는 가장 경제적인 방법은 무엇입니까?
옵션 1. 세 파일의 압축을 모두 풀고 원하는 파일을 찾습니다.
옵션 2. 찾고자 하는 파일을 압축하여 3개의 압축 파일 중에서 정확히 동일한 파일을 찾습니다.
예 - 그래서 당신이 제안한 것은 좋지 않습니다
예, 데이터가 짧으면 보관 중에 크기가 증가한다는 것을 알고 있습니다.
이 방향으로 계속 진행하려면 검색에 해싱이나 체크섬을 사용할 수 있습니다. 압축으로 인코딩할 필요는 없습니다. 해시에 대한 인덱스를 만들고 이분법을 사용하여 검색합니다.
그러나 이것은 원본 부분이 완전히 존재하는 경우입니다.
예를 들어 그런 경우에는 군더더기 없이 DBMS를 사용합니다. 그리고 개발에 소요되는 시간이 줄어들고 제품이 안정적입니다.
당신들은 모든 것을 올바르게 말하고 있으며 이것은 압축 옵션이 작업에 대해 정당화되어야 함을 다시 한 번 강조합니다.
문제의 설정에서 춤을 출 필요가 있습니다.
이 방향으로 계속 진행하려면 검색에 해싱이나 체크섬을 사용할 수 있습니다. 압축으로 인코딩할 필요는 없습니다. 해시에 대한 인덱스를 만들고 이분법을 사용하여 검색합니다.
그러나 이것은 원본 부분이 완전히 존재하는 경우입니다.
예를 들어 그런 경우에는 군더더기 없이 DBMS를 사용합니다. 그리고 개발에 소요되는 시간이 줄어들고 제품이 안정적입니다.
그래서 제안하지 않았습니다. 어쨌든 아이디어는 흥미롭습니다.
>>> 두 개의 압축된 시퀀스를 비교하는 것에 대해 이야기하십시오.
디마! 나는 기억한다 - 그것이 바로 그것이었다
이것이 바로 우리가 실제로 한 일입니다.
>>> 예, 데이터가 짧으면 보관 중에 크기가 증가한다는 것을 알고 있습니다.
따라서 적합하지 않음
--
따라서 산업 기반에는 이러한 이념이 없습니다.
...
Ну если хотите продолжать в этом направлении, то для поиска можно и хеширование использовать или контрольную сумму, не обязательно кодировать сжатием. Создать индекс по хешам и методом дихотомии выполнять поиск.
Но это при наличии исходной порции в полном объеме.
Я например, в подобных случаях использую СУБД без всяких выкрутасов. И времени меньше затрачиваю на разработку, и продукт стабильный получается.
정수 :
좋은 생각.그리고 여기에서 시도할 수 있습니다
>>> 예를 들어 이런 경우에는 군더더기 없는 DBMS를 사용합니다. 그리고 개발에 소요되는 시간이 줄어들고 제품이 안정적입니다.
그러나 기성품 산업용 SQL 데이터베이스를 사용하는 것이 가장 좋습니다.
>>> 두 개의 압축된 시퀀스를 비교하는 것에 대해 이야기하십시오.
디마! 나는 기억한다 - 그것이 바로 그것이었다
이것이 바로 우리가 실제로 한 일입니다.
>>> 예, 데이터가 짧으면 보관 중에 크기가 증가한다는 것을 알고 있습니다.
따라서 적합하지 않음
--
따라서 산업 기반에는 이러한 이념이 없습니다.
...
그리고 여기에서 시도할 수 있습니다
>>> 예를 들어 이런 경우에는 군더더기 없는 DBMS를 사용합니다. 그리고 개발에 소요되는 시간이 줄어들고 제품이 안정적입니다.
그러나 기성품 산업용 SQL 데이터베이스를 사용하는 것이 가장 좋습니다.
Yurchik, 파일 처리, 압축 등으로 군더더기 없는 것을 의미했습니다. 순전히 SQL 및 로봇/표시기 논리로 작업합니다. 많은 데이터베이스로 작업했는데 MQL과 SQL을 친구로 만드는 것이 유일한 문제였습니다.)) 배열과 구조 없이 아름다운 솔루션을 만들었습니다.
일반적으로 나는 바퀴를 재발명하는 것이 아니라 최적의 수단을 사용하여 문제를 해결하는 것을 선호합니다.
나는 다른 이유로 생각한다. RAM에 대용량 데이터를 로드하는 문제는 다르게 해결되기 때문에 로드되지 않고 디스크에서 직접 읽습니다. (아마도)
서버가 이 작업을 수행하고 ... 매우 효율적으로