저희 제품은 동시에 350 명의 후보자를 테스트합니다. 테스트가 끝나면 각 후보자의 결과가 인덱스로 가득 찬 데이터웨어 하우스로 이동됩니다. 각 테스트마다 약 400 개의 레코드가 datawarehouse에 입력됩니다. 그래서 400 x 350은 많은 레코드입니다. 데이터웨어 하우스에 많은 레코드가 없으면 모두 잘됩니다. 그러나 데이터웨어 하우스에 이미 많은 레코드가있는 경우 많은 삽입이 실패합니다.많은 성능 지표를 가진 데이터웨어 하우스
끝날 때만 다시 작성되거나 실제 문제가 아닌 인덱스가있는 방법이 있습니까? ? 아니면 어떻게 해결할 수 있을까요?
정상화 된 데이터웨어 하우스와 Kimball 별 데이터웨어 하우스 모두에서 작업 했으므로 문제가되지 않습니다. 140000 행은 작은 데이터웨어 하우스에서도 많은 행이 아닐 것이라고 말하고 싶습니다.
삽입이 실패하는 이유는 무엇입니까? 일반적으로 Kimball 스타일의웨어 하우스에서는 삽입이 실패하지 않습니다. 예를 들어 팩트 테이블에서 삽입은 항상 차원 및 날짜 (또는 날짜 스냅 샷과 같은)에 관련된 고유 한 기본 키 집합을 갖습니다. dimmension 테이블에서 변경 사항이 감지되고 새 치수가 삽입되며 기존 치수가 재사용됩니다. 표준화 된 창고에서는 일종의 수정 메커니즘이나 아카이브 프로세스 또는 유효 날짜가있어 고유 한 것을 유지합니다.
DW 철학이나 아키텍처에 관계없이 이러한 행을 고유하게 유지해야하는 것처럼 보입니다.
(귀하의 의견에 명시된대로) 모든 열을 포함하는 단일 색인이있는 경우 모든 데이터베이스 설계에서 매우 유용한 색인이 아닐 수 있습니다. 모든 검색어에 대해 색인을 사용하고 있습니까? 그것은 또한 유일무이 한 것으로 표시되어 있으며 그 제약은 위반되고 있습니까? 어쨌든 꽤 큰 다중 컬럼 인덱스이며 비교할 때 상대적으로 비용이 많이들 것입니다. 이것은 타임 아웃이 될 수 있습니다. 연결에서 영원히 기다리지 않고 수정할 수는 있지만 문제를 공격 할 것입니다. 디자인 관점.
데이터웨어 하우징에서로드하기 전에 색인 및 제약 조건을 삭제하고 이후에 다시 작성하는 것이 일반적입니다. 제약 조건 (FK)을 없애려면로드 프로세스에서이를 처리해야합니다. 체크 제약 조건을 삭제하고 ETL 소프트웨어로 확인 유효성 검사를 이동하십시오.
140K는 많은 행이 아닙니다. 삽입물이 실패 할 때 테이블 디자인과 오류를 게시하십시오.
나는 다음과 같이 제안합니다 : 오늘 별도의 테이블에있는 것을 제외하고 모든 데이터를 유지하십시오 (히스토리라고 부름). 귀하의 리포트. 오늘의 데이터를 다른 별도의 테이블에 보관하고 (Today라고 말하면 됨) 자정에 작업을 실행하여 Today 테이블에서 History 테이블로 데이터를 이동하십시오. 오늘 테이블에서 - 삽입 성능을 향상 시키려면 최소한의 인덱싱이 있어야합니다. 이 디자인을 구현하면 보고서가 삽입으로 인해 혼잡하지 않게됩니다. 또한 두 개의 테이블을 용도에 맞게 조정할 수 있습니다. 일반적으로 빠른 삽입과 빠른 선택을 위해 테이블을 조정하는 것은 어렵습니다.
삽입이 '실패', 쿼리 실행 시간으로 인한 단순 시간 초과 또는 키 실패 등을 정의해야합니다. – Andrew
아직 알지는 못 하겠지만 타임 아웃이라고 확신합니다. –
사용중인 기술의 특성을 모른 채 구체적인 답변을 드릴 수는 없습니다. 아마도 "데이터웨어 하우스"솔루션이 잘못된 기술입니까? 몇 주 전에 몇 가지 흥미로운 질문/답변이있었습니다. –