킬로바이트 블록 및 포인터의 모든 가능한 순열의 메모리가 가능합니까?

이것은 내 머리를 감싸기에 충분하지 않은 아이디어이며 알고있는 사람들이 더 잘 읽을 수 있도록 편집 / 도움을 주시면 감사하겠습니다.

이론적으로 1 킬로바이트의 가능한 모든 이진 순열의 사본 하나를 저장 한 다음 시스템의 나머지 부분에 단순히 이러한 위치에 대한 포인터를 작성하는 하드 드라이브를 가질 수 있습니까?

시스템이 단순히 정보를 직접 저장하는 것보다 더 빠른 방법일까요?

다른 방법으로 설명하려면 문장 대신 말하십시오.

"안녕 밥입니다." "그 샌드위치 맛있겠다."

... 하드 드라이브에 저장하면 알파벳과 다른 문자의 모든 순열 (최대 1000 자 정도)을 입력 한 다음 문장을 다음과 같이 저장합니다.

[포인터 # 21381723]

2 개의 ⁸¹⁹² 개의 서로 다른 1K 블록이 있습니다. 그것들을 모두 저장하려면 2 ⁸²⁰² 비트의 저장 공간이 필요합니다. 우주에는 약 10 ⁸⁰ (또는 ~ 2 ²⁶⁶ )의 입자 만 포함되어 있기 때문에 모든 입자 를 저장할 수 없다는 것이 안전 합니다. 시간을 절약 할 수 있을지 궁금하지 않아도됩니다.

그러나 실제로 이에 대한 더 흥미로운 방법이 있습니다. 거대한 상수 풀에 인덱스를 생성하는 것이 좋습니다. 그러나 역 참조 할 인덱스를 어떻게 알 수 있습니까? 당신이 저장하려는 인수를 위해 상상 만 1 문자 블록 : a, b, c... 그 그 블록을 저장하는 가장 효율적인 레이아웃 이후 아마도 당신의 인덱스는 0, 1, 2 등이 될 것입니다.

합의에 대해 뭔가 알아 차렸습니까? 실제로 인덱스는 저장된 데이터의 코드화 된 표현입니다 ! 다시 말해, 당신은 전혀 역 참조 할 필요가 없으며, 색인을 원하는 데이터로 변환하면됩니다.

당신이 저장되면 모든 테이블에 뭔가의 가능한 값이 항상 발생합니다 색인은 단순히 데이터 자체의 인코딩 된 버전이된다, 그래서 데이터가 처음에 불필요하게 저장. 이 이유는 현실 세계에서, 인덱스는 스파 스 데이터 (방문한 예를 들어 모든 웹 페이지, 모든 웹 페이지에서만 유용 존재할 수 , 심지어 모든 것을 할 존재).

다른 사람들이 이미 지적했듯이 1k 블록에 대해 2 ^ 8192 가능성이 있습니다. 즉, 모든 블록 주소가 같은 양의 비트로 인코딩되면 주소의 길이가 1k가 될 경우 블록의 주소를 인코딩하려면 8192 비트가 필요합니다. 간접 레이어를 추가하는 것 외에는 아무것도 얻지 못하므로 성능을 얻지 못합니다.

더 짧은 주소를 원한다면 짧은 주소로 일부 블록을 인코딩하고 일부는 더 긴 블록으로 인코딩하여 긴 블록이 자주 표시되지 않도록해야하며 이제는 데이터를 압축하고 있습니다. 허프만 코드 ). 저장하기 전에 저장하는 데이터에 대한 지식이 있거나 인코딩을 정기적으로 변경해야합니다. 길이가 다른 블록을 사용하는 다른 압축 알고리즘보다 효율성이 떨어질 수 있습니다.

그것에는 두 가지 문제가 있습니다.

첫째, "1 킬로바이트의 모든 가능한 이진 순열"은 엄청난 양의 데이터입니다. 1024 바이트 * 바이트 당 8 비트 = 킬로바이트 단위의 8192 비트 가능한 모든 순열은 2 ^ 8192입니다. 약 1.09e+2466킬로바이트입니다! (비교를 위해 1TB 드라이브는 1e09킬로바이트입니다.)

둘째, 거대한 테이블이 있고 포인터를 사용하여 색인을 생성 한 경우에도 정확히 1KB보다 작은 데이터를 참조하려면 어떻게해야합니까?

다른 포스터가 지적했듯이 어느 시점에서 가능한 모든 값 목록에 색인을 생성하는 데 필요한 포인터 크기는 이득을 무효화합니다.

그러나 일부 언어는 메모리 사용을 최적화하기 위해 제안한 내용의 제한된 버전을 사용합니다. 파이썬은 문자열 'interning'을 사용하여 메모리의 중복 문자열 수를 줄입니다. 'python string intern'을 검색하여 자세한 정보를 찾을 수 있습니다.