Sqlserver 높은 동시성 및 빅데이터 스토리지 솔루션

사용자 수가 증가하고 일일 활동 및 최고 가치가 급증함에 따라 데이터베이스 처리 성능은 큰 과제에 직면해 있습니다. 피크 값이 100,000 이상인 실제 플랫폼에 대한 데이터베이스 최적화 계획을 공유해 보겠습니다. 모두와 토론하고, 서로 배우고 발전해보세요!

사례: 게임플랫폼.

1. 높은 동시성 해결

클라이언트 접속량이 정점에 도달하면 서버에서 접속 유지 및 처리가 불가능해집니다. 당분간 여기에서 논의하겠습니다. 여러 쓰기 요청이 데이터베이스에 전송되면 이때 여러 테이블을 삽입해야 하며, 특히 하루에 수천만 개의 데이터를 저장하는 일부 표현식은 시간이 지남에 따라 동기식으로 데이터를 쓰는 전통적인 방식은 분명히 권장되지 않습니다. After Experiments는 비동기식 삽입을 통해 많이 개선되었지만 동시에 데이터를 읽는 실시간 성능에 대해서는 일부 희생이 필요했습니다.

많은 비동기 방식이 있습니다. 현재 방식은 작업을 통해 임시 테이블에서 실제 테이블로 데이터를 일정한 간격(요구 사항 설정에 따라 5분, 10분...)으로 전송하는 것입니다.

1. 원본 테이블 A가 있는데, 이 테이블도 실제로 읽을 때 사용되는 테이블입니다.

2. 데이터 전송 처리를 위해 원본 테이블 A와 동일한 구조로 B와 C를 생성합니다. C->B->A.

3. 데이터를 동기화하는 Job1과 Job1의 실행 상태를 기록하는 테이블을 설정합니다. 동기화 시 가장 중요한 것은 B의 데이터가 현재 동기화 중인지 확인하는 것입니다. 서버의 데이터는 C에 저장된 후 B로 가져옵니다. 이 데이터 배치는 다음 작업이 실행될 때 A로 전송됩니다. 그림 1과 같이:

동시에 안전을 보장하고 문제 해결을 용이하게 하기 위해 전체 데이터베이스 인스턴스를 기록하는 저장 프로시저를 사용하여 작업 수행 시간이 단축됩니다. 비정상적인 오류가 발생하면 다른 방법을 통해 관련 담당자에게 즉시 알려야 합니다. 예를 들어, 이메일 및 SMS 테이블에 쓰고, Tcp 알림 프로그램이 정기적으로 읽고 보내도록 하는 등의 작업을 수행합니다.

참고: 하루의 데이터가 수십 G에 도달하고 이 테이블에 대한 쿼리 요구 사항이 있는 경우(파티셔닝은 아래에 언급됨) 가장 좋은 전략 중 하나는 다음과 같습니다.

B를 여러 서버로 동기화할 수 있어 쿼리 부담을 공유하고 리소스 경쟁을 줄일 수 있습니다. 예를 들어, 전체 데이터베이스의 리소스는 제한되어 있으므로 삽입 작업은 먼저 공유 잠금을 획득한 다음 클러스터형 인덱스를 통해 특정 데이터 행을 찾은 다음 이를 의도적 잠금으로 업그레이드해야 합니다. 잠금을 유지하기 위해 데이터 크기에 따라 다른 잠금을 적용하여 리소스 경쟁을 유발합니다. 따라서 읽기와 쓰기는 최대한 분리되어야 하며, 이는 비즈니스 모델이나 정해진 규칙에 따라 구분될 수 있으며, 플랫폼 기반 프로젝트에서는 데이터가 효과적으로 삽입될 수 있도록 하는 것이 우선시되어야 합니다.

빅 데이터를 쿼리하면 필연적으로 많은 리소스가 소모됩니다. 일괄 삭제가 발생하는 경우 이러한 문제가 발생하지 않도록 순환 일괄 처리 방법(예: 한 번에 2000개 항목)으로 전환할 수 있습니다. 프로세스로 인해 전체 라이브러리가 중단되어 예측할 수 없는 버그가 발생합니다. 연습 후에는 효과적이고 실행 가능하지만 저장 공간만 희생할 뿐입니다. 테이블에 많은 양의 데이터가 포함된 필드는 쿼리 요구 사항에 따라 새 테이블로 분할될 수도 있습니다. 물론 각 비즈니스 시나리오의 요구 사항에 따라 설정해야 하며 적합하지만 화려하지 않은 솔루션을 설계할 수 있습니다.

2. 스토리지 문제 해결

한 테이블의 데이터가 매일 수십 기가바이트에 도달한다면 스토리지 솔루션을 개선하는 것이 당연합니다. 이제 치솟는 데이터의 파괴에도 불구하고 최전선에 머물겠다는 나만의 계획을 공유하고 싶습니다! 다음은 내 환경에 대한 소박한 의견을 공유하는 예입니다.

기존 데이터 테이블 A는 단일 테이블에 매일 30G의 데이터가 추가되고 저장 중에 일부 테이블은 데이터를 지울 수 없습니다. 파티셔닝을 수행하면 파일 그룹을 파일 그룹으로 나누고 파일 그룹을 다른 디스크에 할당하여 IO 리소스에 대한 경쟁을 줄이고 기존 리소스의 정상적인 작동을 보장할 수도 있습니다. 이제 5일 동안 기록 데이터를 유지하기 위한 요구 사항을 결합합니다.

1. 이때 작업을 사용하여 사용자 ID 또는 시간 필드 기반 파티셔닝과 같은 파티션 기능을 기반으로 파티션 계획을 생성해야 합니다. ;

2. 테이블 이동 파티셔닝 후 해당 인덱스를 통해 쿼리를 통해 특정 파티션을 빠르게 찾을 수 있습니다.

3. 불필요한 파티션 데이터를 동일한 구조로 테이블로 옮깁니다. 작업 병합 파티션을 통해 이 테이블의 데이터를 지웁니다.

그림 2와 같이:

SQL 쿼리 추적을 통해 긴 쿼리 시간을 캡처하고 SQL 자체 저장 프로시저 sp_lock을 사용하거나 dm_tran_locks 및 dblockinfo 보기를 봅니다. 현재 인스턴스에 존재하는 잠금 유형 및 세분성입니다.

특정 쿼리문이나 저장프로시저를 찾은 후, 맞는 약을 처방해보세요! 약이 질병을 치료한다!

위 내용은 이 글의 전체 내용입니다. 이 글의 내용이 모든 분들의 공부나 업무에 조금이나마 도움이 되었으면 좋겠습니다. 저도 PHP 중국어 홈페이지에 지원하고 싶습니다!

Sqlserver 높은 동시성 및 빅데이터 저장 솔루션에 관한 더 많은 기사를 보려면 PHP 중국어 웹사이트를 주목하세요!