프로토 타입 데이터베이스 디자인의 함정 (성능 생존력 테스트 용)

Question

my previous question에이어서, 개체 모델의 다양한 잠재적 인 스키마 표현에 대한 성능 테스트를 수행하려고합니다. 그러나 모델이 개념적으로 완료되었지만 아직 실제로 마무리되지 않았기 때문에 각 테이블의 정확한 테이블 수와 숫자/유형의 특성이 명확하지 않습니다.

필자의 생각으로는 각 접근법에 대해 대표적인 프로토 타입 모델을 조합하여 각각의 경우에 가장 빠른 접근 방법을 결정하기 위해 각각의 성능을 테스트 할 수있는 것처럼 보입니다.

그리고 그 질문이 들어 있습니다. 데이터베이스의 성능 특성이 매우 직관적이지 않아서 작은 (심지어 "사소한") 변경으로 인해 큰 차이가 발생할 수 있음을 알고 있습니다. 따라서 더미 테이블 구조를 설정하고 더미 데이터로 채울 때 일반적으로 발생할 수있는 함정이 무엇인지 궁금합니다. 환경이 큰 차이를 만들 가능성이 있기 때문에 대상은 RHEL 3에서 실행되는 Oracle 10.2.0.3.0입니다.

(특히, 다음 중 하나와 같은 예를 찾고 있습니다. 다른 것보다 훨씬 더 선택적인 색인을 가지고 있습니다; "아래에 x 개의 행/열이 있어야합니다. 왜냐하면이 아래에서 페이지 오류가 발생하지 않고 성능이 달라지기 때문에"; "DATETIME 데이터 유형 쿼리 계획을 크게 바꿀 것이기 때문에이 도구를 사용하게 될 것입니다. "등등.이 영역의 모범 사례에 대한 많은 페이지/블로그 게시물이있을 것이라고 기대했지만 Google을 사용해 보았지만 나무를 찾을 수 없었습니다. 나무 대신 (기존 DB의 성능 튜닝에 관한 페이지가 많이 있습니다.)

참고로, 필자는 "결과의 전이성에 대해 어느 정도 확신을 갖고 이와 같은 테스트를 수행하는 것이 현실적이지 않은 경우"라는 라인을 따라 대답을 기꺼이 받아들입니다.

Answer 1

성능 목표를 달성하기 위해 자신을 위치시킬 수있는 몇 가지 사항이 있습니다. 나는 그들이 순서로 일이 생각 :

1. 는 아키텍처, 모범 사례 및 패턴 인식
2. 추가 정밀도를 얻거나 이상한 디자인의 영향을 결정하기 위해 데이터베이스가
3. 현장 테스트 성능을 작동하는 방법을 알고 있어야 지역 각

더 :

1. 아키텍처, 모범 사례 패턴 : 데이터베이스를 수행하지 못하는 가장 보편적 인 이유 중 하나는 데이터베이스를 작성하는 사람들이보고 도메인에 완전히 익숙하지 않다는 것입니다. 이들은 트랜잭션 데이터베이스 도메인의 전문가 일 수 있지만 해당 도메인의 기술은웨어 하우스 /보고 도메인으로 변환되지 않습니다. 따라서 도메인을 잘 알아야합니다. 그렇다면 거의 언제나 올바르게 작동 할 수있는 적절한 접근 방식을 신속하게 파악할 수있을 것이며, 거기에서 조정할 수 있습니다.

2. 데이터베이스 작동 방법 : 일반적으로 옵티 마이저/플래너가 쿼리에 대해 갖는 옵션을 이해해야합니다. 인덱스를 추가하는 다른 문장에 미치는 영향은 무엇입니까? 256 바이트 varchar를 인덱싱하면 어떤 영향이 있습니까? 보고 쿼리에서도 색인을 사용합니까?

3. 이제 올바른 접근법을 얻었고 모델의 90 %가 어떻게 수행되는지 이해 했으므로 대부분의 중소 규모 데이터베이스에서 성능을 예측하는 경우가 많습니다. 당신이 거대한 것을 가지고 있다면, 엄청난 돈이 걸릴 것입니다. 더 많은 하드웨어를 주문해야 할 수도 있고, 디자인에 이상한 점이있을 수도 있습니다. 합리적인 테스트 데이터 및 프로덕션 환경에서 볼 수있는 (중요한) 통계를 생성하십시오. 그리고 데이터베이스가 그 데이터로 무엇을 할 것인지 알아 봅니다. 실제 데이터와 실제 크기의 서버가 없다면 아직 추정해야하지만, 적어도 합리적으로 가까운 서버를 확보 할 수 있어야합니다.

Answer 2

개념 모델의 다양한 추정 구현에 대한 성능 테스트는 영웅적으로 생각만큼 순진하지 않습니다. 아아, 시간 낭비라고 생각합니다.

데이터를 예로 들어 봅시다. 아마 테이블을 채우기 위해 임의의 데이터를 생성하려고합니다. 그러면 쿼리가 대량으로 얼마나 잘 수행되는지 알 수 있습니다. 그러나 종종 성능 문제는 데이터의 왜곡의 산물입니다. 임의의 데이터 세트는 평균 값 분포를 제공합니다.

다른 예 : 코드. 대부분의 성능 문제는 잘못 작성된 SQL, 특히 부적절한 조인으로 인한 것입니다. SELECT * FROM my_table WHERE blah에 대해 개인을 조정하기 위해 색인을 적용 할 수는 있지만 잘못 쓰여진 검색어를 포기하는 데 도움이되지는 않습니다.

조숙 한 최적화에 대한 사실주의는 데이터베이스뿐만 아니라 알고리즘에도 적용됩니다. 가장 중요한 것은 데이터 모델을 완전하고 올바르게 만드는 것입니다. 당신이 그것을 관리한다면 당신은 이미 게임보다 앞서 있습니다. 편집

은 더 명확하게 당신이 어디에서 오는지 이해 I에 링크 된 질문을 읽으면서. 데이터베이스 디자이너 관점에서이 Hibernate 매핑 문제에 대해 약간의 경험이 있습니다. 당신이 페이지의 끝에 줄 예제를 취하는 ...

Animal>Vertebrate>Mammal>Carnivore>Canine>Dog type 계층

작업 ... 중요한 것은 최대한 체인 아래로 객체를 인스턴스화한다. Animals 컬럼을 인스턴스화하면 Dogs, Cats 등의 별도 콜렉션을 인스턴스화하는 것보다 훨씬 느리게 수행됩니다 (해당 하위 또는 전체 테이블에 대한 테이블이 있다고 가정).

이것은 데이터베이스 디자인 문제보다 더 많은 응용 프로그램 디자인 문제입니다. 차이점은 구체적인 수준 (CATS, DOGS)에서만 테이블을 만들거나 테이블 (ANIMALS, VERTEBRATES 등)에서 계층 구조를 복제하는지 여부입니다. 불행히도 여기에는 간단한 대답이 없습니다. 예를 들어, 데이터 검색의 성능뿐만 아니라 Hibernate가 삽입과 업데이트를 처리하는 방법을 고려해야한다. 쿼리를 잘 수행하는 디자인은 데이터를 지속 할 때 매우 악몽 일 수있다. 또한 관계형 무결성에 영향을 미칩니다 : 모든 엔터티가 Mammals에 적용되는 경우 MAMMALS 테이블에 대해 외래 키를 적용 할 수 있으면 편리합니다.

Answer 3

데이터베이스의 성능 문제는 데이터 볼륨에 따라 선형 적으로 확장되지 않습니다. 백만 개의 행이있는 데이터베이스는 하나의 핫 스폿을 표시하지만 10 억 개의 행이있는 유사한 데이터베이스는 완전히 다른 핫 스폿을 표시합니다.샘플 데이터로 수행 된 테스트에주의하십시오.

디자인을 단순하고 건강하게 유지하려면 좋은 사운드 데이터베이스 디자인 방법이 필요합니다. 속도에 대해 걱정하기 시작하기 전에 데이터베이스가 데이터 요구 사항을 충족하는지, 그리고 모델이 관련성, 완전성, 정확성 및 관계형인지 (관계형 데이터베이스를 작성한다고 가정)에 대해 걱정할 필요가 있습니다.

그런 다음, 단순하고, 건전하며, 올바른 것이 있으면 속도에 대한 걱정을 시작하십시오. 앱 코드를 변경하지 않고 데이터베이스의 물리적 기능을 조정하여 속도를 향상시킬 수있는 방법에 놀랄 것입니다. 이를 위해서는 특정 DBMS에 대해 많은 것을 배워야합니다.

그들은 데이터베이스 개발이 쉬울 것이라고 결코 말하지 않았습니다. 그들은 방금 이렇게 재미있을 것이라고 말했다.