use-the-index-luke 저자 Markus Winand
---------------------------------------------
Markus Winand는 SQL에 대한 통찰력을 제공하고 다양한 시스템이 SQL을 지원하는 방법을 modern-sql.com 에서 보여줍니다. 이전에 그는 use-the-index-luke.com 을 만들었는데, 지금도 활발하게 유지되고 있습니다. Markus는 winand.at 를 통해 강사, 연사 및 컨설턴트로 고용될 수 있습니다.
---------------------------------------------
You can upload a Korean translation of use-the-index-luke.com on your blog
Thank you from the bottom of my heart to author Makus Winand for allowing me.
These are translations that I use for studying by using a papago (google translate)
The translations may not be correct or there may be a typo.
I'd appreciate it if you could point it out in the comments.
---------------------------------------------
---------------------------------------------
use-the-index-luke.com 의 한글번역본을 블로그에 업로드 해도 된다고
허락해주신 Makus Winand 저자님께 진심으로 감사합니다.
이 번역본들은 제가 공부용도로 번역기(papago, google transrate)를 돌려서
번역한 내용들이라 맞지 않거나, 오타가 있을수 있습니다.
댓글로 지적해주시면 감사하겠습니다.
---------------------------------------------
https://use-the-index-luke.com/sql/testing-scalability/data-volume
ㄴ데이터 볼륨이 성능에 미치는 영향
데이터베이스에 저장된 데이터의 양은 데이터베이스 성능에 큰 영향을 미칩니다.
일반적으로 데이터베이승 추가 데이터가 있을 경우 쿼리 속도가 느려지는 것으로 간주됩니다.
그러나 데이터 볼륨이 두 배로 증가할 경우 성능에 얼마나 큰 영향을 미칩니까? 이 비율을 어떻게 개선할 수 있을까요?
데이터베이스 확장성에 대해 논의할 때 중요한 질문은 다음과 같습니다.
예를 들어 두 개의 다른 인덱스를 사용할 때 다음 쿼리의 응답 시간을 분석합니다. 인덱스 정의는 당분간 알려지지 않은 상태로 유지됩니다. 이 정의는 토론 과정에서 밝혀질 것입니다.
----------------------------------------------------------
SELECT count(*)
FROM scale_data
WHERE section = ?
AND id2 = ?
----------------------------------------------------------
SECTION이 쿼리에는 데이터 볼륨을 제어하는 특별한 목적이 있습니다.
더 큰것. SECTION 숫자가 될수록 쿼리가 선택하는 행 수가 늘어납니다. 그림3.1은 소규모 기업에 대한 응답 시간을 보여줍니다.
SECTION.
그림 3.1 성능 비교
----------------------------------------------------------
----------------------------------------------------------
두 인덱싱 모델 사이에는 상당한 성능 차이가 있습니다. 두 응답 시간 모두 여전히 10분의 1초 미만이기 때문에 대부분의 경우 느린 쿼리도 충분히 빠릅니다.
그러나 성능 차트에는 하나의 검정점만 표시됩니다.
확장성에 대해 논의한다는 것은 데이터 볼륨과 같은 환경 매개 변수를 변경할 때 성능에 미치는 영향을 살펴보는 것을 의미합니다.
----------------------------------------------------------
Important
확장성은 데이터 볼륨과 같은 요소에 대한 성능의 의존성을 보여줍니다.
성능 값은 확장성 차트의 단일 데이터 지점에 불과합니다.
----------------------------------------------------------
그림 3.2는 다음 기간 동안의 응답 시간을 보여줍니다.
SECTION 즉, 데이터 볼륨이 증가합니다.
그림 3.2 데이터 볼륨별 확장성
차트는 두 인덱스 모두에 대해 증가하는 응답 시간을 보여줍니다. 차트의 오른쪽에서는 데이터 볼륨이 100배나 높을 때 빠른 쿼리는 원래보다 두 배 이상 긴 시간이 필요하지만 느린 쿼리의 응답 시간은 20배에서 1초 이상 증가합니다.
----------------------------------------------------------
Tip
부록 C의 "예시 스키마"에는 Oracle, Postgre에서 이 테스트를 반복하기 위한 스크립트가 있습니다.
SQL 또는 SQL Server Database
----------------------------------------------------------
SQL 쿼리의 응답 시간은 여러 요인에 따라 달라집니다. 데이터 볼륨도 그 중 하나입니다. 특정 테스트 조건에서 쿼리가 충분히 빠르다고 해서 트로덕션에서 충분히 빠르다는 것을 의미하지는 않습니다. 특히 프로덕션 시스템의 데이터가 극히 일부에 불과한 개발 환경에서는 더욱 그렇습니다.
그러나 데이터 볼륨이 증가하면 쿼리 속도가 느려지는 것은 놀라운 일이 아닙니다. 그러나 두 지수 사이의 현저한 차이는 다소 예상치 못한 것입니다.
성장률이 다른 이유는 무엇입니까?
두 실행 계획을 비교하면 그 이유를 쉽게 찾을 수 있을 것입니다.
----------------------------------------------------------
------------------------------------------------------
| Id | Operation | Name | Rows | Cost |
------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 972 |
| 1 | SORT AGGREGATE | | 1 | |
|* 2 | INDEX RANGE SCAN| SCALE_SLOW | 3000 | 972 |
------------------------------------------------------
------------------------------------------------------
| Id Operation | Name | Rows | Cost |
------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 |
| 1 | SORT AGGREGATE | | 1 | |
|* 2 | INDEX RANGE SCAN| SCALE_FAST | 3000 | 13 |
------------------------------------------------------
----------------------------------------------------------
실행 계획은 거의 동일하며 다른 인덱스를 사용합니다. 비용 값에 속도 차이가 반영되더라도 실행 계획에는 그 이유가 보이지 않습니다.
우리는 "느린 인덱스 경험"에 직면한 것처럼 보입니다.
쿼리는 인덱스를 사용하지만 속도가 느립니다.
그럼에도 불구하고 우리는 더 이상 "깨진 지수"의 신화를 믿지 않습니다. 대신, 우리는 인덱스 검색을 느리게 만드는 두가지 요소, 즉(1)테이블 액세스 및 (2)광범위한 인덱스 범위 검색을 기억합니다.
두 실행 계획 모두 다음을 표시하지 않습니다.
TABLE ACCESS BY INDEX ROWID한 실행 계획이 다름 실행 계획보다 더 넓은 인덱스 범위로 검색해야하는 작업입니다. 실행 계획은 검색된 인덱스 범위를 어디에 표시합니까? 물론 Predicate information에서!
----------------------------------------------------------
Tip
Predicate information에 중의를 기울입니다.
----------------------------------------------------------
Predicate information는 위에서 했던 것처럼 당신이 생략할 수 있는 불필요한 세부사항이 결코 아닙니다. Predicate information가 없는 실행 계획이 불완전합니다.
즉, 위에 표시된 계획에서 성능 차이의 원인을 볼 수 없습니다. 전체 실행 계획을 살펴보면 차이를 알 수 있습니다.
----------------------------------------------------------
------------------------------------------------------
| Id | Operation | Name | Rows | Cost |
------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 972 |
| 1 | SORT AGGREGATE | | 1 | |
|* 2 | INDEX RANGE SCAN| SCALE_SLOW | 3000 | 972 |
------------------------------------------------------
Predicate Information (identified by operation id):
2 - access("SECTION"=TO_NUMBER(:A))
filter("ID2"=TO_NUMBER(:B))
------------------------------------------------------
| Id Operation | Name | Rows | Cost |
------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 13 |
| 1 | SORT AGGREGATE | | 1 | |
|* 2 | INDEX RANGE SCAN| SCALE_FAST | 3000 | 13 |
------------------------------------------------------
Predicate Information (identified by operation id):
2 - access("SECTION"=TO_NUMBER(:A) AND "ID2"=TO_NUMBER(:B))
----------------------------------------------------------
----------------------------------------------------------
Memo
실행 계획은 명확하게 하기 위해 단순화되었습니다. 부록에서는 Oracle 실행 계획의 "Predicate Information" 섹션에 대한 자세한 내용을 설명합니다.
----------------------------------------------------------
이제 차이는 분명합니다. SECTION의 조건만 sclae_slow 인덱스를 사용할 때 access prdicate 입니다. 데이터베이스는 섹션에서 모든 행을 읽고 ID2의 filter predicate 와 일치하지 않는 행을 삭제합니다.
응답 시간은 섹션의 행 수에 따라 증가합니다.
SCALE_FAST 인덱스를 사용하면 데이터베이스는 모든 조건을 access predicate로 사용합니다. 응답 시간은 선택한 행의 수에 따라 증가합니다.
----------------------------------------------------------
Important
Filter predicates 는 불발탄과 같습니다. 그것들은 언제든지 폭팔할 수 있습니다.
----------------------------------------------------------
우리 퍼즐에서 마지막으로 빠진 조각들은 인덱스 정의입니다 실행 계획에서 인덱스 정의를 재구성할 수 있습니까?
SCALE_SLOW 인덱스의 정의는 SECTION 열로 시작해야 합니다. 그렇지 않으면 access predicate로 사용할 수 없습니다. ID2의 조건은 access predicate가 아니므로 인덱스 정의의 SECTION을 따를 수 없습니다.
즉, SPECTION이 첫 번째이고 ID2가 두번째가 아닌 세 개 이상의 열이 있어야 합니다.
이 테스트에 사용된 인덱스 정의는 다음과 같습니다:
----------------------------------------------------------
CREATE INDEX scale_slow ON scale_data (section, id1, id2)
----------------------------------------------------------
두 번째 위치의 열 ID1로 인해 데이터베이스에서 ID2를 access predicate로 사용할 수 없습니다.
SCALE_FAST 인덱스의 정의는 처음 두 위치에 SECTION과 ID2 열이 있어야 합니다. 둘 다 access predicate에 사용되기 때문입니다. 그럼에도 불구하고 우리는 그들의 주문에 대해 아무 말도 할 수 없습니다.
테스트에 사용된 인덱스는 섹션 열로 시작하며 세번째 위치에 추가 열 ID1 이 있습니다.
----------------------------------------------------------
CREATE INDEX scale_fast ON scale_data (section, id2, id1)
----------------------------------------------------------
이 인덱스의 크기가 SCALE_SLOW와 동일하도록 열 ID1이 추가되었습니다. 그렇지 않으면 크기가 차이를 유발한다는 인상을 받을 수 있습니다.
----------------------------------------------------------
Links
- Index filter predicates explained: Greater, Lesser and Between Conditions
- Finding index filter predicates in the Oracle database, PostgreSQL and SQL Server.
- Indexing LIKE Filters: index access and filter predicates in one expression.
- Big-O notation: The mathematical approach to scalability.
----------------------------------------------------------
'use-the-index-luke' 카테고리의 다른 글
| 3.3 Response Time and Throughput (0) | 2023.09.18 |
|---|---|
| 3.2 System Load (0) | 2023.09.15 |
| 3장 Testing and Scalability (0) | 2023.09.09 |
| 2.7-5 Math (0) | 2023.09.08 |
| 2.7-4 Smart Logic (0) | 2023.09.01 |
