Database Optimizer
DEPT (100건)
# deptno
* dname
* loc
EMP (10만건)
# empno
* ename
* sal
* job
* deptno
위와 같은 Table이 2개 있을 때 아래 Query문 실행시켰다고 할 때
SELECT B.dname, A.empno, A.ename, A.sal
FROM EMP A, DEPT B
WHERE A.deptno = B.deptno
1. DEPT를 Drive 해서 찾는게 빠를까 ? (DEPT를 먼저 Full-Scan 하면서 EMP에서 해당되는 Data를 검색)
아니면 2. EMP를 Drive해서 찾는게 빠를까 ? (EMP를 Full-Scan 하면서 DEPT에서 해당되는 Data를 검색)
1번의 경우 DEPT를 Full-Scan 하면서 DEPT의 #deptno 를 상수화 하여 EMP에서 해당 Data를 찾는다.
ex) DEPT의 첫번째 Data의 첫번째 #deptno가 101 이라면 EMP에 *deptno에는 index가 없으므로
EMP에서 Full-Scan하여 *deptno 가 101인 것을 찾는다. #deptno 1건에 대해서 100만건을 Scan해야 하므로
전체적으로 읽는 횟수는 100 X 10만 이므로 1000만건 을 읽어야 한다.
2번의 경우 EMP의 *deptno를 상수화 하여 DEPT의 #deptno에서 같은 Data를 찾는다. DEPT의 #deptno는 index가 있으므로
해당 Data를 바로 찾을수가 있다. 즉 10만건 X 1건 이므로 10만건을 읽는 속도라고 생각을 할 수 있다.
정답은 2번이다.
D/B Optimizer의 경우 Join시 Index가 있는 쪽과 없는 쪽이 각각 있다면 없는 쪽을 무조건 먼저 Drive한다.
Database Performance
위의 예 같은 경우 일부에서는 Join 비용을 줄이기 위하여 *deptno 와 *dname 을 EMP Table에 중복으로 복사를 해서 사용하는 경우도 많이 있다. 이럴 경우 정말로 성능이 빨라지는가 ?
D/B 성능(Performance)는 Disk I/O 양에 의해 결정된다. D/B는 Data를 Block 단위로 읽는다.
만약 한번 I/O Block의 크기를 4Kbytes 라고 가정 했을 때
DEPT의 1 row data의 크기를 30 Bytes라고 가정하고 EMP의 1 row data 크기를 40 Bytes 라고 가정했을 해보자.
그리고 EMP Table에 DEPT의 *dname을 추가로 넣었을 경우 1 row data 크기를 55 Bytes 라고 가정해보자.
Join 없이 역정규화 하여 Data를 중복으로 저장할 경우 55 Bytes X 10만건 = 55MBytes 를 읽어야 하며
원래대로 읽을 경우 30Bytes X 100건 = 3KBytes , 40 Bytes X 10만건 = 40MBytes 의 합인 40M + 3KBytes를 읽으면 된다.
Block 수로 따졌을 경우 앞의 경우는 13,750 Block을 읽어야 하지만, 뒤의 경우는 1만Block + 1 Block만 읽으면 된다.
역정규화를 해서 성능이 좋아졌다면, 원래 Query문 자체가 문제가 있는 것이라고 생각하면 된다.
Database Modeling
대부분의 경우 Process 중심의 Modeling을 한다. Application의 기능/화면을 먼저 설계하고 각각 화면에 맞는 Table을 설계하는 경우가 많다. 이럴 경우 나중에 Process가 바뀌게 되면 Data Modeling을 다시 하게 되는 경우가 많이 발생한다.
솔직히 아무리 Data Modeling이 잘못되더라도 Application에서 해결이 다 가능하다. if-then-else 면 해결 안되는게 없다.
하지만 성능은 보장 할 수가 없다. 제대로 설계된 Database에서 적절한 Query를 사용하면 Optimizer가 제대로 동작을 한다.
처음부터 Data 중심적으로 설계를 한다면, 나중에 Process가 바뀌더라도 Data는 안바뀌어도 된다.
처음부터 설계시 Data 중심적으로 Database Modeling을 해야 한다.
DEPT (100건)
# deptno
* dname
* loc
EMP (10만건)
# empno
* ename
* sal
* job
* deptno
위와 같은 Table이 2개 있을 때 아래 Query문 실행시켰다고 할 때
SELECT B.dname, A.empno, A.ename, A.sal
FROM EMP A, DEPT B
WHERE A.deptno = B.deptno
1. DEPT를 Drive 해서 찾는게 빠를까 ? (DEPT를 먼저 Full-Scan 하면서 EMP에서 해당되는 Data를 검색)
아니면 2. EMP를 Drive해서 찾는게 빠를까 ? (EMP를 Full-Scan 하면서 DEPT에서 해당되는 Data를 검색)
1번의 경우 DEPT를 Full-Scan 하면서 DEPT의 #deptno 를 상수화 하여 EMP에서 해당 Data를 찾는다.
ex) DEPT의 첫번째 Data의 첫번째 #deptno가 101 이라면 EMP에 *deptno에는 index가 없으므로
EMP에서 Full-Scan하여 *deptno 가 101인 것을 찾는다. #deptno 1건에 대해서 100만건을 Scan해야 하므로
전체적으로 읽는 횟수는 100 X 10만 이므로 1000만건 을 읽어야 한다.
2번의 경우 EMP의 *deptno를 상수화 하여 DEPT의 #deptno에서 같은 Data를 찾는다. DEPT의 #deptno는 index가 있으므로
해당 Data를 바로 찾을수가 있다. 즉 10만건 X 1건 이므로 10만건을 읽는 속도라고 생각을 할 수 있다.
정답은 2번이다.
D/B Optimizer의 경우 Join시 Index가 있는 쪽과 없는 쪽이 각각 있다면 없는 쪽을 무조건 먼저 Drive한다.
Database Performance
위의 예 같은 경우 일부에서는 Join 비용을 줄이기 위하여 *deptno 와 *dname 을 EMP Table에 중복으로 복사를 해서 사용하는 경우도 많이 있다. 이럴 경우 정말로 성능이 빨라지는가 ?
D/B 성능(Performance)는 Disk I/O 양에 의해 결정된다. D/B는 Data를 Block 단위로 읽는다.
만약 한번 I/O Block의 크기를 4Kbytes 라고 가정 했을 때
DEPT의 1 row data의 크기를 30 Bytes라고 가정하고 EMP의 1 row data 크기를 40 Bytes 라고 가정했을 해보자.
그리고 EMP Table에 DEPT의 *dname을 추가로 넣었을 경우 1 row data 크기를 55 Bytes 라고 가정해보자.
Join 없이 역정규화 하여 Data를 중복으로 저장할 경우 55 Bytes X 10만건 = 55MBytes 를 읽어야 하며
원래대로 읽을 경우 30Bytes X 100건 = 3KBytes , 40 Bytes X 10만건 = 40MBytes 의 합인 40M + 3KBytes를 읽으면 된다.
Block 수로 따졌을 경우 앞의 경우는 13,750 Block을 읽어야 하지만, 뒤의 경우는 1만Block + 1 Block만 읽으면 된다.
역정규화를 해서 성능이 좋아졌다면, 원래 Query문 자체가 문제가 있는 것이라고 생각하면 된다.
Database Modeling
대부분의 경우 Process 중심의 Modeling을 한다. Application의 기능/화면을 먼저 설계하고 각각 화면에 맞는 Table을 설계하는 경우가 많다. 이럴 경우 나중에 Process가 바뀌게 되면 Data Modeling을 다시 하게 되는 경우가 많이 발생한다.
솔직히 아무리 Data Modeling이 잘못되더라도 Application에서 해결이 다 가능하다. if-then-else 면 해결 안되는게 없다.
하지만 성능은 보장 할 수가 없다. 제대로 설계된 Database에서 적절한 Query를 사용하면 Optimizer가 제대로 동작을 한다.
처음부터 Data 중심적으로 설계를 한다면, 나중에 Process가 바뀌더라도 Data는 안바뀌어도 된다.
처음부터 설계시 Data 중심적으로 Database Modeling을 해야 한다.
댓글 없음:
댓글 쓰기