????: 무슬림, 힌두교, 기타 종교 아이들 재끼고 크리스찬 아이들만! 우는 아이들 재끼고 웃는 아이들만! 늦게 자는 아이들 재끼고 미라클 모닝 하는 아이들만 필터링하니 몇 명 안남 더군요?...

그렇다 그는 전세계 모든 어린이들에게 선물을 줄 필요가 없었기 때문이다. 바로 "선택도"를 바탕으로 선물을 주는 쿼리를 짜고 실행하셨기 때문이지 후훗; 산타할아버지는 사실 개쩌는 DB엔지니어였다는 거지

그렇다 시작부터 그냥 대충 개소리를 느려놓으며 밀도와 선택도에 대한 이야기와 그 지표로 인덱스를 설정하는 방법에 대해 이야기할 것이다.

1. 밀도(density)

1) 정의

밀도는 테이블의 특정 컬럼이나 인덱스 키 값에 대한 고유 값의 분포를 나타내며, 쿼리 최적화 및 성능 튜닝에 중요한 역할을 합니다.

인덱스 키 값의 중복정도를 나타내기 때문에 계산법은 아래와 같다

2) 계산법

1 / 고유 값의 수 예) 탑, 미드, 정글, 원딜, 서포터 5개 포지션에 대한 밀도 1 / 5 = 0.2 이름에 대한 밀도 1 / 16 = 0.0625

밀도가 높을수록 효율이 적고 밀도가 낮을수록 효율이 높음

즉, 인덱스를 설정할 때에 밀도를 고려한다면 위와 같은 테이블은 이름 컬럼에 인덱스를 설정하는 것이 좋다.

2. 선택도(selectivity)

1) 정의

특정 값이 전체 데이터에서 차지하는 비율, 쿼리 조건이 얼마나 선택적인지(즉, 얼마나 적은 수의 행을 반환하는지)를 의미한다. 분포도라고도 불리어 진다.

2) 계산법

위와 같은 테이블을 예시로 하였을 때 아래와 같다. 조건을 만족하는 행의 수 / 전체 행의 수

포지션에 대한 선택도 서포터: 6 / 16 = 0.375 원딜: 2 / 16 = 0.125 탑: 3 / 16 = 0.1875 정글: 4 / 16 = 0.25 미드: 2 / 16 = 0.125

이름에 대한 선택도는 모두 1 / 16 = 0.0625 예시에서 알 수 있듯 컬럼자체가 아닌 쿼리의 조건을 기준으로 계산을 한다는 것이 Point!

선택도가 높을수록(비율은 낮을수록) 효율이 높고 선택도가 낮을수록(비율은 높을수록) 효율이 낮음

즉, 선택도를 고려하더라도 위와 같은 테이블은 이름 컬럼에 인덱스를 설정하는 것이 좋다.

그럼 여기서 드는 의문은 "밀도와 선택도가 다르게 나온다면 그때는 어떤 지표를 따라서 인덱스를 설정하여야 하는가?"

3. 밀도 < 선택도

1) 인덱스와 선택도의 관계

예를 들어 아래와 같은 테이블이 있다고 가정해보자.

밀도 분석: Department 열의 밀도: 1 / 고유 값의 수 (Sales, HR, IT) 고유 값의 수 = 3 밀도 = 0.333

Title 열의 밀도: 1 / 고유 값의 수 (Manager, Salesperson, Assistant, Developer) 고유 값의 수 = 4 밀도 = 0.25

선택도 분석: Department = 'Sales' 쿼리의 선택도: Sales의 행 수 / 전체 행 수 Sales의 행 수 = 3 전체 행 수 = 10 선택도 = 0.3

Title = 'Developer' 쿼리의 선택도: Developer의 행 수 / 전체 행 수 Developer의 행 수 = 4 전체 행 수 = 10 선택도 = 0.4

만일 밀도만을 생각하여 Title 컬럼에 인덱스를 설정하였다면 발생하는 문제점

1. Title = 'Developer' 쿼리의 선택도는 0.4, 이는 전체 행의 40%를 차지한다.(물론 Department컬럼에 Sales도 딱히 좋지 못함 0.3이므로) 통상적으로 선택도가 10%가 넘어간다면 인덱스를 통한 방식보다 테이블 스캔이 더 빠르다.
2. 쿼리 최적화기라는 쿼리의 효율을 높히기 위해 실행 계획을 세우는 SQL Server 구성 요소가 있는데 이 친구가 해당 인덱스가 비효율적인 것을 인지하지 못하고 잘못된 쿼리를 선택할 수 있다.

결론은 인덱스를 설정할 때는 밀도와 함께 선택도, 쿼리 패턴, 데이터 업데이트 빈도 등을 종합적으로 고려해야 한다.

2) 이상적인 인덱스 컬럼은?

이 과정에서 우리는 한 가지 알 수 있는 것이 생겼다. 인덱스는 다른 어떠한 컬럼과도 아무런 연관이 없는 것이 좋다는 것이다. 그렇지만 이러한 방법 역시 만병통치약은 아니란 것이 앞선 포스트에서 얘기하였듯이 컬럼 하나를 따로 뽑아야 할 것이기 때문에 저장 공간을 차지하기 때문에 별도의 유지비용이 든다. 그리고 다른 컬럼들이 무수히 더 추가되기 시작하면 저 하나의 ID컬럼 만으로는 감당이 안될 수도 있는 괴물 같은 쿼리가 만들어 질 수도 있다.

다시 한번 되새기자.

DB세상에 모두 좋은 것은 없다.

만약 위와 같은 상황들이 생긴다면 DB를 많이 다뤄본 고수님들은 아시겠지만 테이블을 나누어 관리하거나 상황에 맞게 여러가지 대처를 할 것이다. 그래서 정원혁 선생님께서도 뭐 이런 기타 여러가지 대응을 하기 위해서는 비즈니스 로직을 이해하고 공부하는 것이 최우선이라고 하였다!!

이상, 다음 포스트는 인덱스를 설정한 테이블에 DML을 쓰게되면 벌어지는 일에 대해 작성해보겠다! 오늘도 DB 골머리를 앓고 있을 개발자들 파이팅!!!

현재 여러 IT 회사를 다니면서 DB에 대한 문제해결 및 솔루션을 제시해주는 일을 하고 다니신다고 하셨다.

아이유가 단발이 이쁘니까 나도 이쁠꺼얌!

그렇다. 단발이 모두에게 좋은 스타일은 아니다... 이처럼 DB세상에도 모두 좋은 것은 없다... 이를 테면 인덱스랄까;

와 근데 아이유 진짜 졸라 이뿌다...

1. 인덱스란

1) 정의

데이터베이스 테이블에서 하나 이상의 컬럼에 대한 값의 순서와 위치를 미리 저장한 데이터 구조로, 빠르고 효율적인 검색 작업을 지원합니다. 인덱스는 책의 색인처럼 작동하며, 특정 데이터를 빠르게 찾을 수 있도록 도와줍니다.

정의와 동시에 인덱스의 장점이라고 볼 수 있는 내용이다. 테이블의 검색 성능을 향상시키고 책의 색인(목차)처럼 데이터가 정렬되어 있어서 데이터의 순서와 위치를 미리 저장해 두고 찾아 볼 수 있다.

2) 단점

1, 저장 공간 사용량이 증가한다. 2, DML 성능 저하의 가능성이 있다. 3, 인덱스가 많아질수록 데이터 구조가 복잡해진다.

크게 꼽자면 위의 세 가지가 가장 큰 단점이라고 볼 수 있다. 자세한 내용은 아래 인덱스에는 어떠한 종류들이 있고 어떠한 장·단점과 적재적소에 써야하는지 알아보도록 하자.

"우선, 그 전에 우리는 데이터베이스에서 데이터의 구조가 테이블에 어떠한 형태로 들어가 있는지 파악하여야 한다."

2. 인덱스 구조(feat. B-Tree)

인덱스는 B-Tree(Balanced-Tree) 구조로 구성되어 있다. 말 그대로 뿌리, 가지, 잎 순으로 균형잡힌 구조를 띄는데 이는 마치 나무를 거꾸로 뒤집어 놓은 모양이라고 생각하면 편할거 같다. 여기서 실제 데이터는 Data Level에 존재하게 된다.

실제로 테이블 인덱스가 담겨 있는 말단 페이지 하나를 Leaf Page 혹은 Leaf Node라고 하고 본인은 이하 본문 부터 Page라는 용어로 통일하도록 하겠다. 해서 이 인덱스 구조에서 실제 데이터가 어느 페이지에 있는지 그리고 해당 데이터를 물리적 or 논리적으로 어떻게 검색하는지 에 따라 인덱스의 종류가 나뉘어지느...ㄴ 솰라솰라 ㄴ어ㅜ얼ㄴ풔

결론, 인덱스는 크게 보면 두 가지다.

3. 인덱스의 종류

1) 클러스터 인덱스 (Clustered Index)

사진출처) https://gwang920.github.io/database/clusterednonclustered/

클러스터 인덱스의 가장 큰 특징은 그림과 같이 인덱스의 정보를 저장하는 가장 말단 끝 레벨인 Leaf Level에 테이블의 데이터(Data Page)가 함께 저장되어진다는 것이다.

클러스터 인덱스가 설정되어 있는 테이블은 조회시 Table Scan이 아닌 Index Seek나 Index Scan이 발생하여 빠른 시간안에 찾고자 하는 데이터를 불러올 수 있다. (단, WHERE절에서 컬럼을 Index로 잡았다면)

데이터들의 주소 정보(키값)를 담고 있는 최종 레벨이 즉 Leaf Page가 Data Page와 동일하기 때문에 테이블 스캔을 할 필요 없이 인덱스 시크나 스캔만으로 빠르게 데이터를 훑어 찾아낼 수 있는 것이다.

그래서 인덱스 씨크고 스캔이고 그게 뭔데?

본인도 정원혁 선생님께서 테이블을 만들고 쿼리를 실행해주시면서 알려줬을 때 벙쪘었다... 따라서 3만건 정도의 테이블을 만들고 나서 실험해보니 알게되었달까?

2) 클러스터 인덱스 실행 테스트 - Index Seek

CREATE TABLE Orders (
    OrderID INT PRIMARY KEY,
    CustomerID INT,
    OrderDate DATE,
    OrderAmount DECIMAL(10, 2)
);

Orders 라는 테이블을 하나 만든다 참고로 PK를 지정하게 되면 테이블에 자동적으로 클러스터드 인덱스가 생성된다.

DECLARE @i INT = 1;

WHILE @i <= 30000
BEGIN
    INSERT INTO Orders (OrderID, CustomerID, OrderDate, OrderAmount)
    VALUES (
        @i,
        (ABS(CHECKSUM(NEWID())) % 1000) + 1, -- 1 ~ 1000 사이의 임의의 CustomerID
        DATEADD(DAY, @i % 365, '2023-01-01'), -- 임의의 OrderDate (2023년 내의 날짜)
        ROUND((ABS(CHECKSUM(NEWID())) % 10000) / 100.0, 2) -- 임의의 OrderAmount (0.00 ~ 100.00)
    );

    SET @i = @i + 1;
END;

이렇게 3만건의 임의의 데이터를 만들어 넣어 주었다 여기까지 GPT형의 도움을 받아 빠르게 진행했다. 고마워요 GPT형~ 정원혁 선생님께서는 AI를 잘 활용하는 것이 더욱 미래지향적인 개발자라고 하셨다. 라고 변명변명~

각설하고 여기서 다음 두 개의 쿼리를 실행해보자

-- 특정 OrderID에 대한 조회
SELECT * FROM Orders WHERE OrderID = 15000;

-- 특정 범위의 OrderDate에 대한 조회
SELECT * FROM Orders WHERE OrderDate BETWEEN '2023-06-01' AND '2023-06-30';

우선, 해당 버튼을 클릭하여 실행 계획 창을 활성화 시켜주고 첫번째 쿼리를 실행하게 되면 아래와 같은 결과를 얻을 수 있다. 좌측은 쿼리 실행 메시지이고 우측은 실행 내용이다. 페이지 I/O가 2회 발생하였으며 이외에 동원된 자원은 없다. 여기서 "실제 읽기"란 디스크를 실제로 읽었다는 뜻이고 "미리 읽기 읽기" 란 (Read-Ahead Reads)로 순차적으로 데이터를 읽어야 하는 경우에 읽어야할 페이지를 미리 읽어 들여와 디스크에 I/O 지연을 줄여 성능을 높이는 방식이란 정도로만 알고 있으면 좋겠다. 사실 나도 잘 모른다...;; 아무튼 3만건의 데이터 중 단일 데이터를 찾는데 3만건을 모두 훑지 않고 단 2회의 디스크 읽기로 찾아낸 셈이다. 난 감탄을 금치 못하였다. 이처럼 Index Seek는 인덱스의 특정 부분만 선택적으로 읽기 때문에 높은 선택도를 필요로 한다. 선택도는 쉽게 말해 해당 테이블에서 내가 찾는 행이 얼마나 "고유한가" 에 대한 얘긴데 자세한 얘기는 다음 포스트를 통해 정리하도록 하겠다. 성능이 아주 효율적으로 일어난 Index Seek의 예시이다.

3) 클러스터 인덱스 실행 테스트 - Index Scan

그렇다면 두번째 특정 범위를 검색하는 OrderDate에 대한 검색을 해보겠다.

-- 특정 범위의 OrderDate에 대한 조회
SELECT * FROM Orders WHERE OrderDate BETWEEN '2023-06-01' AND '2023-06-30';

페이지 I/O가 총 실제읽기 1회 + 미리 읽기 101회로 총 102회가 발생하였으며 앞선 Index Seek와는 다르게 미약하게나마 경과 시간이 더 걸렸다는 점을 알 수 있다. 스캔 수1이 눈에 띄는 데 이는 OrderDate의 해당하는 범위에 인덱스를 스캔하였다는 뜻이다. 그로 인해 데이터를 순차적으로 읽어들여서 확인하여야하는 경우가 되어 버렸고 미리 읽기가 101회 발생, Index Scan이 일어났다고 볼 수 있는 것이다. 다시 말해 낮은 선택도에 의해 쿼리 실행 속도가 조금은 느려졌다고 말할 수 있을 것이다. 물론 방금까지의 예시에서 느려진 정도로는 아무런 문제가 되지 않는다. 선생님께서는 선택도가 테이블의 전체행에서 1% 미만이면 쿼리 실행에 문제가 없을 거라고 하셨다. 클러스터 인덱스를 활용할 때에는 이 선택도에 대한 것을 잘 고려하여 써야 할 것이다.

4) 넌클러스터 인덱스 (Non Clustered Index)

사진출처) https://gwang920.github.io/database/clusterednonclustered/

넌클러스터 인덱스는 Leaf Level과 Data Level이 분리되어 있고 Leaf Level에서 Data Page의 데이터 주소 정보 들고 있다.

그림에서 Leaf Level의 201페이지에 1번 행을 보면 102:1이라는 주소 정보를 담고 있다. 해당 정보를 찾아 Data Page로 이동하면 102페이지에 1번행이 한국이라는 값을 얻을 수 있는 것이다.

단, 넌클러스터 인덱스는 반드시 클러스터 인덱스를 만들고 만들어야 한다.

클러스터 인덱스와 넌클러스터 인덱스를 만드는 쿼리와 방법은 공식 문서가 있긴 하나...

선생님 피셜 공식문서는 설명이 개떡같다고 하셔..ㅅ ㄷ..;; 그래서 괜찮은 블로그를 소개해 볼까 한다.

는 개뿔 GPT 형아 한테 물어보면 잘 알려준답...;

5) 넌클러스터 인덱스 실행 테스트 - Look Up

-- 특정 CustomerID 대한 조회
SELECT * FROM Orders WHERE CustomerID = 500;

이번엔 넌클러스터 인덱스로 설정한 CustomerID를 특정해서 조회해 본 결과

?????????????????????????????????????

웬 쌩뚱맞은 중첩 루프 조인과 룩업이라는 것이 나를 반겨 주었다... 아니 반겨준게 맞는건가 당황스럽다; 그런데 생각보다 이러한 과정이 일어난 이유는 간단했다.

1, Index Seek => idx_CustomerID 인덱스를 활용하여 CustomerID = '500'으로 높은 선택도를 주었기에 Index Seek가 발생, 해당하는 OrderID를 조회한 임의에 테이블이 만들어짐 2, Look Up => Index Seek를 통해 찾은 OrderID로 나머지 데이터들을 실제 테이블에서 가져와 임의에 테이블이 만들어짐 3, 조인을 통해 두 임시 테이블을 내부 조인을 걸어 최종 쿼리 결과를 도출해냄

룩업을 통해 실제 테이블에서 데이터를 가져온다라는 뜻이 곧 Leaf Level과 Data Level이 분리되어 있다는 반증인 것이다!

참고, 중첩 루프 조인은 조인중에 가장 흔해 빠진 방식이며 선행 테이블에서 도출해낸 검색결과를 반복해서 후행테이블에서도 검색하는 방식이다. 자세한 내용은 해당 블로그 참조.

6) 넌클러스터 인덱스 실행 테스트 - Index Scan

-- 특정 범위의 OrderDate에 대한 조회
SELECT * FROM Orders WHERE OrderDate BETWEEN '2023-06-01' AND '2023-06-30';

자 이번엔 앞서 클러스터 인덱스에서 테스트했던 특정 범위에 대한 조회를 해보겠다. 앞선 클러스터 인덱스의 Index Scan과 동일한 결과가 도출되었다. 이유는 OrderDate라는 컬럼은 클러스터와 넌클러스터 어느 인덱스로도 설정되지 않은 것이였고 데이터 조회를 위해 스캔이 불가피하다는 것이 동일한 결과를 불러온 것이다.

결론, 선택도가 높은 좁은 범위의 검색은 Look Up이 발생하고 선택도가 낮은 넓은 범위에서는 Index Scan이 발생한다.

선생님께서는 말씀하셨다. 테이블의 전체행에서 10%정도의 Size면 넌클러스터 인덱스를 활용해 볼만한 가치가 있다고 하셨다.

4. 비교 분석

● 클러스터 인덱스는 리프 레벨과 데이터 레벨이 동일한 위치에 있고 넌클러스터 인덱스는 그렇지 않다.

● 클러스터 인덱스는 그로 인해 물리적인 성격으로 띄고 넌클러스터 인덱스는 Look Up을 통해 데이터 페이지에 접근하기 때문에 논리적인 성격을 띈다.

● Size는 각각 1%, 10%내의 조회량으로 예상될 때 활용하는 것이 효율적이다.

● 높은 선택도를 가정하였을 때 스캔 방식은 각각 Index Seek와 Look Up으로 나뉜다.

● 클러스터 인덱스는 인덱스 정보를 담을 별도의 공간이 필요하므로 저장 공간에 있어서는 넌클러스터 인덱스보다 불리하다.

이상 지금까지 클러스터, 넌클러스터 인덱스에 대한 강의 내용을 공부하고 풀어보았다. 이처럼 인덱스란 장단점이 있기에 모든 테이블에 적용할 수 없고 비즈니스 로직을 잘 헤아려 보아야 한다. DB세상에 모두 좋은 것은 없다 라는 말을 단편적으로 이해해보는 시간을 가져 보았다. 아직 배운 내용이 엄청 많고 그에 비해 포스트해야 될 내용도 엄청 많다. 다음에는 이 인덱스를 만든 테이블에 DML를 쓰면 어떠한 영향을 미치는지, 밀도와 선택도에 대한 이야기, Search Argument (SARG)를 통한 WHERE절 처리 방법 등을 정리해보겠다! DB세상에 모두 좋은 것은 없다 라는 말을 더욱이 깊게 느껴 질 수 있는 내용이 될 듯하다.

DB때문에 스트레스 받고있는 영혼들에게 조금이나마 도움이 되길 바라며 다들 파이팅!

ThingWorx Web Component SDK - Polymer => 문서 참고

Thingworx 컴포너트 SDK 문서 링크

Thingworx에서는 위의 빨간 밑줄 같이 PTC전용 컴포넌트가 나올때는 일반적인 CSS로 셀렉팅을 하여 CSS문법을 사용할 수 없다.

ptcs-confirmation-dialog::part(dialog) { border-radius : 27px; } ptcs-confirmation-dialog::part(primary-button), ptcs-confirmation-dialog::part(cancel-button){ border-radius : 27px; width: 160px; height: 54px; margin-left:6px;
}

아래와 같이 컴포넘트를 아무 기호없이 선언하여 파트를 찾아가면서 대 => 소로 들어가여 셀렉팅을 하여야 한다. 역시 컴포넌트 SDK 문서를 보면 아래와 같이 part부분과 subcomponents 부분을 확인하고 셀렉터를 작성하여 css를 작성할 수 있다.

한가지 예외가 있다면 바로 wc라고 하는 shadow DOM 컴포넌트를 지정하는 구분자가 나오는데 개발자 노트에서 내가 css를 작성해야할 셀렉터에 해당 구분자가 있다면 일반적인 방법으론 css를 작성할 수 없다.

따라서 이제 사장된 방법이라고 하는 @support라고 하는 문법을 써서 css 를 작성해야 한다.

@supports (ptcs-style-unit: "PTCS-GRID:grid-control:data-filter"){ [part~=top-bar]{ padding: 0 !important; } }

위는 그 방법의 예시이다.

ptcs-style-unit이라는 컴포넌트인데 이 컴포넌트는 @support 문법으로 작성하여야지 css 작성이 가능하다. 위의 컴포넌트의 css를 작성할 때 쓴 예시이다. wc 구분자로 나타나 있는 "PTCS-GRID:grid-control:data-filter"를 해당 위치에 넣고 아래에는 개발자 노트에 나와있는 part명들을 작성하여 css 작성을 마무리하면 된다. 간혹 적용하여도 바뀌지 않을 때가 있는데 이는 내가 작성하고 있는 custom css보다 상위에 css 파일에서 작성된 문법이 이미 존재하여 적용이 되지 않는 것이므로 !important를 써 css 적용 우선순위를 높여주면 된다.