URL 또는 유사한 문자열을 나타 내기 위해 binary_checksum()을 사용하는 데 제한이 있습니까?

Question

로그가 정말 큽니다. (수백만 행)

LogTable 
------- 
ID  
DATE 
BASEURL 
QUERYSTRING 
USER 
REFERRER 
USERAGENT 
SERVER 

데이터를 정규화하여이 테이블을 줄이십시오. (슬림 한 사이즈)

나는 알고있다! 알아! 로그는 초고속 인서트 여야합니다. 반면에 로그 테이블은 너무 커서 유지 관리 계획이 추해지고 있습니다. 그래서 저는 BASEURL, USER, SERVER, USERAGENT와 같이 반복적 인 컬럼에만 관심이 있습니다.

는 지금, 나는 로깅이 여전히 빨라야 알고, 그래서 내 질문에 이르게하는 문자열 비교하고 싶지 않아 :

내가 LOGTABLE에

binary_checksum(COLUMN_VALUE) 

를 저장에 의존 할 수 , 별도의 테이블에 COLUMN_VALUE와 체크섬 매핑을 유지 하시겠습니까?

내 응용 프로그램에서는 모든 요청에 ​​대해 데이터베이스 서버로 돌아갈 필요가 없도록 매핑 캐시를 보관할 것입니다. (새로운 체크섬 값이있는 경우에만 매핑 테이블에 삽입해야합니다.)

주요 목표는 테이블에 대한 간단한 분석 쿼리를 실행하고 데이터를 추출 할 수있게하는 것입니다. 데이터베이스 (및 내 응용 프로그램)를 완전히 정지시키는 것입니다.

다음은 간단한 쿼리는 예를 들어, :

select 
    count(1) 
, [user] /* This is a checksum value, which I can lookup in my cache */ 
from 
    LogTable 
where date between @from and @to 
group by [user] 

당신은 어떻게 생각하십니까? 이 체크섬 접근은 괜찮습니까?

편집 :

• 내 모든 열은 VARCHAR (2000) 이하이다.
• 데이터를 더 빨리 인덱싱 할 수 있다고 가정합니까? (오프라인/변형 복사본의 색인을 생성합니다)

Answer 1

해시 충돌 전략이란 무엇입니까? 32 비트 다이제스트를 발생시키는 체크섬은 단지 65,000 개의 항목 후에 50 %의 충돌 확률을 갖습니다. 이는 meet-in-the-middle 개의 충돌로 인한 것입니다. 수백만 행의 경우 해시 충돌 가능성이 매우 높습니다.

Answer 2

로그 저장 시나리오를 과소 평가하는 것에 대한 다른 의견 외에, 날짜별로 테이블을 분할하는 것을 고려해야하며 광범위한보고가 필요한 경우 데이터를 다른 형식 (크기 또는 요약)으로 변환하는 것에 대해 생각해보십시오. 보고를 위해.

예를 들어, USERAGENT는 긴 문자열을 대리 정수로 대체하는 (눈송이 가능성이있는) 차원의 첫 번째 후보입니다.

요구 사항에 따라 지정된 영구 저장 장치 (최소 용량으로 변환 됨)에 보관 한 후에는 최소한의 정보 만 로그 테이블에 보관할 수 있습니다.