언제, 왜 데이터베이스 조인 비용이 많이 듭니까?

데이터베이스에 대한 조사를 진행 중이며 관계형 DB의 일부 제한 사항을보고 있습니다.

큰 테이블의 조인이 매우 비싸지 만 이유가 확실하지 않습니다. 병목 현상이 발생하는 지점에서 조인 작업을 실행하려면 DBMS가 무엇을해야합니까?
비정규 화가이 비용을 극복하는 데 어떻게 도움이 될 수 있습니까? 다른 최적화 기술 (예 : 인덱싱)이 어떻게 도움이됩니까?

개인적인 경험은 환영합니다! 리소스에 대한 링크를 게시하려는 경우 Wikipedia를 피하십시오. 나는 그것을 어디서 찾을 수 있는지 안다.

이와 관련하여 BigTable 및 SimpleDB와 같은 클라우드 서비스 데이터베이스에서 사용되는 비정규 화 된 접근 방식이 궁금합니다. 이 질문을 참조하십시오 .

성능 향상을위한 비정규 화? 설득력있는 것처럼 들리지만 물을 담지 않습니다.

박사 테드 커드와 회사의 관계형 데이터 모델의 최초 제안자이었다 크리스 날짜, 정상화에 대한 잘못된 정보 인수 인내심이 부족하고 체계적으로 과학적인 방법을 사용하여 철거 : 그는 대규모 데이터베이스를 가지고 및 테스트 이러한 주장을.

나는 그가 그것을 쓴 생각 관계형 데이터베이스 글 1988년부터 1991년까지 하지만이 책 이후의 버전을 여섯으로 압연 된 데이터베이스 시스템을 소개 하고, 내가 쓸 가능성이 남아으로 데이터베이스 이론 및 설계에 대한 최종 텍스트가 8 번째 판에서, 앞으로 수십 년 동안 인쇄되었습니다. Chris Date는 우리 대부분이 맨발로 뛰고있을 때이 분야의 전문가였습니다.

그는 그것을 발견했다 :

• 그들 중 일부는 특별한 경우를 위해 개최
• 그들 모두는 일반적인 사용을 위해 돈을 지불하지 않습니다
• 다른 특별한 경우에는 모두 심각하게 악화됩니다.

그것은 모두 작업 세트의 크기를 완화시키는 것으로 돌아옵니다. 인덱스를 올바르게 설정하여 올바르게 선택한 키와 관련된 조인 은 행이 구체화 되기 전에 결과 를 크게 정리할 수 있기 때문에 저렴하지 않습니다 .

결과를 구체화하는 것은 대량의 디스크 읽기를 포함하며, 이는 대량의 운동으로 가장 비싼 측면입니다. 반대로 조인을 수행하려면 논리적으로 키만 검색해야 합니다 . 실제로 키 값도 가져 오지 않습니다. 키 해시 값은 조인 비교에 사용되어 다중 열 조인의 비용을 줄이고 문자열 비교와 관련된 조인 비용을 크게 줄입니다. 캐시에 훨씬 더 적합 할뿐만 아니라 디스크 읽기가 훨씬 적습니다.

또한 우수한 옵티마이 저는 가장 제한적인 조건을 선택하고 조인을 수행하기 전에 적용하여 카디널리티가 높은 인덱스에서 조인의 높은 선택성을 효과적으로 활용합니다.

분명히이 유형의 최적화는 비정규 화 된 데이터베이스에도 적용 할 수 있지만 스키마를 비정규 화 하려는 사람들은 일반적으로 인덱스를 설정할 때 카디널리티에 대해 생각하지 않습니다.

테이블 스캔 (조인을 생성하는 동안 테이블의 모든 행을 검사)은 거의 드물다는 것을 이해하는 것이 중요합니다. 쿼리 최적화 프로그램은 다음 중 하나 이상이 보류 된 경우에만 테이블 스캔을 선택합니다.

• 관계에 200 개 미만의 행이 있습니다 (이 경우 스캔이 저렴함)
• 조인 열에 적합한 인덱스가 없습니다 (이 열에서 조인하는 것이 의미가있는 경우 인덱스되지 않은 이유는 무엇입니까?).
• 열을 비교하려면 유형 강제가 필요합니다 (WTF ?! 수정 또는 집으로 이동). ADO.NET 문제에 대한 최종 참고 사항 참조
• 비교의 인수 중 하나는 표현식입니다 (인덱스 없음)

작업 수행은 수행하지 않는 것보다 비용이 많이 듭니다. 그러나 잘못된 작업을 수행하고 무의미한 디스크 I / O로 강제 전환 한 다음 실제로 필요한 조인을 수행하기 전에 찌꺼기를 버리는 것은 훨씬 비쌉니다. "잘못된"연산이 사전 계산되고 인덱스가 현명하게 적용 되더라도 상당한 벌금이 부과됩니다. 수반되는 업데이트 이상에도 불구하고 조인을 사전 계산하는 비정규 화는 특정 조인에 대한 약속입니다. 당신이 필요한 경우 다른를 결합, 이러한 노력은 비용 것입니다 큰 .

누군가가 세상이 변하고 있음을 상기시키고 싶다면 gruntier 하드웨어의 더 큰 데이터 세트가 Date의 결과를 과장한다는 것을 알게 될 것입니다.

과금 시스템 또는 정크 메일 생성기 (부끄러운 일)에 종사하고 불완전하게 키보드로 손을 뻗어 모든 비정규 화가 더 빠르다는 사실을 알고 있습니다. 죄송합니다. 경우-특히, 모든 데이터를 순서대로 처리하는 경우 . 그것은 일반적인 경우가 아니다, 그리고 당신이 하는 전략 정당화.

당신은 그것을 잘못 일반화하는 것이 정당 하지 않습니다 . 데이터웨어 하우징 시나리오에서 비정규 화를 적절하게 사용하는 방법에 대한 자세한 정보는 참고 섹션 끝을 참조하십시오.

나는 또한 응답하고 싶습니다

조인은 립글로스가있는 직교 제품입니다.

볼록의 짐. 제한은 가능한 한 빨리 적용되며 가장 제한적인 것부터 적용됩니다. 당신은 이론을 읽었지만 이해하지 못했습니다. 조인은 쿼리 최적화 프로그램에 의해서만 "조건자가 적용되는 카티 전 곱" 으로 처리 됩니다 . 옵티마이 저는 모든 등가 변환을 생성하고 비용과 선택 성별로 순위를 매겨 최상의 쿼리 계획을 선택할 수 있도록 기호 분해 (실제로 정규화)를 나타냅니다.

옵티마이 저가 데카르트 제품을 생성하게하는 유일한 방법은 술어를 제공하지 않는 것입니다. SELECT * FROM A,B

노트

David Aldridge는 중요한 추가 정보를 제공합니다.

실제로 인덱스 및 테이블 스캔 외에도 다양한 다른 전략이 있으며, 현대 옵티마이 저는 실행 계획을 생성하기 전에 모든 비용을 지불합니다.

실용적인 조언 : 외래 키로 사용할 수 있다면 색인화 하여 옵티마이 저가 색인 전략을 사용할 수 있도록하십시오.

예전에는 MSSQL 옵티 마이저보다 똑똑했습니다. 그것은 두 가지 버전으로 변경되었습니다. 이제는 일반적으로 저를 가르칩니다 . 매우 실제적인 의미에서 전문가 시스템으로, 규칙 기반 시스템이 효과적이라는 영역에서 충분히 영리한 사람들의 모든 지혜를 체계화하고 있습니다.

"볼록"은 재치가 없었을 것입니다. 나는 덜 거만 해지고 수학은 거짓말을하지 않는다는 것을 상기시켰다. 이것은 사실이지만 수학적 모델의 모든 의미가 반드시 문자 그대로 취해 져야하는 것은 아닙니다. 음수의 제곱근은 부조리 검사를 조심스럽게 피하고 방정식을 해석하려고 시도하기 전에 모두 제거 해야하는 경우 매우 편리합니다.

내가 너무 야만적으로 반응 한 이유는

조인 은 직교 제품입니다 ...

이 의미가 있었는지하지 않을 수 있지만 입니다 쓰여진 것, 그것은 절대적으로 사실입니다. 직교 곱은 관계입니다. 조인은 함수입니다. 보다 구체적으로, 조인은 관계 값 함수입니다. 빈 술어를 사용하면 데카르트 제품이 생성되며,이를 확인하는 것은 데이터베이스 쿼리 엔진에 대한 하나의 정확성 점검이지만, 교실 밖에서는 실질적인 가치가 없기 때문에 제약이없는 조인을 작성하는 사람은 아무도 없습니다.

독자들이 모델과 모델을 혼동하는 고대 함정에 빠지는 것을 원하지 않기 때문에 이것을 호출했습니다. 모델은 편리한 조작을 위해 의도적으로 단순화 된 근사치입니다.

테이블 스캔 조인 전략 선택 컷오프는 데이터베이스 엔진마다 다를 수 있습니다. 트리 노드 채우기 팩터, 키-값 크기 및 알고리즘의 미묘 성과 같은 많은 구현 결정의 영향을 받지만 광범위하게 말하는 고성능 인덱싱의 실행 시간은 k log n + c 입니다. C 용어는 대부분 설정 시간으로 이루어진 고정 된 오버 헤드이며 곡선 모양은 n 이 수백이 될 때까지 선형 검색과 비교할 때 보상을받지 못한다는 것을 의미합니다 .

때로는 비정규 화가 좋은 생각입니다

비정규 화는 특정 조인 전략에 대한 약속입니다. 앞에서 언급했듯이 이는 다른 조인 전략을 방해 합니다. 그러나 디스크 공간, 예측 가능한 액세스 패턴 및 그 일부 또는 전부를 처리하려는 경향이있는 경우, 조인 사전 계산은 매우 가치가 있습니다.

작업에서 일반적으로 사용하는 액세스 경로를 파악하고 해당 액세스 경로에 대한 모든 조인을 사전 계산할 수도 있습니다. 이것은 데이터웨어 하우스의 전제입니다. 최소한 유행어 규정 준수를 위해서가 아니라 자신이하는 일을하는 이유를 아는 사람들이 구축 한 것입니다.

올바르게 설계된 데이터웨어 하우스는 정규화 된 트랜잭션 처리 시스템에서 대량 변환으로 주기적으로 생성됩니다. 이러한 운영 및보고 데이터베이스의 분리는 OLTP와 OLAP (온라인 트랜잭션 처리, 즉 데이터 입력 및 온라인 분석 처리, 즉보고) 사이의 충돌을 없애는 매우 바람직한 효과를 갖습니다.

여기서 중요한 점은주기적인 업데이트 외에 데이터웨어 하우스는 읽기 전용이라는 것 입니다. 이로 인해 업데이트 이상 문제가 발생합니다.

OLTP 데이터베이스 (데이터 입력이 발생하는 데이터베이스)를 비정규 화하는 실수를 저 지르지 마십시오. 청구 실행이 더 빠를 수 있지만 그렇게하면 업데이트 이상이 발생합니다. Reader 's Digest가 당신에게 물건 보내기를 멈추도록 시도한 적이 있습니까?

요즘에는 디스크 공간이 저렴하기 때문에 스스로를 쓰러 뜨리십시오. 그러나 비정규 화는 데이터웨어 하우스에 대한 이야기의 일부일뿐입니다. 훨씬 더 큰 성능 향상은 사전 계산 된 롤업 값 (매월 총계, 그런 종류)에서 비롯됩니다. 그건 항상 작업 세트를 줄여 대해.

형식이 일치하지 않는 ADO.NET 문제

varchar 유형의 인덱스 열이 포함 된 SQL Server 테이블이 있고 AddWithValue를 사용하여이 열에 대한 쿼리를 제한하는 매개 변수를 전달한다고 가정합니다. C # 문자열은 유니 코드이므로 유추 된 매개 변수 유형은 NVARCHAR이며 VARCHAR과 일치하지 않습니다.

VARCHAR에서 NVARCHAR 로의 변환은 광범위하게 변환되므로 암시 적으로 발생하지만 인덱싱에 작별 인사를하고 이유를 알아내는 것이 좋습니다.

"디스크 적중 횟수 계산"(Rick James)

모든 것이 RAM에 캐시되면 JOINs다소 저렴합니다. 즉, 정규화에는 많은 성능 저하 가 없습니다 .

"정규화 된"스키마가 JOINs디스크에 많이 충돌하지만 동등한 "비정규 화 된"스키마가 디스크에 충돌하지 않아도되면 비정규 화가 성능 경쟁에서 승리합니다.

원래 작성자의 의견 : 최신 데이터베이스 엔진은 조인 작업 중 캐시 누락을 최소화하기 위해 액세스 순서를 구성하는 데 매우 능숙합니다. 위의 내용은 사실이지만 조인은 반드시 큰 데이터에서 문제가 발생한다는 것을 암시하는 것으로 잘못 해석 될 수 있습니다. 이로 인해 경험이 부족한 개발자는 잘못된 의사 결정을 내릴 수 있습니다.

대부분의 주석가들이 언급하지 못한 것은 복잡한 RDBMS에서 사용할 수있는 광범위한 조인 방법론이며, 비정규 화 도구는 비정규 화 된 데이터 유지 관리 비용이 높아짐에 따라 항상 광택을 내고 있습니다. 모든 조인이 인덱스를 기반으로하는 것은 아니며 데이터베이스에는 조인 비용을 줄이기 위해 조인을위한 최적화 된 알고리즘 및 방법이 많이 있습니다.

어쨌든 조인 비용은 유형과 몇 가지 다른 요인에 따라 다릅니다. 전혀 비싸지 않아도됩니다-몇 가지 예.

• 대량 데이터가 결합 된 해시 조인은 실제로 매우 저렴하며 해시 테이블을 메모리에 캐시 할 수없는 경우에만 비용이 크게 증가합니다. 색인이 필요하지 않습니다. 조인 된 데이터 집합간에 동등하게 파티션을 나누는 것이 큰 도움이 될 수 있습니다.
• 정렬 병합 조인 비용은 병합이 아닌 정렬 비용에 의해 결정됩니다. 인덱스 기반 액세스 방법은 정렬 비용을 사실상 제거 할 수 있습니다.
• 인덱스의 중첩 루프 조인 비용은 b- 트리 인덱스의 높이와 테이블 블록 자체의 액세스에 의해 결정됩니다. 빠르지 만 대량 조인에는 적합하지 않습니다.
• 클러스터를 기반으로하는 중첩 루프 조인은 조인 행당 필요한 논리 IO 수를 줄여 훨씬 저렴합니다. 조인 된 테이블이 모두 동일한 클러스터에 있으면 조인 된 행의 코 로케이션을 통해 조인이 매우 저렴 해집니다.

데이터베이스는 조인하도록 설계되었으며 조인 메커니즘이 잘못되지 않는 한 데이터베이스의 작동 방식이 매우 유연하고 일반적으로 성능이 뛰어납니다.

나는 모든 질문이 잘못된 전제에 기초한다고 생각한다. 큰 테이블의 조인이 반드시 비싼 것은 아닙니다 . 사실, 조인을 효율적으로 수행하는 것은 관계형 데이터베이스가 존재하는 주된 이유 중 하나입니다 . 큰 집합 에 대한 조인 은 종종 비싸지 만 큰 테이블 A의 전체 내용을 큰 테이블 B의 전체 내용과 조인하려는 경우는 거의 없습니다. 대신 각 테이블 의 중요한 행만 사용 되도록 쿼리를 작성하십시오. 결합에 의해 유지되는 실제 세트는 더 작게 유지됩니다.

또한 Peter Wone이 언급 한 효율성이 있으므로 최종 결과 세트가 구체화 될 때까지 각 레코드의 중요한 부분 만 메모리에 저장됩니다. 또한 조인이 많은 큰 쿼리에서는 일반적으로 더 작은 테이블 세트로 시작하여 큰 테이블 세트로 작업하여 메모리에 보관 된 세트가 가능한 한 작게 유지되도록합니다.

올바르게 수행하면 일반적으로 조인이 많은 양의 데이터를 비교, 결합 또는 필터링 하는 가장 좋은 방법 입니다.

병목 현상은 거의 항상 디스크 I / O이며, 특히 임의의 디스크 I / O입니다 (순서 읽기는 상당히 빠르며 미리 읽기 전략으로 캐시 할 수 있음).

큰 테이블의 작은 부분을 읽으며 뛰어 다니면 조인 이 임의의 탐색을 증가시킬 수 있습니다 . 그러나 쿼리 최적화 프로그램은 그것을 찾아서 더 나은 것으로 생각되면 순차적 테이블 스캔 (필요하지 않은 행을 버림)으로 바꿉니다.

비정규 화 된 단일 테이블에도 비슷한 문제가 있습니다. 행이 커서 단일 데이터 페이지에 적합하지 않습니다. 다른 행과 멀리 떨어진 행이 필요하고 큰 행 크기로 더 멀리 떨어져 있으면 임의의 I / O가 발생합니다. 다시, 테이블 스캔으로 인해이를 피할 수 있습니다. 그러나 이번에는 테이블 스캔이 행 크기가 커서 더 많은 데이터를 읽어야합니다. 당신이하고 있다는 사실에 추가 데이터를 복사 여러 위치에 하나의 위치에서, 그리고 RDBMS가 훨씬 더 읽기 (캐시)하는 것이 있습니다.

2 개의 테이블을 사용하면 2 개의 클러스터 된 인덱스도 얻을 수 있습니다. 일반적으로 인덱스가 작거나 디스크를 빠르게 읽을 수 있기 때문에 인서트 / 업데이트 오버 헤드가 적기 때문에 더 많은 인덱스를 생성 할 수 있습니다 (삽입 / 업데이트 오버 헤드가 적기 때문에). (또는 캐시 비용이 저렴) 디스크에서 읽어야하는 테이블 행의 양을 줄입니다.

조인이있는 유일한 오버 헤드는 일치하는 행을 알아내는 것에서 비롯됩니다. Sql Server는 주로 데이터 집합 크기를 기준으로 3 가지 유형의 조인을 사용하여 일치하는 행을 찾습니다. 옵티마이 저가 잘못된 조인 유형을 선택하면 (정확하지 않은 통계, 부적절한 인덱스 또는 옵티 마이저 버그 또는 에지 사례로 인해) 쿼리 시간에 큰 영향을 줄 수 있습니다.

• 루프 조인은 (최소 1) 작은 데이터 세트에 대해 싸구려 저렴합니다.
• 병합 조인에는 먼저 두 가지 데이터 집합이 필요합니다. 인덱스 된 열에서 조인하면 인덱스가 이미 정렬되어 있으므로 더 이상 작업을 수행 할 필요가 없습니다. 그렇지 않으면 정렬시 CPU 및 메모리 오버 헤드가 발생합니다.
• 해시 조인에는 해시 테이블을 저장하는 메모리와 해시를 빌드하는 CPU가 모두 필요합니다. 다시, 이것은 디스크 I / O와 관련하여 상당히 빠릅니다. 그러나 해시 테이블을 저장할 RAM이 충분하지 않은 경우 Sql Server는 tempdb를 사용하여 해시 테이블의 일부와 찾은 행을 저장 한 다음 한 번에 해시 테이블의 일부만 처리합니다. 모든 디스크와 마찬가지로이 속도는 상당히 느립니다.

최적의 경우 디스크 I / O가 발생하지 않으므로 성능 측면에서 무시할 수 있습니다.

최악 의 경우, 디스크 읽기가 작기 때문에 비정규 화 된 단일 테이블에서 온 것이므로 x 조인 된 테이블에서 동일한 양의 논리 데이터 를 읽는 것이 실제로 더 빠릅니다 . 동일한 양의 물리적 데이터 를 읽으려면 약간의 오버 헤드가있을 수 있습니다.

쿼리 시간은 일반적으로 I / O 비용에 의해 좌우되며 비정규 화로 인해 데이터 크기가 (소량의 아주 작은 행 오버 헤드를 뺀) 변경되지 않기 때문에 테이블을 병합하는 것만으로는 큰 이점이 없습니다. 성능을 향상시키는 경향이있는 비정규 화 유형 인 IME는 계산에 필요한 10,000 개의 행을 읽는 대신 계산 된 값을 캐싱합니다.

테이블을 조인하는 순서는 매우 중요합니다. 두 개의 데이터 세트가있는 경우 쿼리를 처리하는 데 필요한 데이터 양을 줄이기 위해 가장 작은 것이 먼저 사용되도록 쿼리를 작성하십시오.

일부 데이터베이스의 경우 중요하지 않습니다. 예를 들어 MS SQL은 대부분 적절한 조인 순서를 알고 있습니다. IBM Informix와 같은 일부의 경우 순서가 모든 차이를 만듭니다.

비정규 화 또는 정규화 여부를 결정하는 것은 조인의 복잡성 클래스를 고려할 때 매우 간단한 프로세스입니다. 예를 들어, 쿼리가 O (k log n) 일 때 정규화를 사용하여 데이터베이스를 설계하는 경향이 있습니다. 여기서 k는 원하는 출력 크기와 관련이 있습니다.

성능을 비정규 화하고 최적화하는 쉬운 방법은 정규화 구조의 변경이 비정규 화 된 구조에 어떤 영향을 미치는지 생각하는 것입니다. 그러나 비정규 화 된 구조에서 작동하려면 트랜잭션 논리가 필요할 수 있으므로 문제가 될 수 있습니다.

정규화와 비정규 화에 대한 논쟁은 문제가 심각하기 때문에 끝나지 않을 것입니다. 자연 솔루션에 두 가지 접근 방식이 필요한 경우 많은 문제가 있습니다.

일반적으로 정규화 된 구조와 재구성 할 수있는 비정규 화 된 캐시를 항상 저장했습니다. 결국, 이러한 캐시는 향후 정규화 문제를 해결하기 위해 엉덩이를 절약합니다.

다른 사람들의 말을 정교하게

조인은 립글로스가있는 직교 제품입니다. {1,2,3,4} X {1,2,3}는 12 개의 조합을 제공합니다 (nXn = n ^ 2). 이 계산 된 세트는 적용되는 조건에 대한 참조 역할을합니다. DBMS는 조건 (왼쪽 및 오른쪽이 2 또는 3 인 경우)을 적용하여 일치 조건을 제공합니다. 실제로 더 최적화되었지만 문제는 동일합니다. 세트 크기를 변경하면 결과 크기가 기하 급수적으로 증가합니다. 소비되는 메모리 및 CPU 사이클의 양은 모두 지수 적으로 영향을받습니다.

우리가 비정규화할 때, 우리는이 계산을 완전히 피하고, 책의 모든 페이지에 색깔의 끈적 끈적한 것이 붙어 있다고 생각합니다. 참조를 사용하지 않고 정보를 유추 할 수 있습니다. 우리가 지불하는 페널티는 DBMS (최적의 데이터 구성)의 본질을 손상시키고 있다는 것입니다.