SQL Server 2008 R2에 대한 삽입이 RAM에 먼저 캐시되도록하려면 어떻게해야합니까?

"버스트 (burst)"한 데이터 스트림을 상상해보십시오. 즉, 10,000 개의 이벤트가 매우 빠르게 도착한 후 1 분 동안 아무것도 없을 수 있습니다.

전문가의 조언 : SQL 서버에 C # 삽입 코드를 작성하여 SQL이 데이터를 해당 RAM에 공급하는 데 걸리는 것 이상으로 앱을 차단하지 않고 자체 RAM에 모든 것을 즉시 캐시하도록 보장하려면 어떻게해야합니까? 이를 달성하기 위해 SQL 서버 자체 설정 패턴이나 내가 쓰고있는 개별 SQL 테이블을 설정하는 패턴을 알고 있습니까?

물론 RAM으로 자체 큐를 구성하는 자체 버전을 수행 할 수는 있지만 구석기 석재 도끼를 재발 명하고 싶지 않습니다.

글쓰기를 시도하고 어떤 일이 일어나는지 보셨습니까? 병목 현상이 있습니까?

앱이 차단되는 것을 방지해야하는 경우 데이터베이스 호출을 지연시키기 위해 쓰기를 대기시키는 방법이 있습니다. 그러나 대기열이 1 초 또는 2 초 안에 지워질 것으로 기대합니다. 이것이 정상이라면 대기열이 필요합니까?

아니면 준비 테이블에 스풀링 한 다음 나중에 플러시 할 수 있습니까? 우리는이 기술을 사용하여 분당 수백만 개의 새로운 행을 지속적으로 기록합니다 (실제로는 간단한 복구로 스테이징 DB를 사용합니다). 그러나 행을 작성하는 경험이있을 때까지는 구현하지 않았습니다.

참고 : SQL Server의 모든 쓰기가 됩니다 쓰기 앞서 로깅 (WAL) 프로토콜의 한 부분으로 디스크를 할 이동합니다. 이것은 해당 쓰기에 대한 t-log 항목에 적용됩니다.

행이있는 데이터 페이지는 특정 시점 (시간, 사용, 메모리 부족 등)에 따라 디스크로 이동하지만 일반적으로 데이터는 메모리에 있습니다. 이것을 "Checkpointing"이라고하며 메모리에서 데이터를 제거하지 않고 변경 사항을 플러시합니다 (2011 년 11 월 24 일 편집)

편집하다:

위의 마지막 단락을 기준으로 전반적으로 고려해야 할 사항은 성능 향상을 위해이 데이터베이스의 LDF를 전용 디스크 세트로 옮기는 것입니다. 준비 데이터베이스를 분리합니다 (MDF / LDF마다 하나씩). 데이터베이스 서버에 12 개 또는 3 개의 다른 볼륨 (일반적으로 SAN을 통해)이있는 것이 일반적입니다.

내가 빠진 것이 아니라면 이것은 ACID ( http://en.wikipedia.org/wiki/ACID ) 의 내구성 요구 사항을 위반하는 것 입니다. 즉, 응용 프로그램이 데이터를 RAM에 "쓰기"한 다음 서버가 충돌하면 데이터가 손실됩니다.

따라서 원하는 것은 데이터베이스에 최종 저장을위한 큐 역할을하는 비 데이터베이스 시스템이거나 수행중인 작업에 충분히 빠른 데이터베이스 시스템입니다. 나는 후자를 먼저 시도하고 그것이 충분한 지 알아볼 것을 제안한다. 문제를 빌리지 마십시오.

한 번 Dataset을 사용했습니다. 도착했을 때 데이터 세트에 행을 삽입하고 있었고 2 초마다 행을 데이터베이스에 플러시하는 다른 스레드가있었습니다. xml 문서를 사용하여 cachin을 수행 한 다음 한 번의 호출로 xml을 데이터베이스에 전달할 수도 있습니다.

문안 인사

피오트르