시나리오에 가장 적합한 데이터 저장소는 무엇입니까?

데이터베이스에서 업데이트 / 선택 쿼리를 매우 많이 실행하는 응용 프로그램을 작성 중입니다.

기본 테이블 (A)가 있는데 하루에 약 500 개의 레코드가 있습니다. 그리고 시스템의 모든 사용자에 대해이 엔티티의 변형은 사용자의 일부 환경 설정을 기반으로 작성되며 다른 테이블 (B)에 저장됩니다. 이것은 매일 자정에 실행되는 크론 작업에 의해 수행됩니다.

따라서 테이블 A에 10,000 명의 사용자와 500 개의 레코드가있는 경우 해당 날짜에 대해 테이블 ​​B에 5M 레코드가 있습니다. 나는 항상이 테이블에 하루 동안 데이터를 보관하고 자정에 히스토리 데이터를 HBase에 보관합니다. 이 설정은 제대로 작동하며 지금까지 성능 문제가 없습니다.

최근 비즈니스 요구 사항이 약간 변경되어 이제 기본 테이블 A의 일부 속성 (15-20 개 레코드)이 20 초마다 변경되며 테이블 B의 모든 변형 레코드에 대한 일부 값을 다시 계산해야합니다. 모든 사용자들. 20 개의 마스터 레코드 만 변경하더라도 20 초 이상 걸리는 200,000 개의 사용자 레코드를 다시 계산하고 업데이트해야합니다. 그 후 다음 업데이트가 발생하여 결국 모든 Select 쿼리가 대기 상태가됩니다. 온라인 사용자로부터 약 3 건의 요청 받기 / 5 초가 발생하여 6-9 개의 Select 쿼리가 발생합니다. API 요청에 응답하기 위해 항상 표 B의 필드를 사용합니다.

더 많은 처리 능력을 구매하고이 상황을 해결할 수 있지만 수백만 명의 사용자를 처리 할 수있는 적절한 규모의 시스템을 보유하고 싶습니다.

여기 아무도 더 나은 대안을 제안 할 수 있습니까? nosql + 관계형 데이터베이스가 여기에 도움이됩니까? 잠금없이 데이터를 자주 업데이트 할 수있는 플랫폼 / 데이터 저장소가 있습니까?

테이블 B이 일종의 캐시 인 것 같습니다. 그러나 이런 종류의 캐시는 생산성을 저하시킵니다.

초당 25 개의 쿼리가 있어도 테이블 사용을 거부하고B 각 요청에 대한 답변을 계산할 수 있습니다.

어쨌든 , 20 레코드를 업데이트하는 데 30 초 지연이 발생하면 소프트웨어 아키텍처에서 실패합니다 (DB가 모든 레코드에 대해 처음 10 ^ 100 개의 PI 신호를 계산하는 경우 잘못되었습니다).

알다시피, 추악한 SQL 쿼리, 인덱스 및 1000000 미만의 레코드가있는 관계형 DB는 거의 모든 쿼리에 완벽하게 작동합니다.

테이블 사용을 거부 B하고 테이블 에 적절한 인덱스를 추가하십시오 A(대부분의 최신 데이터베이스에는 도우미 도구가 있습니다). 다음 : A계산 속도를 높이기 위해 데이터 구조 (table )와 쿼리 (쿼리 분석기 또는 SQL 전문가 사용) 를 최적화하십시오 . 레코드를 20 개만 업데이트 할 경우 인덱스가 있어도 업데이트 프로세스의 생산성에는 영향을 미치지 않지만 선택 속도는 크게 향상됩니다 .

문제는 실제로 시스템이 B에 삽입 할 레코드와 B 데이터의 크기를 계산하는 것입니다.

모든 데이터베이스 (예 : MSSQL)는 객체가 크지 않다고 가정 할 때 문제가없는 삽입 량을 처리 할 수 ​​있어야합니다.

업데이트는 더 어려운 문제 일 수 있지만 올바른 인덱싱 및 잠금을 사용하면 큰 문제는 아닙니다.

B 레코드가 저장 프로 시저에 의해 계산되기 때문에 이와 같은 문제가 발생하는 시간의 99 %. 이것은 모든로드를 db 서버에 둔다

이 경우 해결 방법은이 코드를 큐 시스템을 통해 호출 할 수있는 오프라인 서비스로 옮기는 것입니다.

따라서 업데이트 A 메시지는 작업자 프로세스를 트리거하여 사용자를 반복하고 각 사용자에 대한 업데이트 B 메시지를 만듭니다.

두 번째 작업자 프로세스 B는 데이터 A 이벤트로 업데이트 사용자 X를 가져 와서 B 레코드를 작성하고 DB를 업데이트합니다.

대기열 작업자가있는 상자를 더 추가하여 확장 할 수 있으므로 계산 뒤에 처리 능력이 점점 더 많아지고 db가 업데이트 및 선택에 집중할 수 있습니다.

업데이트 / 삽입에서 선택 항목을 분리하여 추가로 최적화 할 수 있습니다. 모든 선택 요청을 복제 슬레이브로 가져 오는 새 DB가 있고 모든 업데이트를받는 이전 DB가 있습니다.

Amazon에서 실행중인 경우 DynamoDB를 고려합니다. 플래시 메모리 기반입니다. : 여기에 대한 링크입니다 https://aws.amazon.com/dynamodb/가 .

어떤 종류의 RDBMS를 사용하고 있습니까? 보기에서 UDF 또는 계산 된 필드를 사용하여 성능을 향상시킬 수 있습니다. 단일 업데이트 쿼리를 통해 데이터베이스에서 계산을 실행하거나 데이터베이스에서 데이터를 선택하고 다른 프로세스에서 계산을 실행 한 다음 다시로드합니까?

Oracle은 기본적으로 스냅 샷 모드 실행을 사용하도록 구성됩니다. 즉, 업데이트 중에 행이 잠기지 않고 동시 선택이 원래 값을 얻습니다. SQL Server는 기본적으로 비관적 동시성으로 구성되므로 업데이트가 완료 될 때까지 동시 선택이 차단됩니다. 일부 버전의 SQL Server는 스냅 샷 모드로 전환 될 수 있지만 임시 테이블에 대한 스트레스가 크게 증가합니다.

어떤 환경에서 활동하고 있습니까? Amazon의 EC2 인스턴스에있는 RDBMS 인 경우 DB 데이터 파일을 로컬 플래시 디스크에 저장하십시오. 파일을 EBS에서 로컬 디스크로 옮기는 데있어 차수의 차이가 있습니다.