2011-02-17 5 views
2

가능한 한 효율적으로 데이터베이스에 삽입하려는 대량의 지속적으로 들어오는 데이터 (분당 10,000 개 이상 증가)가 있습니다. 지금은 준비된 insert 문을 사용하고 있지만 SqlBulkCopy 클래스를 사용하여 더 큰 청크로 데이터를 가져올 생각입니다.빠른 삽입; 관계형 데이터를 사용한 대량 복사

문제는 단일 테이블에 삽입하지 않는다는 것입니다. 데이터 항목의 요소는 수많은 테이블에 삽입되며 ID 열은 동시에 삽입되는 다른 행의 외래 키로 사용됩니다. 나는 대량 복사가 이와 같은 복잡한 삽입을 허용하지 않는다는 것을 이해하지만 uniqueidentifier 열에 대해 내 ID 열 (이 경우에는 bigints)을 교환 할 가치가 있는지 궁금합니다. 이렇게하면 각 테이블에 대해 대량 복사를 할 수 있으며 삽입 전에 ID를 확인할 수 있으므로 SCOPE_IDENTITY와 같은 항목을 확인할 필요가 없으므로 대량 복사를 사용할 수 없습니다.

실용적인 솔루션처럼 들리거나 내가 직면 할 수있는 다른 잠재적 인 문제가 있습니까? 또는 데이터를 빠르게 삽입 할 수있는 또 다른 방법이 있지만 bigint ID 열의 사용을 유지하고 있습니까?

감사합니다.

답변

1

"SQL prep [GUID 서로 게이트 키 할당] 방법론을 사용하여"SQL이 [bigint identity() 열] 대리 키 "를 교환 할 계획 인 것 같습니다. 즉, 키는 SQL 내에서 할당되지 않고 SQL 외부에서 할당됩니다. 귀하의 볼륨을 감안할 때, 데이터 생성 과정 대리 키를 할당 할 수 있다면 분명히 그와 함께 갈 것입니다.

다음 질문은 GUID를 사용해야합니까, 아니면 데이터 생성 프로세스에서 자동 증가 정수를 생성 할 수 있습니까? 일관되고 틀림없이 작동하는 프로세스를 만드는 것은 어렵습니다 (SQL Server에 대해 $$$을 지불해야하는 이유 중 하나입니다). 그러나 데이터베이스 내에서 작고 읽기 쉬운 키에 대한 절충이 그만한 가치가있을 수 있습니다.

+1

"일관되고 틀림없이 작동하는 프로세스 만들기는 어렵습니다." 사실,하지만 데이터베이스 외부의 단일 비공유 응용 프로그램에서이 작업을 수행하는 경우 훨씬 쉽습니다. 경합 없음, 경합 조건 없음, 트랜잭션 없음. –

+0

GUID를 시도한 결과 성능이 10 배 향상되었습니다 (초당 10,000 개 삽입). :) – Barguast

3

uniqueidentifier는 페이지 나누기와 더 넓어 질 가능성이 있습니다.

  • 당신이 저장 프로 시저
  • 사용 A와 한 번에 실제 테이블에 준비 테이블을
  • 부하를로드 : 귀하의 부하가/일괄 처리 할 수있는 경우, 하나의 옵션을 this

    을 참조하다 각 배치에 대한 스테이징 테이블의 uniqueidentifier

초당 약 50k 행의 피크를 처리합니다. 우리는 실제로 별도의 준비 데이터베이스를 사용하여 이중 트랜잭션 로그 쓰기를 방지합니다.)

+0

순차적 GUID (일명 .COMB)를 사용하여 C#에서 생성 된 것으로 실험 중이므로 링크에서 클러스터 된 인덱스 문제를 해결해야한다고 생각합니다. 처음에는 GUID PKs가있는 행을 저장 한 다음 IDENTITY PK가있는 테이블로 전송한다는 가정용 테이블 준비 아이디어가 마음에 들었습니다. 그러나 ID 열을 가져와야하기 때문에 많은 INSERT 작업을 수행해야합니다. 아마 나는 오해하고있다. – Barguast

+1

@Bargauast : 단일 배치 (일부는 SQL BulkCopy에서, 일부는 위험 엔진에서 생성 된 것)를 식별하기 위해 GUID를 사용합니다. 그런 다음 bigint 클러스터 키를 사용하여 주 테이블로 플러시합니다.GUID는 클러스터 된 키가 아니며 주 테이블로 플러시 할 데이터의 일괄 처리를 추적하는 방법 일뿐입니다. 순차적이든 아니든간에 GUID는 여전히 16 바이트이며, 이로 인해 수십억 개의 행이 추가됩니다. – gbn