본문 바로가기

CS 과목(CS科目）

25. DB INDEX DB 쿼리 속도를 높이는데 너무나도 중요한 것이 바로 index입니다 그래서 실무에서 매우 매우 자주 사용되는데요, 이번 시간에는 인덱스가 왜 중요한지, 어떻게 사용되는지, 동작 원리는 무엇인지 핵심만 모아서 아주 알차게 설명합니다. 그럼 오늘도 고고씽!!! 오늘날 대부분의 DBMS는 B-tree 기반의 index로 원하는 정보를 빨리 찾는다. (MySQL의 경우 B-tree 이외에도 hash index도 제공을 한다.) SELECT,DELETE,UPDATE 그리고 JOIN에서의 조건(condition)을 만족하는 tuple들을 빠르게 찾기 위해서 index를 사용한다. 아래에서 이미 table에 tuple들이 저장돼 있을 때, 어떻게 index를 생성하는지에 대해 알아 보자. name은 중복된 값을 허.. 더보기
24. DB 정규화(normalization) - Part 2 3Normal Form(3NF) EMPLOYEE_ACCOUNT Table의 FD를 시각화한 것이다. 그런데 테이블의 {empl_id,empl_name}을 보면 중복된 데이터가 너무 많은 것을 알 수가 있다. 왜 저 부분에서 중복된 데이터가 발생할 수밖에 없는지, 원인을 살펴보자. 우선, empl_id -> empl_name이라는 FD 관계에 있다. 그리고 account_id(key) -> empl_id이다. 위 2가지 FD를 좀 더 그림으로 이해해 보자. Key가 {bank_name.account_num}일 때에도 위와 같은 이유로 중복이 발생을 한다. 모든 non prime attribute는 여기서는 {class,ratio, empl_id, empl_name}에 해당 key는 {bank_name,ac.. 더보기
23. DB 정규화(normalization) - Part 1 그 전에 아래의 용어들을 짚고 넘어 가자. 1. super key : table에서 tuple들을 unique하게 식별할 수 있는 attribute set 2. (candidata) key : super key 중에서 어느 한 attribute라도 제거하면 tuple들을 unique하게 식별 못하는 super key. 3. primary key : (candidata) key 중에서 실제로 tuple을 unique하게 식별하기 위한 선택한 (candidta) key. 4. prime key : 임의의 key에 속하는 attribute. 5. non-prime key : 어떤 (candidate) key에도 속하지 않는 attribute. EMPLOYEE_ACCOUNT에 존재하는 모든 FD를 아래에서 보여.. 더보기
22.함수 종속(Functional Dependency) 위의 정의를 따라도 되지만, 나는 x의 값에 대응하는 y의 값이 오로지 1개만 있을 때, y는 x에 종속된다 or x는 y를 결정한다 라고 정의를 하겠다. 종속 관계를 위 그림의 기호로 나타낼 수가 있다. (x에 대한 y값이 오로지 1개만 존재하는 관계) Jinho라는 x값에 대해 y값이 2개가 존재하므로, 위 경우는 FD가 존재하지 않는다. 위와 같이, 테이블의 특정 부분과 특정 시점의 테이블을 보고 FD를 생각해서는 안된다. 테이블의 스키마(Schema)를 보고 의미적으로 FD가 존재하는지 파악해야 한다. (아래 참조) 위 경우는 FD이다. 위 경우는 FD가 아니다. 왜냐하면 empl_id에 대해서 dept_id가 2개 이상 존재할 수가 있기 때문이다. 1. x->y라고 해서, 반드시 y->x가 존재.. 더보기
21.DB 테이블 설계를 잘못하면 생길 수 있는 문제 JOIN 등의 연산으로 여러 테이블들을 연결시키다 보면 성능이 안 좋아지므로, 일부러 테이블을 나누지 않는 경우도 존재를 한다. 더보기
20. MVCC - Part 2 Locking Read 이번 시간에는 MySQL에서는 Lost Update 문제를 어떻게 해결해야 하는지에 대해 알아 보자. Locking Read는 MySQL에서만 사용하는 개념이다. 보통, read(x)를 하기 위해서는 SELECT balace from account where id = x 라는 SQL문을 작성을 할 것이다. MySQL에서는 Lost Update문제를 해결하기 위해서 FOR UPDATE 문을 추가적으로 개발자가 작성을 하여서, Write_Lock 을 취득하게 하여 값을 read해야 한다. 위와 같이 MySQL 세계관에서는 데이터를 읽을 때(read할 때), Lost Update 문제를 해결하기 위해 write lock을 취득한 후에 값을 읽어 들이는데, 이러한 read를 Locking.. 더보기
19.MVCC - Part 1 이전 시간에, Lock을 활영한 concurrency control에 대해서 살펴 보았다. 같은 데이테에 대해서 read-read인 경우는 허용을 하지만, 그 이외의 경우는 허용을 하지 않는다. 그래서, 트랜잭션의 Operantion에 대한 전체 처리량(throughput)이 좋지가 않았다. 개발자들은 이러한 문제를 해결하고자, write-write한 경우는 그렇다고 쳐도, read-write의 경우에는 어떻게 최적화를 시킬 수 없을까 라는 고민을 하게 되었고, 그렇게 해서 나온 아이디어가 MVCC(Multi Version Concurrency Control)이다. write-write의 경우에 대해서는 어느 한쪽을 block을 시키지만, read-read는 물론, read-write의 경우에 같은 데이.. 더보기
18. LOCK을 활용한 concurrency control 트랜잭션 1의 목적을 달성하기 위해서는 write(x=20) 작업이 필요하다. 그러나, 위 그림은 설명을 쉽게 하기 위해서 단순히 write(x=20) Operation 하나만 실행을 해주면 되는 것처럼 적어놨다. 그러나 write를 하게 될 때, 만약 index가 걸려 있다면 거기에 대한 처리도 해야 할 것이고, 이 데이터가 실제로 저장되는 파 일에 대해서도 이런 저런 처리를 해줘야 하므로, 실제로는 복잡한 실행 과정을 거쳐야 한다. 이때, 트랜잭션1의 write와 트랜잭션2의 write가 동시에 실행이 된다고 해보자. 어떠한 데이터를 write하는 과정은 복잡한 과정이므로, 같은 데이터를 트랜잭션2에서 write를 동시에 처리하게 되면, 최종 적으로 데이터가 깔끔하게 처리되지 않을 가능성이 높다. 그.. 더보기

티스토리툴바