솔리드 스테이트 드라이브의 등장으로 B- 트리 및 기타 데이터 구조가 더 이상 사용되지 않습니까?

오늘날 많은 (아마도?) 데이터베이스 응용 프로그램은 B-Tree 및 변형을 사용하여 데이터를 저장합니다.이 데이터 구조는 하드 디스크의 읽기, 쓰기 및 검색 작업을 최적화하고 이러한 작업은 전반적인 효율성에서 중요한 역할을하기 때문입니다. 데이터베이스).

그러나 SSD (Solid State Drive)가 기존의 하드 디스크 (HDD)를 완전히 대체해야한다면 B- 트리 및 변형이 더 이상 사용되지 않아 직접 액세스 메모리에서보다 효율적으로 작동하는 데이터 구조를위한 공간이 생길 것이라고 말할 수 있습니까? 그렇다면 그 구조는 무엇입니까? (예 : 해시 테이블, AVL 트리)

database data-structures

— 다니엘 스코코
소스

데이터베이스 응용 프로그램 외부에서 다른 응용 프로그램이 많기 때문에 데이터베이스 구현 관점에서 또는 일반적으로 더 이상 사용되지 않을 것인지 묻고 있습니까?

— Pemdas

데이터베이스 관점에서.

— Daniel Scocco

답변:

B- 트리는 하드 디스크의 데이터베이스 인덱스에 가장 많이 사용되지만 여러 계층의 캐시와 가상 메모리를 갖춘 최신 메모리 계층 구조를 고려할 때 인 메모리 데이터 구조로도 이점이 있습니다. 가상 메모리가 SSD에 있어도 변경되지 않습니다.

나는 C ++로 꽤 많이 쓴 메모리 내 B + 스타일 멀티 웨이 트리 라이브러리를 사용합니다. 원래 작성된 이유는 캐시를 더 잘 사용하려고했기 때문에 성능 이점 이 있을 수 있지만 종종 그런 식으로 작동하지 않는다는 것을 인정해야합니다. 문제는 항목이 삽입 및 삭제시 노드 내에서 이동해야하며 이진 트리에서는 발생하지 않는 절충입니다. 또한, 내가 그것을 최적화하는 데 사용한 저수준 코딩 해킹 중 일부는 아마도 옵티 마이저를 혼동하고 물리 칠 것입니다.

어쨌든 데이터베이스가 SSD에 저장되어 있어도 여전히 블록 지향 저장 장치이며 B-Tree 및 기타 멀티 웨이 트리를 사용하는 것이 여전히 유리합니다.

그러나 약 10 년 전에는 캐시를 모르는 알고리즘과 데이터 구조가 발명되었습니다. 이것들은 캐시 등의 크기와 구조에 대해 잘 모릅니다.-모든 메모리 계층 구조를 (무의식적으로) 최대한 활용합니다. B- 트리는 특정 메모리 계층 구조에 맞게 "조정"되어야 최상의 활용을 할 수 있습니다 (다양한 범위에서 상당히 잘 작동하지만).

캐시의 명백하지 않은 데이터 구조는 아직 야생에서 종종 보이지는 않지만 일반적인 메모리 내 이진 트리를 쓸모 없게 만들 수 있습니다. 또한 클러스터 크기 또는 하드 디스크 캐시 페이지 크기가 무엇인지 신경 쓰지 않기 때문에 하드 디스크 및 SSD에도 가치가 있습니다.

Van Emde Boas 레이아웃은 캐시를 모르는 데이터 구조에서 매우 중요합니다.

MIT OpenCourseware 알고리즘 과정에는 캐시가 보이지 않는 데이터 구조에 대한 내용이 포함되어 있습니다.

— 스티브 314
소스

흥미 롭군 이 주제를 더 탐색 할 수있는 유용한 정보를 제공했습니다. 감사.

— Daniel Scocco

이 MIT 과정 에는 캐시가 보이지 않는 데이터 구조에 대한 정보도 있습니다.

— dan_waterworth

안녕하십니까, SSD가 아닌 캐시가 모르는 데이터 구조로 인해 B-tree가 더 이상 사용되지 않을 것입니까? 그러나 DBMS의 블록 관리와 같은 다른 데이터 구조는 어떻습니까?

— Yang Bo

@ user955091-캐시가 모르는 데이터 구조 (캐시가 모르는 모델에서 최적의 구조를 의미하는)로 인해 의미가 있었지만 그 당시에는 너무 흥분했습니다. 다른 데이터 구조는 곧 사라지지 않을 것입니다. 우선, 캐시 만이 성능 문제는 아닙니다. 병렬 처리는 다른 요구를 만듭니다. 게다가, 키 기반 순서가 필요한 것은 종종 특별한 경우입니다. 일반적으로 해시 테이블이 왕입니다. 캐시에 익숙 하지 않은 "임의 화 된"레이아웃을보기는 어렵지만 항목을 직접 가져 오기위한 한 번의 액세스는 이길 수 없으므로 지역이 필요 하지 않습니다 .

— Steve314

우선, 디스크가 느리게 이동하고 데이터를 가져 오는 하드 드라이브에서 로컬 리티가 모두 중요하기 때문에 B-Tree가 더 이상 데이터를 저장하는 데 가장 효율적인 데이터 구조가 아니기 때문에 대부분의 데이터베이스 엔진을 다시 작성해야합니다. 블록 단위로 데이터를 변경하면 다음이 필요합니다.

헤드를 디스크의 올바른 위치 (~ 10ms)로 이동하십시오.
디스크가 회전 할 때까지 기다립니다 (10k rpm에서 초당 167 회 회전을 의미하지만 평균적으로 반 회전 만 기다리므로 ~ 3ms).
블록을 읽습니다 (~ 3ms).
RAM에서 수정하십시오. (~ 10ns)
헤드를 디스크의 올바른 위치로 다시 이동하십시오 (~ 10ms).
디스크가 다시 회전 할 때까지 기다립니다 (~ 3ms 다시).
블록을 쓰십시오 (~ 3ms).

10 + 3 + 3 + 10 + 3 + 3 = 34ms입니다.

평균적으로 SSD에서 동일한 작업을 수행하는 것은 디스크 위치에 관계없이 1ms에 불과합니다.

그리고 해시 테이블이 훨씬 빠르기 때문에 해시 테이블이 더 나은 대안이라고 생각할 수 있습니다.

유일한 문제는 해시 테이블이 순서 보존이 아니기 때문에 Van Emde Boas처럼 다음과 이전을 찾을 수 없다는 것입니다.

보다:

다음 및 이전 찾기가 중요한 이유는 무엇입니까? x보다 크고 z보다 작은 모든 요소를 얻는다고 가정하면 이전 찾기 및 다음 찾기와 함께 색인을 사용해야합니다.

글쎄, 유일한 문제는 주문 보존 능력을 가진 해시 테이블을 찾지 못했다는 것입니다. B- 트리에서 버킷의 크기가 중요 할 수도 있지만 캐시 불명확 한 알고리즘으로 해결됩니다.

그래서 이것은 개방형 문제라고 말할 것입니다.

— 빌헬름 반 엔데 보아스
소스

해시 테이블은 (일반적으로) 캐시를 모르는 WRT의 성능을 모델링하지만 해당 모델에서 효율적이라는 의미는 아닙니다. 문제는 해시 함수가 일반적으로 항목을 "임의로"흩어 지도록 설계되어 있기 때문에 해시 테이블이 정렬되지 않은 이유와 지역성이 낮은 이유입니다. 즉, 인접한 키가있는 일련의 항목을 식별 할 수 있어도 블록 당 두 개 이상의 항목을 읽을 경우 이점이 없을 것입니다 (SSD는 여전히 블록 장치 임).

— Steve314

물론 해싱을 "키 변환"이라고도하며 변환이 "무작위"일 필요 는 없습니다. 아마도 검색을 제거하지 않고 합리적으로 효율적인 순차 액세스를 허용하는 해시 함수를 정의 할 수 있습니다. 해시 함수, 결국-최소화)) 여전히 해시 충돌을 거의 유지하지 않고 지역적 이점을 제공합니다.

— Steve314