SQL Server 2008에서 보관 된 엄청난 양의 레코드로 작업 할 때 가장 좋은 솔루션은 무엇입니까?

Question

.NET으로 온라인 상태가 아닌 ebanking 트랜잭션을 수집하는 프로젝트를 개발 중입니다. 전날 거래가 들어있는 텍스트 파일을 얻게 될 것입니다. 전체적으로 이것은 하루에 약 2,000,000 행을 포함합니다.

지난 달 트랜잭션 (최대 3 초)에서 검색하는 데 좋은 성능을 원하지만 이전 트랜잭션 (최대 30 초)에서 검색 할 수 있기를 원합니다. 아카이브 검색은 CardNumber, TransactionNumber 및 TransactionDate을 기준으로합니다. 아카이브 검색 시나리오가 정적이며 다른 열을 검색하거나 모든 종류의 보고서를 얻지 않기를 바랍니다.

저는 보관 전략을 생각하고 있습니다. 기본 테이블에

1. 튜닝과 최적화 인덱스 :

   몇 가지 옵션이 있습니다.

2. 주 테이블을 분할하는 중입니다.

3. 이전 트랜잭션을 야간에 다른 데이터베이스로 이동합니다.

4. 오래된 트랜잭션을 매 시간 (TextFile, XmlSerialization, BinarySerialization)으로 이동 한 다음 메모리에서 검색합니다.

5. 다른 오픈 소스 NON-RDBMS 데이터베이스 (텍스트 검색에서 Lucene 엔진과 같은)를 사용합니다.

우선이 시나리오에서 어떤 전략이 가장 적합한 지 알고 싶습니다.

또한 SQL Server 2008, Oracle, Sqlite, MySql 등과 같이 알려진 데이터베이스 엔진에서 지원하는 레코드 수는 얼마나됩니까? Table Partitioning은 언제 생각해야합니까?

Answer 1

필자는 파티션 분할이 아마도 월별 파티션 일 가능성이 가장 높다고 생각합니다. 이전 파티션을 전환하여 (시간이 지남에 따라 파일 그룹을 분리하고 읽기 전용으로 표시) 쿼리를 계속 사용할 수 있습니다. 하루 2MM 행은 그다지 거대한 것이 아니지만 동일한 파티션에서이 작업을 수집하는 경우 결국 일부 작업/쿼리는 결국 확장되지 않습니다. 클러스터 된 인덱스, 클러스터되지 않은 인덱스 및 분할 스키마/기능을 설정하는 방법에 대해서는 매우 신중해야합니다. 아직 파티셔닝에 익숙하지 않다면 익숙해지고 테스트/dev/준비 환경에서 프로덕션 환경에서 느슨하게하기 전에 숙련되고 익숙해 지도록 시간을 예산 책정하는 것이 좋습니다. This is probably a good a starting point as any이지만 공문서 이외에 실용적이고 실제적인 조언을 위해 블로그를 검색하는 데 두려움을 느끼지 마십시오.