웹용 SQL Server 확장(단일 기록기 다중 판독기)

Question

다중 판독기 단일 기록기 방식으로 SQL Server를 확장한 경험이 있는 사람이 있습니까?읽기 집약적인 웹 애플리케이션에 대한 적절한 대안을 제안할 수 없는 경우, 경험이 있는 사람이 있어야 합니다.

Answer 1

아마도 두 가지에 따라 다릅니다.

1. 각 단일 쓰기는 얼마나 큰가요?
2. 독자는 실시간 데이터가 필요합니까?

글은 글을 쓸 때 독자를 차단하지만 각 글쓰기가 작고 빠르면 독자는 눈치 채지 못할 것입니다.

예를 들어, 하루 종일보고를 오프로드하면 독자가 실시간 데이터가 필요하지 않기 때문에로드를 별도의 서버에 배치합니다. 이것은 의미가 있습니다

기본 서버에 쓰기는 오프로드 보조 서버와 동기화되어야합니다. 어쨌든 동기화 프로세스의 일부로 차단됩니다.

대부분의 앱은 어쨌든 항상 95%+ 읽기입니다. 예를 들어, 업데이트 또는 삭제는 읽기와 쓰기가 뒤 따릅니다.

내 선택은 (아마도 저술량이 적고 웹 앱을 기준으로) 일 것입니다. 위로 데이터베이스의 데이터 및 로그 파일에 대한 별도의 디스크 경로가있는 DB 서버에서 가능한 많은 RAM.

Answer 2

시나리오를 위해 SQL Server를 확장 한 경험이 없습니다. 그러나 읽기 집약적 인 응용 프로그램의 경우 데이터베이스의 부하를 줄이고 다음과 같은 것을 사용하여 캐시 전략을 사용하려고합니다. Memcache 또는 MS 속도

내가 알고있는 두 가지 접근법이 있습니다.

1. 전체 데이터베이스를 캐시에로드하고 캐시에서 항목 추가 및 업데이트를 관리하십시오.

2. 요청이있을 때만 캐시에 항목을 추가하고 쓰기 작업이 수행 될 때 제거하십시오.

Answer 3

어떤 종류의 복제가 트릭을 수행할 것입니다.
http://msdn.microsoft.com/en-us/library/ms151827.aspx

물론 앱 코드를 변경해야 합니다.

어떤 사람들은 뷰와 통합되어 서로 다른 서버에 서로 다른 행 범위가 저장되는 분할된 테이블을 사용합니다.이는 앱에 표시되지 않습니다.내 생각엔 이 연습을 위한 연맹인 것 같아요.

데이터베이스, 애플리케이션 및 서버 구성(SQL 세부 사항 - 데이터/로그/시스템/SQL 바이너리/tempdb의 위치)을 설계하면 꽤 좋은 로드를 처리할 수 있습니다.꼭 필요하지 않다면 일을 복잡하게 만들지 마십시오.