쿼리 튜닝이 능동적이거나 반응성이어야합니까?

소프트웨어 개발자이자 주목받는 DBA 인 저는 SQL Server 데이터베이스를 설계 할 때 모범 사례를 통합하려고합니다 (소프트웨어의 시간이 99 % 인 SQL Server를 사용하는 시간의 99 %). 개발 전과 개발 중에 최상의 디자인을 만듭니다.

그러나 다른 소프트웨어 개발자와 마찬가지로 데이터베이스 객체를 변경 / 생성해야하는 기능, 버그 및 요구 사항 변경이 추가되었습니다.

내 질문은 쿼리 튜닝이 능동적이거나 반응성이어야합니까? 즉, 코드 / 데이터베이스를 약간 수정 한 후 몇 주 후에 쿼리 성능을 확인하고 그에 따라 조정하기 위해 하루를 따로 설정해야합니까? 괜찮아 보인다고 해도 ?

아니면 평균 미만의 성능이 데이터베이스 확인이어야하고 속담 칠판으로 돌아 가야한다는 것을 알고 있어야합니까?

쿼리 튜닝에는 많은 시간이 소요될 수 있으며 초기 데이터베이스 디자인에 따라 최소한의 이점을 얻을 수 있습니다. 받아 들여진 modus operandi에 대해 궁금합니다.

둘 다, 그러나 대부분 능동적

실제 볼륨과 데이터 품질에 대해 개발 중에 테스트하는 것이 중요합니다. 개발자가 100 또는 1000 개의 행에서 쿼리를 실행 한 다음 천만 개의 프로덕션 행을 사용하는 경우가 일반적입니다.

"index here help help"에 대해 메모 할 수도 있습니다. 또는 "나를 다시 방문하십시오". 또는 "다음 DB 버전에서 새로운 기능 xxx로 수정됩니다".

그러나 몇 가지 쿼리는 시간의 테스트를 견디지 ​​못합니다. 옵티마이 저가 다른 조인 유형을 사용하기로 결정하기 때문에 데이터 분배가 변경되거나 기하 급수적으로 증가합니다. 이 경우에만 반응 할 수 있습니다.

적어도 SQL Server의 경우 다양한 "누락 된 인덱스"및 "가장 긴 쿼리"DMV 쿼리가 전화 전에 문제 영역을 나타낼 수 있다고 말하면

편집 : 명확히하기 위해 ...

사전 대응이 모든 쿼리를 지금 조정한다는 의미는 아닙니다. 합리적인 응답 시간에 필요한 (자주 실행)을 조정하는 것을 의미합니다. 매주 오전 3시 일요일 보고서 쿼리는 무시하십시오.

좋아, 나는 물고 반대의 견해를 취할 것이다. 우선, 나는 당신이 당신을 곤경에 빠뜨리 게 할 것이라고 생각하는 것을 시작해서는 안된다고 말하고 싶습니다. 이 모범 사례를 적용하여 전화를 걸려면 계속 진행하십시오. 이것은 능동적으로 진행되어야합니다.

그 후, 시간과 돈이 낭비되므로 시간을 낭비하고 제품을 배달하십시오. 병목이 될 수도 있고 아닐 수도있는 수많은 디자인 타임 튜닝 쿼리를 사용하는 대신로드 테스트를 포함한 추가 테스트에이 시간을 사용하십시오.

무언가가 설계 사양에 미치지 못하거나 프로파일 러의 응답 시간 목록의 10 % 또는 20 %에 해당하는 것이 있으면 무엇이든 조정하는 데 필요한 시간을 투자하십시오. 부서진.

완벽한 세계에서는 모든 것이 처음부터 완벽하게 설계되고 논리적 빌드 시퀀스를 사용하여 개발됩니다. 실제로는 예산과 시간에 제약이 있으며 테스트 데이터는 생산 데이터처럼 보이지 않을 수 있습니다. 이런 이유로 저는 사전에 문제를 피하기 위해 상식을 사용하지만 상상력이 있거나 잠재적 인 문제를 찾는 데는 시간과 돈을 소비하는 대신 실제 문제로 판명되는 것을 조정하는 제한된 자원에 집중한다고 말합니다.

3 가지 유형의 튜닝, 1 개의 반응 및 2 개의 능동을 수행하게됩니다.

반응성

파란색으로 인해 일부 쿼리가 문제를 일으키기 시작합니다. 응용 프로그램 버그 또는 기능, 예상치를 초과하는 테이블 증가, 트래픽 급증 또는 쿼리 최적화 프로그램이 "크리에이티브"를 얻기 때문일 수 있습니다. 이것은 심야 중 오작동의 다운 유형일 수도 있고, 중요하지 않은 특성의 시스템 속도 저하에 대한 응답 일 수도 있습니다. 어느 쪽이든, 반응성 튜닝의 정의 특성은 이미 문제 가 있다는 것 입니다. 말할 것도없이, 당신은 가능한 한 적은 일을하고 싶습니다. 어느 것이 우리를 ...

능동적

유형 1 : 일상적인 유지 관리

스키마가 얼마나 자주 변경되고 얼마나 빨리 데이터가 증가하는지에 따라 몇 달 또는 몇 주마다 일정에 따라 데이터베이스의 성능 분석 도구 (예 : Oracle DBA의 AWR 보고서)의 출력을 검토해야합니다. 초기 문제, 즉 반응성 조정을 요구하는 방법과 낮은 매달린 과일, 곧 문제를 일으키지 않지만 멀리 예방하기 위해 약간의 노력으로 개선 할 수있는 품목을 찾고 있습니다. 미래의 문제. 당신이 이것에 소비하는 시간은 얼마나 많은 시간과 당신이 그것을 소비 할 수있는 다른 것에 달려 있지만 최적의 금액은 결코 0이 아닙니다. 그러나 더 많은 일을함으로써 지출해야 할 금액을 쉽게 줄일 수 있습니다.

유형 2 : 적절한 디자인

"조기 최적화"에 대한 Knuth의 권고는 널리 알려져 있으며 정식으로 존중됩니다. 그러나 "조기"의 적절한 정의를 사용해야합니다. 일부 응용 프로그램 개발자는 자신의 쿼리를 작성할 수있는 경우 논리적으로 정확한 첫 번째 쿼리를 채택하는 경향이 있으며 성능, 현재 또는 미래에 대해 아무 것도 신경 쓰지 않습니다. 또는 단순히 프로덕션 환경을 대표하지 않는 개발 데이터 세트에 대해 테스트 할 수도 있습니다 (팁 : 수행하지 마십시오! 개발자는 항상 테스트를 위해 현실적인 데이터에 액세스해야합니다). 요점은 쿼리를 조정하는 적절한 시간은 성능이 떨어지는 SQL 목록에 나타날 때가 아니라 중요한 문제가 발생하지 않을 때가 아니라 처음 배포 될 때라는 것입니다.

그렇다면 DBA 토지에서 조기 최적화의 자격은 무엇입니까? 내 목록의 맨 위에는 입증 된 필요없이 정규화를 희생하는 것이있을 것입니다. 물론 자식 행에서 런타임에 계산하지 않고 부모 행의 합계를 유지할 수 있지만 실제로해야합니까? Twitter 또는 Amazon 인 경우 전략적 비정규 화 및 사전 계산이 가장 친한 친구가 될 수 있습니다. 5 명의 사용자를위한 작은 회계 데이터베이스를 설계하는 경우 데이터 무결성을 촉진하는 적절한 구조가 최우선 순위가되어야합니다. 다른 조기 최적화도 마찬가지로 우선 순위의 문제입니다. 0.1 초로 줄일 수 있다고 생각하더라도 하루에 한 번 실행되고 10 초가 걸리는 쿼리를 수정하는 데 시간을 소비하지 마십시오. 어쩌면 매일 6 시간 동안 실행되는 보고서가있을 수 있습니다. 그러나 조정에 시간을 투자하기 전에 배치 작업으로 스케줄을 탐색하십시오. 프로덕션로드가 10 %를 넘지 않는 경우 (보안을 관리 할 수 ​​있다고 가정) 별도의 실시간 복제보고 인스턴스에 투자하지 마십시오.

현실적인 데이터에 대한 테스트, 성장 및 트래픽 패턴에 대한 교육 된 추측 (스파이크에 대한 허용량) 및 플랫폼의 최적화 요구 사항에 대한 지식을 적용함으로써 현재뿐만 아니라 미래에도 최적으로 실행되는 쿼리를 배포 할 수 있습니다. 이상적이지 않은 조건에서. 적절한 기술을 적용하면 쿼리 성능을 정확하게 예측하고 최적화 할 수 있습니다 (각 구성 요소가 필요한만큼 빠름).

(그리고 당신이 그것을하는 동안 통계를 배우십시오! )

완벽한 세계에서 모든 튜닝은 디자인 단계에서 사전에 수행되며 반응하는 것은 없지만 세상은 완벽하지 않습니다. 테스트 데이터가 대표적이지 않고 테스트 사례가 누락되거나로드가 예기치 않게 달라지며 성능 문제를 일으키는 버그가있을 수 있습니다. 이러한 상황에서는 일부 사후 조정이 필요할 수 있지만 사후 조정이 선호되는 것은 아닙니다. 목표는 항상 이러한 것들을 미리 파악하는 것입니다.

소급 조정 계획은 매우 실용적입니다. 테스트 할 때는 예상되는 타이밍과 처리량을 문서화해야하며 생산 프로세스가 설계 사양을 충족하지 않는시기를 알려주는 분석을 실제로 빌드해야합니다. 이런 식으로 튜닝 할 코드를 미리 식별 할 수 있습니다. 그런 다음 문제가 무엇인지뿐만 아니라 설계 / 테스트 단계에서 문제를 파악하지 못한 이유를 파악할 수 있습니다.

저에게있어 성능 테스트는 항상 개발 프로세스의 일부였습니다. 이 표를 변경하고,이 보고서를 수정하고,이 기능을 추가 하시겠습니까? 테스트 과정에서 개별 및 전체 성능을 알려진 기준 및 / 또는 요구 사항과 비교할 수 있습니다 (예 : 일부 보고서는 백그라운드에서 실행되거나 자동화되어 있으므로 모든 단일 쿼리의 성능 또는 속도) 시스템이 항상 최우선 순위는 아닙니다).

IMHO, 이것은 반응적인 프로세스가되어서는 안됩니다. 변경으로 인해 프로덕션의 성능 문제가 반응을 시작할 때까지 기다리지 않아야합니다. dev / test 등을 변경하는 경우 동일한 앱 및 유사한 사용 패턴을 가진 유사한 하드웨어에서 유사한 데이터를 사용하여 이러한 변경 사항을 테스트해야합니다. 이러한 변경 사항이 프로덕션에 몰려 들게하고 놀라게하지 마십시오. 이 조정 시간에 대한 예산을 미리 미리 조정하는 것이 편리하지 않을 때 거의 항상 발생합니다.