B- 트리 대 해시 테이블

MySQL에서 인덱스 유형은 b- 트리이고 b- 트리의 요소에 대한 액세스는 대수 상각 시간 O(log(n))입니다.

반면에 해시 테이블의 요소에 액세스하는 것은 O(1).

데이터베이스 내부의 데이터에 액세스하기 위해 B- 트리 대신 해시 테이블을 사용하지 않는 이유는 무엇입니까?

해시 테이블의 기본 키를 통해서만 요소에 액세스 할 수 있습니다. 이는 트리 알고리즘 ( O(1)대신log(n) ) 보다 빠르지 만 범위 ( 및 사이의 모든 항목)를xy 선택할 수 없습니다 . 트리 알고리즘은이를 지원하는 Log(n)반면 해시 인덱스는 전체 테이블 스캔을 수행 할 수 있습니다 O(n). 또한 해시 인덱스의 상수 오버 헤드는 일반적으로 더 큽니다 ( 세타 표기법의 요소는 아니지만 여전히 존재합니다 ). 또한 트리 알고리즘은 일반적으로 유지 관리, 데이터 증가, 확장 등이 더 쉽습니다.

해시 인덱스는 미리 정의 된 해시 크기로 작동하므로 객체가 저장되는 "버킷"이 생깁니다. 이러한 객체는이 파티션 내에서 올바른 객체를 찾기 위해 다시 반복됩니다.

따라서 크기가 작은 경우 작은 요소에 대한 오버 헤드가 많고 크기가 크면 추가 스캔이 발생합니다.

오늘날의 해시 테이블 알고리즘은 일반적으로 확장되지만 확장은 비효율적 일 수 있습니다.

실제로 확장 가능한 해싱 알고리즘이 있습니다. 어떻게 작동하는지 묻지 마세요. 나에게도 미스터리입니다. AFAIK는 재해 싱이 쉽지 않은 확장 가능한 복제에서 발전했습니다.

그 호출 RUSH - R eplication U 파인더 S calable H의 애싱, 이러한 알고리즘은 따라서 RUSH 알고리즘을 호출한다.

그러나 인덱스가 해시 크기에 비해 허용 가능한 크기를 초과하고 전체 인덱스를 다시 작성해야하는 지점이있을 수 있습니다. 일반적으로 이것은 문제가되지 않지만 거대한 데이터베이스의 경우 며칠이 걸릴 수 있습니다.

트리 알고리즘에 대한 트레이드 오프는 작으며 거의 ​​모든 사용 사례에 적합하므로 기본값입니다.

그러나 매우 정확한 사용 사례가 있고 무엇이 필요한지 정확히 알고있는 경우 해싱 인덱스를 활용할 수 있습니다.

실제로 MySQL은 다음 링크 에 따라 해시 테이블 또는 b- 트리 두 종류의 인덱스를 모두 사용하는 것으로 보입니다 .

b- 트리와 해시 테이블 사용의 차이점은 전자 를 사용하면 =,>,> =, <, <= 또는 BETWEEN 연산자를 사용하는 표현식에서 열 비교 를 사용할 수 있고 후자는 다음에 대해서만 사용된다는 것 입니다. = 또는 <=> 연산자를 사용하는 같음 비교 .

해시 테이블의 시간 복잡도는 충분한 크기의 해시 테이블에 대해서만 일정합니다 (데이터를 보관할 충분한 버킷이 있어야 함). 데이터베이스 테이블의 크기는 미리 알 수 없으므로 해시 테이블에서 최적의 성능을 얻으려면 테이블을 지금 다시 해시해야합니다. 재해 싱도 비싸다.

해시 맵은 크기가 조정되지 않고 전체 맵을 다시 해시해야 할 때 비용이 많이들 수 있다고 생각합니다.

Pick DB / OS는 해싱을 기반으로하고 잘 작동했습니다. 요즘에는 효율적인 희소 해시 테이블을 지원하기 위해 더 많은 메모리를 사용하고 적당한 범위 쿼리를 지원하기위한 중복 해싱을 사용하면 해싱이 아직 그 자리를 차지할 수 있다고 말하고 싶습니다 (일부는 와일드 카드 및 정규식과 같은 다른 형태의 비 범위 유사성 일치를 사용합니다. ). 또한 메모리 계층 구조에 속도 차이가 큰 경우 충돌 체인을 연속적으로 유지하기 위해 복사하는 것이 좋습니다.