Database 기초

스키마(Schema)

- MySQL과 ORACLE에서 다르게 사용
    - MySQL: Schema == Database
           - 데이터베이스와 동의어로 사용
        - DB 서버 1개 안에 여러 DB(스키마)가 존재

    - Oracle: Schema == User(사용자)
        - 사용자를 생성하면, 그 사용자가 소유하는 전용 공간이 생기고, 이것을 스키마라고 부름
        - DB 서버 1개 안에 여러 유저(스키마)가 존재

Oracle 구조

- Server(물리장비)
    |
    --- Instance(메모리 + 프로세스, SID)
    |
    --- Database(물리 파일)
    |
    --- Schema (User A)
    |
    --- Schema (User B)

- MySQL 구조
    |
    --- Instance(메모리 + 프로세스)
    |
    --- Database(Schema A)
    |
    --- Database(Schema B)
    |
    --- User(계정)

옵티마이저

- 데이터베이스의 두뇌, SQL을 던지면 어떤 길로 가야 가장 빠를지 결정하는 네비게이션 역할

- RBO(Rule-Based Optimizer, 규칙 기반)
    - 방식
        - 무조건 정해진 규칙대로만 감
        - 인덱스가 있으면 무조건 탄다
    - 단점
        - 융통성 없음
        - 데이터가 몇 건인지 따지지 않고 규칙 우선
        - 요즘 거의 안씀


- CBO(Cost-Based Optimizer, 비용 기반)
    - 방식
        - 통계 정보를 보고 비용을 계산해서 감
           - 인덱스가 있지만, 데이터가 많으면 Full Scan을 하는게 빠르겠다고 판단

        - 핵심 CBO가 똑똑하게 굴려면, 통계 정보가 최신 상태여야 함

인덱스 분할

- 인덱스는 정렬된 상태를 유지해야 하기 때문에, 데이터를 넣을 때(INSERT) 발생하는 고통

- 상황
    - 책장에 책이 1,2,3,5 순서로 꽂혀 있고, 책장이 꽉 참
    - 4번 책을 꽂으려고 함
    - 순서를 지켜야하니 3과 5사이에 넣어야 하는데 공간이 없음

- 현상(Split)
    - 새로운 블록을 하나 더 추가
    - 기존 책장에 있던 책의 절반을 새 책장으로 옮김
    - 빈 공간을 만들고 나서야 4를 꽂음

- 결과
    - 단순히 꽂는 것보다 엄청난 부하(I/O)가 발생
    - 인덱스가 많은 테이블에 INSERT가 느린 이유가 바로 이사다니는 비용 때문
    - 그래서 무작위로 들어오는 UUID 같은 값을 PK로 쓰면 성능이 박살남