저는 주로 Hibernate를 사용하는 Java 개발자이며, 일부 유스 케이스에서는 기대했던 것과 비교하여 매우 느리게 수행되는 쿼리를 사용합니다. 필자는 지역 DBA와 이야기를 나누었으며 많은 경우 쿼리의 성격으로 인해 성능을 향상시킬 수 없다고 주장합니다.데이터베이스 성능에 대한 현실적인 가정을 어떻게 배울 수 있습니까?
그러나 나는 그들의 말을 듣기에는 다소 주저합니다. 내가 그것을 빨아 들이고 내가 원하는 정보를 얻는 다른 방법을 찾거나 속도와 함께 살아가는 법을 배우고 DBAs에게 허풍을 불러 일으킬 수있을 때 배우기 위해 사용할 수있는 자원은 무엇입니까?
당신은 흥미로운 시점에 있습니다. 대부분의 Java 개발자는 데이터베이스에 대해 알지 못하기 때문에 ORM 도구를 사용하며 데이터베이스에 대해 배우고 싶지 않으며 특히 특정 독점 DBMS의 특성에 대해 배우고 싶지 않기 때문에 ORM 도구를 사용합니다. ORMs는이 모든 것에서 우리를 표면 상으로 보호합니다.
그러나 실제로 쿼리를 수행하는 방법을 알고 싶다면 Oracle 데이터베이스의 작동 방식을 이해해야합니다. 이것은 좋은 일이다 : 당신이 확실히 데이터베이스의 곡물로 작업한다면 당신은보다 나은 Hibernate 애플 리케이션을 구축 할 것이다.
오라클의 설명서 세트에는 성능 튜닝에 대한 볼륨이 포함되어 있습니다. 이것은 시작할 곳입니다. Find out more. 다른 사람들이 말했듯이, 엔트리 레벨 도구는 EXPLAIN PLAN입니다. 또 하나의 필수 지침은 오라클의 Database Concepts Guide입니다. 튜닝의 중요한 측면은 데이터베이스의 논리적 및 물리적 아키텍처를 이해하는 것입니다. 나는 또한 Tom Kyke의 책에 대한 DCooke의 추천에 동의합니다.
오라클 성능 튜닝을 잘 수행하는 계약자 및 컨설턴트가 있음을 명심하십시오. 그것이 쉬운 경우에 그들은 매우 더 가난 할 것입니다. 하지만 성가신 DBA가 당신과 올바르게 관계를 맺을 수 있도록 충분한 지식을 확실히 얻을 수 있습니다.
+1 자기 책임 성 접근법. 또 다른 좋은 자료는 Tom Kyte의 "Expert Oracle Database Architecture"입니다.이 전문가는 제목에도 불구하고 개발자가 Oracle 아키텍처와 효과적인 응용 프로그램을 작성하는 방법을 이해할 수 있도록 작성되었습니다. – DCookie
쿼리 성능 기대치의 기준은 무엇입니까? 어때? DBA와 논쟁을한다면, 쿼리가 무엇인지를 (최소한) 알아야하고, EXPLAIN PLAN을 이해하고, 개선 방법을 지적 할 수 있어야합니다. 그리고, @OMG Ponies가 지적했듯이, Hibernate는 질의를 작성하는 데 열악한 작업을하고있을 수도 있습니다. 그러면 당신은 무엇을합니까?
쉽지 않은가요? 아마도 DBA 직원과 조금 더 적대적인 접근 방식을 취하고 성능 향상을 방해하는 쿼리에 대해 정중하게 물어보고 더 나은 수행을 위해 리팩토링 할 수있는 방법에 대한 제안이있을 수 있습니다.
EXPLAIN PLAN이 최선의 방법입니다. 조회가 처리되는 f}과 처리 할 데이터의 양을 알려줍니다. 이것을 '이 쿼리를 처리하는 데 필요한 데이터의 양'과 비교해보십시오. 서로 다른 경우 이유를 묻습니다. –
좋은 ORM은 일반적으로 일반 개발자보다 훨씬 잘 작동하며 미세하게 조정할 수 있습니다 (그리고 나는 이것을 Hibernate에 대해 사실이라고 생각한다). –
@ 파스칼, 나는 희망한다. 그렇다면 그들은 쓸데없는 것의 옆에있을 것이다. – DCookie
테이블 구조 (정규화) 문제 일 수도 있습니다. 주로, 이것이 내가 hybernate로 가지 않는 이유입니다. 항상 최적의 쿼리를 작성할 수 있어야합니다.
답변으로 내 코멘트를 게시 :
ORM을 사용하여 트레이드 오프의- 그것은 데이터베이스에 제공되는 쿼리를 구성하는 방법에 대한 자비의에 당신이있어. LINQ는 나에게 관심이있는 유일한 사람입니다. 이러한 상황에서 저장 프로 시저와 함께 사용할 수 있기 때문입니다. DBA가 더 나은 속도를 원한다면 DBA가 ORM을 버리라고 말하지 않은 것에 놀랐습니다 ...
EXPLAIN 계획은 효율성에 대한 아이디어를 줄지 만 실제로 속도에 대한 시각은 아닙니다. 오라클의 경우, tkprof (사용 가능한 것으로 가정)을 사용하여 진행 상황을 분석해야합니다.
+1은 좋은 관찰을 위해서 크레딧을 얻을 수도 있습니다 ;-) – DCookie
그리고 Hibernate가 스토어드 프로 시저를 지원하지 않는다고 생각하게하는 이유는 무엇입니까? 힌트 : 그렇습니다. –
@Pascal Thivent : 죄송합니다. 각 ORM이 제공하는 정보 나 현재 내 정보가 어떤지 알 수 없습니다. 내 생각에 대부분 저장 프로 시저와 함수를 사용하기 위해 ORM을 사용하지 않는다. –
DCookie, OMG 및 APC는 모두 답변을 +1합니다.필자는 Hibernate 애플리케이션의 DBA 측에 있었고 Tom Kyte가 말했듯이 비효율적 인 SQL을 취하여 더 빠르게 실행할 수있는 "fast = true"매개 변수는 없습니다. 때때로 나는 문제가되는 Hibernate 질의를 캡쳐하고 오라클 SQL 분석기를 사용하여 성능을 향상시키는 SQL 프로파일을 생성 할 수있었습니다. 이 프로파일은 옵티 마이저의 실행 계획 생성을 "가로 채고"(응용 프로그램을 변경하지 않고) 어떤 이유로 든 최적화 프로그램에서 일반적으로 간과 할 수있는 더 나은 것으로 만들기위한 일련의 힌트입니다. 그러나 이러한 결과는 성능이 좋지 않은 SQL에 대한 규칙보다는 예외입니다.
ORM 계층보다 데이터를 더 잘 이해하고있는 개발자로서 할 수있는 한 가지 방법은 특정 쿼리 문제를 해결하고 이러한 뷰를 Hibernate에 제공하는 효율적인 뷰를 작성하는 것입니다.
Hibernate 생성 쿼리로 끝나고 WHERE 절의 바인드 변수와 비교되는 Oracle DATE (TIMESTAMP가 아닌) 열은 매우주의해야합니다. Java 타임 스탬프 데이터 유형의 유형이 일치하지 않으면 이러한 열에 인덱스를 사용합니다.
+1은 DBA 관점입니다. Tom Kyte의 "fast = true"매개 변수에 대한 참조가 마음에 들었습니다. 항상 그걸 알았습니다. 또 다른 Kyte-ism은 거의 모든 (80-100 %) 성능 문제가 데이터베이스 문제가 아니라 응용 프로그램 및 디자인 문제라는 것입니다. 바인드 변수 등을 사용하지 않는 구조화되지 않은 쿼리는 모두 기여합니다. – DCookie
그건 ORM을 사용하는 것의 절충점입니다. 데이터베이스에 전달되는 쿼리를 구성하는 방법에 대해 자비를 베풀어 야합니다. LINQ는 나에게 관심이있는 유일한 사람입니다. 이러한 상황에서 저장 프로 시저와 함께 사용할 수 있기 때문입니다. DBA가 더 나은 속도를 원한다면 ORM을 버리라고 말하지 않은 것에 놀랐습니다 ... –
숙련 된 개발자에게조차도 성능 예측은 정말 어렵습니다. 전투의 흉터가 충분하지 않거나 충분히 빠르지 않는 경우, 프로파일 러 (겸손한'설명 '포함)가 당신의 친구입니다. :-) – Ken