대규모 ETL 문자열 조회 성능 문제점

ETL 프로세스 성능 문제점이 있습니다. 나는 4 억이 넘는 행을 가진 테이블을 가지고 있습니다. 구조는 다음과 같습니다대규모 ETL 문자열 조회 성능 문제점

id BIGINT 정체성 (1,1)
raw_url VARCHAR (2000) NOT NULL
md5hash CHAR (32) null가 아닌 NOT NULL
job_control_number INT

md5hash의 ID 및 클러스터되지 않은 고유 인덱스의 클러스터 된 고유 인덱스

SQL Server 2008 Enterprise 페이지 수준 압축이 설정되었습니다.

웹 서버 로그의 원시 URL을 차원으로 저장해야합니다. 원시 문자열이 900자를 넘기 때문에 해당 열에 고유 색인을 넣을 수 없습니다. 우리는 md5 해시 함수를 사용하여 인덱스 목적으로 32 개의 고유 한 문자열을 생성합니다. 테이블에 중복 된 raw_url 문자열을 허용 할 수 없습니다.

성능이 좋지 않습니다. md5hash는 당연히 무작위 적이므로 인덱스 조각화가 50 %로 증가하여 비효율적 인 IO가 발생합니다.

더 나은 삽입 및 검색 성능뿐만 아니라 적은 인덱스 조각화를 허용하는 방법에 대한 조언을 찾고 있습니다.

출처

2009-09-14 Sean

이전의 변경되지 않은 데이터가 읽기 전용 파일 그룹에 포함되어 실제 파일로 테이블을 분할합니다. 비 클러스터형 인덱스가 파일 그룹에도 있는지 확인하십시오.

편집 : 페이지 수준 압축을 해제하면 I/O도 향상됩니다.

출처

2009-09-14 14:39:26

덧붙여 비 클러스터형 인덱스의 MD5 해시가 페이지 분할과 관련하여 많은 문제를 일으키지 않습니다. –

처리 시스템에 24 개의 CPU가 있으므로이 경우 페이지 수준 압축이 실제로 IO 오버 헤드를 줄이므로 CPU 사용률이 약간 증가합니다. 가치가있다. 임의의 문자열 인 md5hash는 인덱스 조각화를 50 %로 유도합니다. 따라서 인덱스에 50 %의 채우기 비율을 사용하면 페이지 분할 방식이별로 없지만 1/IO 오버 헤드를 증가시키는 빈 페이지 2 개 – Sean

처음으로 인덱스를 작성하면 I/O 오버 헤드가 발생하지만 장기적으로 볼 때 문제는 아닌지 어떻게 알 수 있습니까? INSERT에 페이지 분할보다 빈 페이지가 더 빨리 나타납니다. 파일 그룹을 보셨습니까? –

필자는 사실 테이블에서 퇴화 된 차원이어야한다고 주장했습니다.

그리고 데이터를 파티셔닝하는 방법을 알아보십시오. 어쩌면 첫 번째 xxx 문자를 가져 와서 별도의 필드로 저장하고 파티션을 나누십시오. 그런 다음 조회를 수행 할 때 짧고 긴 열을 전달하므로 파티션에서 먼저 찾습니다.

출처

2009-11-05 17:51:57

파티션 기능에 대해서는 md5의 처음 2 문자 만 사용할 수 있다고 생각합니다. 그 이상을 사용하면 1000 가지 이상의 조합이 가능합니다. 그럼에도 불구하고 1 개의 분할되지 않은 인덱스를 256 개의 더 작은 인덱스로 분할하여 재 구축 및 삽입에 대한 추가 병렬 처리를 허용합니다. – brian

대규모 ETL 문자열 조회 성능 문제점

답변

관련 문제