2012-04-04 3 views
5

항상 고유 키에 의해 액세스되는 큰 테이블 (약 450 억 행)을 생성하려고합니다.SQL Server의 Hashset equivalent

DB 외부에서이를 유지하는 가장 좋은 구조는 사전 또는 HashSet이지만 물론 데이터 크기로 인해 데이터베이스 외부에서 수행 할 수 없습니다.

SQL Server는 키 - 값 액세스에 최적화 된 구조를 제공합니까? 나는 클러스터 된 키가 매우 빠르다는 것을 이해하지만 여전히 인덱스이므로 통과하는 인덱스 페이지와 연관된 추가 디스크 읽기가있을 것입니다. SQL Server에서 얻고 자하는 것은 데이터를 키 - 값 쌍으로 저장 한 다음 키를 기반으로 값에 액세스 할 수있게 해주는 "기본"구조입니다.

다른 말로하면, SQL Server에 450 억 개의 행을 저장하고 비 클러스터 페이지 인덱스를 읽는 것이 상당한 IO를 초래할 수 있으므로 클러스터 된 또는 클러스터되지 않은 인덱스없이 효율적으로 액세스하는 방법입니다. 각 값은 고유 한 키로 액세스 할 수 있으므로 키의 해시가 값의 물리적 위치로 해석되는 구조를 가질 수 있어야합니다. 1 값을 얻으려면 해시 충돌이 발생하지 않는 한 읽음을 1 회 수행해야합니다.

당신의 도움에 대한

감사 (오라클에 상응하는 해시 클러스터입니다).

답변

3

SQL 서버에는 그런 것이 없습니다. 유일한 옵션은 색인입니다. 주어진 키에 대한 모든 열을 요청하려는 경우 클러스터 된 인덱스를 사용해야합니다. 당신은 단지 부분 집합을 요청 할 거라면, 당신은 당신이 이렇게 원하는 열만 포함 클러스터되지 않은 인덱스를 사용한다 :

create index IX_MyBigTable on MyBigTable(keyColumn) include (col1, col2, col3youneed); 

이 꽤 효율적입니다.

+0

b-tree를 통과하는 것이 해시 값을 생성하는 것보다 훨씬 효율적이지 않으며 SQL Server에서 Clustered 인덱스가 중요한 이유는 데이터 행이 리프 수준에 저장된다는 것입니다. 따라서 인덱스 키의 b 트리 리프에 도달 한 읽기는 해당 키의 데이터 행을 읽습니다. – Rick

+0

이 대답은 정확합니다. 중간 색인 수준은 작고 완전히 캐시됩니다. 기본적으로 이러한 테이블에 PK를 가져 오는 데는 최대 하나의 IO가 필요합니다. 디스크상의 해시 테이블을 사용하는 것과는 대조적으로 핵심 지역에서 이익을 얻을 수 있습니다. – usr

+0

무작위 제안 - 당신이 진정으로 진정으로 100 % 키 - 값 조회 만하고 어떤 종류의 관계형 쿼리도하지 않는다면 SQL은 당신의 대답이 아닐 수 있습니까? Redis를 확인하십시오 - 이해하기 어려울 정도로 빠르며, 트랜잭션적이고, 일관되고, 디스크에 지속적이고, 설치가 쉽습니다. http://redis.io –

0

내 벤치마킹에 따르면 가장 좋은 방법은 키의 해시 열을 만드는 것입니다. Details.