디스크에 스토리지가 있다고 가정할 때 단일 데이터베이스 서버(마스터-슬레이브 아키텍처 없음)에 대한 대략적인 성능 제한(읽기/초, 쓰기/초)은 무엇입니까? 디스크 종류에 따라 읽기/초, 쓰기/초는 몇 개입니까? (SSD 대 비 SSD) 간단한 작업을 가정합니다(기본 키로 한 행 선택, 한 행 업데이트, 올바르게 인덱싱됨). 이 제한은 디스크 검색/쓰기에 따라 다르다고 가정합니다.
편집: 제 질문은 데이터베이스가 지원하는 작업 수에 대한 대략적인 측정 기준을 얻는 것에 관한 것입니다. 예를 들어 초당 300개의 삽입을 트리거하는 새로운 기능이 추가 서버로 확장하지 않고도 지원될 수 있는지 알 수 있습니다.
답변1
많은 벤치마크 결과를 읽을 수 있습니다.여기마치 그 웹사이트가 믿을 만한 출처인 것처럼 말이죠.
답변2
귀하의 질문에 대한 답을 얻기 위해 테스트해 보시길 강력히 권하고 싶습니다. 윈도우가 실행 중이라면SSIO.exe개발 상자에서 디스크 성능 테스트를 수행하여 아무것도 수행하지 않는 방식을 이해합니다.
그런 다음 성능 모니터를 실행합니다(아마도 Oracle의 MS-SQL TKProf에 있다고 가정합니다. mysql이나 다른 도구를 사용하지 마십시오. 죄송합니다. 비슷한 도구가 있을 것입니다.) 쿼리를 실행하고 읽기/쓰기 횟수와 수행하는 데 소요된 CPU 양을 살펴보세요. 그것. 그런 다음 SSIO 및 성능 모니터 수를 비교하고 하드웨어 요구 사항을 확장하여 현재 장비를 기반으로 이 업데이트에 필요한 사용자 수/빈도를 처리할 수 있습니다.
300개의 행은 상당히 느린 디스크에서도 합리적인 SQL Server에 대해 변경되는 매우 적은 수의 행입니다. 대규모 복합 인덱스나 블롭 등이 없는 한 사용자가 상대적으로 적당한 하드웨어에서 1초도 안 되는 시간에 실행되는 150만 행을 생성하는 쿼리를 볼 때 프로세스가 진행 중입니다.
답변3
너캔트앱을 벤치마킹하지 않고 판단하고 로드하세요.
이는 RAID 레벨, 스핀들 속도, 트랜잭션 크기(단순히 "삽입"이 아님), 트리거, 외래 키, 하이퍼스레딩, 서버의 기타 앱, 서버의 RAM, 디스크 배열 방법(tempdb에 대한 별도의 볼륨, DB t-log, MDF 등), 서비스 팩 수준, RAID 컨트롤러 캐시 구성, CPU Ls + L3 캐시, 코어 수, 스키마 설계, 코드...
확장하는 것보다 확장하는 것이 더 쉽습니다. 서버나 파티션 테이블을 연합하는 경우 오버헤드가 추가됩니다. RAM과 스핀들을 추가하는 것이 더 저렴합니다.
좋은 글은폴 닐슨의 35,000 TPS. 300보다 최소 100배 더 높은 부하입니다.