db 'x'의 성능 또는 'x'에서 'y'로 이동하면 사이트 성능이 향상되었다는 논의가 많이 있습니다.
다른 유형의 데이터베이스에서 작동하는 적절한 벤치마킹을 아직 보지 못했습니다.
Relational, Document-oriented 등과 같은 여러 db 유형에 사용될 수있는 의미있는 벤치 마크를 작성할 수 있습니까?
그러한 벤치 마크를 어떻게 설계하겠습니까?
db 'x'의 성능 또는 'x'에서 'y'로 이동하면 사이트 성능이 향상되었다는 논의가 많이 있습니다.
다른 유형의 데이터베이스에서 작동하는 적절한 벤치마킹을 아직 보지 못했습니다.
Relational, Document-oriented 등과 같은 여러 db 유형에 사용될 수있는 의미있는 벤치 마크를 작성할 수 있습니까?
그러한 벤치 마크를 어떻게 설계하겠습니까?
답변:
그렇습니다 . 연구 한 사례에 대해 의미있는 벤치 마크를 작성하고주의 깊게 작성하고 특정 사례와 관련이있는 경우 다른 사례와 관련이 없을 수 있음을 이해하십시오. 동일한 유형의 데이터베이스 (관계형 데이터베이스와 다른 관계형 데이터베이스) 또는 다른 유형의 데이터베이스를 비교할 때도 마찬가지입니다.
아니요 , 모든 애플리케이션에서 모든 경우에 특정 데이터베이스가 다른 데이터베이스보다 훨씬 낫다는 것을 마술로 입증하는 벤치 마크를 작성할 수는 없습니다.
"데이터베이스에서 다른 데이터베이스로 이동하면 사이트 성능이 향상되었습니다"라고 말할 수 있습니다.
쿼리 및 쿼리 속도에 대한 충분한 정보를 수집하여 프로파일 링 또는 런타임 통계를 통해 이전 데이터베이스의 성능을 측정합니다.
응용 프로그램을 새 데이터베이스로 옮깁니다.
당신도 같은 조치를 취합니다.
당신은 비교합니다.
예를 들어, 2.834 초에로드 된 3182432 제품의 전체 목록이있는 경우. 오래된 데이터베이스에서 0.920 초에로드됩니다. 두 경우 모두 응용 프로그램에 캐시가 비어 있으면 새 데이터베이스에서이기는 것이 좋습니다. 새 데이터베이스는이 쿼리와 관련하여 사이트 성능을 향상 시켰습니다.
이제 성능 지표로 편향되었습니다.
동의, 새로운 쿼리가 더 빠릅니다. 그러나 DBA는 이전의 데이터베이스를 사용하는 방법을 알지 못했기 때문에 모든 제품을로드하는 쿼리가 최적화되지 않았습니다 . 그렇게 다시 작성하면 0.855 초에 해당 제품을로드 할 수 있습니다. 2.834 대신에.
좋아, 당신은 더 나은 결과가 있습니다. 그러나 데이터베이스를 3 년 전에 마지막 유지 관리 계획 이 실행 된 10 년 된 데이터베이스 와 플러시 한 최신 데이터 를 비교하는 것이 불공평하다고 생각하지 않습니까? 그런데 지난 4 년 동안 데이터베이스 제품 을 적어도 한 번 업데이트 했다고 생각하지 않습니까?
일부 쿼리가 더 빠릅니다. 일부는 느립니다. 새 데이터베이스로 이동할 때 전반적인 성능을 얻었음을 알기 위해 평균 결과를 어떻게 계산합니까? 3,182,432 개의 제품을 모두로드 할 때 빠릅니다. 그러나 관리자가 특정 작업을 수행 할 때 지난 10 년 동안 두 번만 수행 한 경우는 드물지만 웹 사이트에서 쿼리가 실행되는 것이 중요합니까? 반면에, 새로운 사용자에 대해 홈페이지에서 모든 쿼리를 실행하면 0.281이 낭비됩니다. 0.207 초였던 새로운 데이터베이스로. 이전 데이터베이스와 함께. 이 결과는 특히 쿼리를 오랫동안 캐시 할 수없고 하루에 수만 번 실행되기 때문에 훨씬 중요합니다.
두 데이터베이스는 동일한 서버 , 동일한 하드웨어, 동일한 구조 에서 테스트되어야합니다 . 예를 들어 하나의 하드 드라이브에서 하나의 데이터베이스를 테스트하고 다른 하나는 두 SSD의 RAID1에서 테스트 할 수 없습니다. 대규모 프로젝트를 새 데이터베이스로 마이그레이션 할 때 이전 데이터베이스가 여전히 이전 시스템에 남아있을 때 새로 배치 된 다른 랙 서버 100 대에 새 데이터베이스를 호스팅 할 가능성이 있습니다.
요약 하면 응용 프로그램의 데이터베이스 쿼리를 벤치마킹하고 정확한 메트릭을 얻을 수 있습니다. 그러나 숫자에 의미를 부여해야합니다. 이 상태에서는 사이트 성능이 향상되었다고 말하고 싶은 유혹이 있습니다. 그렇지 않으면 경영진이 단지 속도를 늦추기 위해 수천 달러와 수개월의 작업을 썼다는 사실에 화가납니다.
가장 끔찍한 실수는 벤치 마크에서 이러한 결론을 취하고 "Microsoft SQL Server가 Oracle보다 3 배 빠릅니다"와 같은 어리 석음을 결론 짓는 것입니다. "Java가 PHP보다 낫습니다"라고 말하는 것과 같습니다. 더 잘 정의하십시오. 어떤 경우에 더 좋습니까? 어떤 종류의 응용 프로그램에 적합합니까? 어떤 개발자 팀을 위해?
해석하고 일반화할수록 관련성이없고 의미가 없어집니다.
select [...]
file의 개정판 # 832에서 찾을 수있는 쿼리ProductFactory.cs
117 행은 0.5 초 미만으로 실행됩니다. 비 기능 요구 사항 부속서 M, 사례 3에 규정 된 조건 하에서 시험 될 때 새로운 데이터베이스로. 테스트 결과가 0.9..1.3 초 범위에있을 때 이전 데이터베이스와 동일한 요구 사항이 충족되지 않았습니다. 같은 조건에서.
개발자에게는 의미가 있으며 테스트 대상, 방법 및 결과를 알 수있을 정도로 정확합니다. 질문 번호 2에 답합니다.
안타깝게도 경영진에게는 의미가 없습니다. 대신 :
제품을 MySQL에서 최신 버전의 Microsoft SQL Server로 마이그레이션하면 제품의 전체 성능이 5 배 향상되어 동시에 2 배, 환경 설치 공간은 3 배 줄어 듭니다. 내년에 모든 응용 프로그램을 Microsoft SQL Server로 마이그레이션하면 더 나은 결과를 얻을 수 있고 시장 경쟁력이 향상 될 것입니다.
순수 마케팅 지버 재버이며 기술적으로 아무 의미가 없지만 놀랍게도 관리 및 마케팅 부서에 가치가 있습니다.
마지막으로, 다른 유형의 데이터베이스를 비교할 수 있습니까? 나는 그것이 완전히 가능하다고 말합니다. 큰 사진을 호스팅하는 웹 사이트가 있다고 가정 해 봅시다. 이 사진들은 varbinary(max)
Microsoft SQL Server 2005에 저장되어 있으므로 사용할 수 없습니다 filestream
. 사진을로드 할 때의 성능이 걱정되므로 파일 시스템을 새 데이터베이스로 사용하여 사진을 파일로 저장하기로 결정했습니다. 먼저, 해당 파일은 데이터베이스와 동일한 시스템에 저장됩니다. 새 솔루션을 프로파일 링하고 필자의 경우 파일이 Microsoft SQL Server보다 파일 시스템에서 4 % 더 빠르게로드되는 결과를 얻습니다. 벤치 마크는 매우 분명합니다. 이제 Microsoft SQL Server에 최적화 된 서버를 사용하지 않고 직접 파일 스토리지에 최적화 된 전용 서버를 배포 할 수 있습니다.
아닙니다. 그들 사이의 차이점은 하나의 벤치 마크가 바이어스되도록하는 것입니다.
즉, 광범위한 테스트를 포함하고 테스트 (특정 언어 별 또는 여러 언어의 복합 테스트)를 쉽게 비교할 수있는 Computer Language Benchmarks Game 과 같은 사이트를 개발 하면 이점이 있습니다. 커뮤니티가 솔루션을 제출하고 스키마 또는 쿼리의 단점을 개선 할 수 있도록 설정 한 경우 특히 그렇습니다.
DB 벤치 마크 사이트의 경우 (언어 슛 아웃의 경우와 같이) 알고리즘을 구현하는 대신 테스트는 특정 제약 조건에 따라 저장 한 다음 검색해야하는 원시 데이터로 구성 될 수 있습니다. 예를 들어, 커뮤니티 라이브러리가 후원자와 서적을 추적하는 데 사용할 수있는 것을 나타내는 간단한 스키마를 나타내는 정보를 포함하는 원시 데이터 세트가있을 수 있습니다. 각 DB는 1 백만 개의 레코드를 모두 저장 한 다음 제약 조건을 충족하는 일부 하위 데이터 집합을 검색해야합니다. 그런 다음 1 억 개의 레코드를 포함하는 매우 간단한 구조 / 관계 (ESPN 등의 사이트에 일반적으로 사용되는 주석 시스템 일 수 있음)를 나타내는 데이터 세트가있을 수 있으며 수행해야하는 자체 쿼리 세트가 있습니다. . 기타.
최소한 복잡한 데이터부터 간단한 관계, 작은 세트에 이르기까지 광범위한 데이터 세트에서 DB를 테스트하면 프로젝트와 유사한 품질을 가진 데이터의 일반적인 경향을 볼 수 있기 때문에 매우 유용 할 수 있습니다. 현재 평가 중입니다.
모든 유형의 데이터베이스를 벤치마킹 할 수없는 이유를 몇 가지 더 추가하고 싶습니다.
데이터베이스 시스템에는 OLAP 및 OLTP의 두 가지 주요 방향이 있습니다 ( 비교 참조 ).
말했듯이 관계형 및 문서 지향 데이터베이스 시스템도 있습니다. RDBS는 ACID 원칙을 엄격하게 준수하지만 대부분의 문서 지향 DBS에서는 약한 데이터가 응용 프로그램에 충분하다고 판단 할 수 있습니다. 따라서 잠금 및 예약이 훨씬 쉬워집니다.
요약하자면 , 람보르기니는 세계에서 가장 좋은 차 라고 주장하지는 않을 것 입니다 . 트렁크 볼륨, 좌석 수 또는 마일리지를 생각하십시오.
참고로 다음 은 OLTP 데이터베이스 시스템의 벤치 마크입니다.