오늘 한 일:
- 기초강의: 데이터 베이스
내일 할 일:
- 배민찬 Step3 리팩토링
- 배민찬 step4 진행
회고
운영체제를 꼭 공부해야 되겠다
DATABASE
RDBMS: ER모델을 바탕으로 만들어진 DBMS
최초의 rdbms : system-R 과 ingres
graphdb
postgress
noSQL: Sql이 아닌 db
- sql(sequel): 관계형 db의 중심 기술
- mongodb, neo4j, elasticsearch 등
rdbms
- oracle, mysql, ms-sql, db2, postgreSQL
redis: 매우빠름
elasticsearch: 검색전용
DB관련용어
CAP
- consistency(일관성): 똑같은 요청에 항상 똑같은 응답
- availablity(가용성): 서버의 다운타임이 없다(연중무휴)
- partition tolerence: 서버 여러대가 있을 때 하나가 망가더라라도 db가 돌아간다 - 최소 3대
ACID
- atomicity(원자성): 트랜잭션이 중간에 멈출경우(커밋되지 않을경우) 그냥 실패시킴
- 값도 원자성을 가져야함(배열값은 값이 테이블에 못들어 간다)
- consistency(일관성): 무결성을 해치지 않는다
- isolation(고립성): 현재 서버에 오퍼레이션이 혼자 실행되는 것(실제로는 동시에 실행되는데 안그런것 처럼 보여야함)
- 멀티쓰레드에서 발생하는 문제를 동기화로 해결하는 방법과 같음
- durablity(내구성): 데이터 한 번 저장하면 안깨진다
트랜잭션? : A transaction is a unit of a program execution that accesses and possibly modifies various data objects
운영체제의 잠금 공부하기
serial schedule: 한번에 하나식 실행된다
프로세스와 쓰레드
- 프로세스(program in execution): 프로그램이 실행중이다 = 메모리에 프로그램이 올라가서 CPU에서 계산한다: 현재 실행되고 있는 코드(코드부분과 데이터 부분등으로 구성된다): 디스크 > 메모리에 올라간다
- 쓰레드: 명령어가 실행되는 흐름(프로세스에는 최소 한 개의 쓰레드가 있다)
명령어는 워드 단위
명령어가 어디까지 실행된 흐름을 포인터로 가리키고 있다
흐름은 한 CPu에서 돌아간다
크롬은 멀티 쓰레드
멀티쓰레드에 의해 발생되는 문제를 해결하는 방법 동기화
ERD와 DB설계
개념적 설계: ERD가 탄생(누가 해석해도 똑같은 의미의 무언가)
논리적 설계: db에 넣을 수 있는 데이터가 탄생
물리적 설계: db에 어떻게 저장할지(요즘은 대부분 소프트웨어가 자동화함)
해당개체를 구분하는 유니크한 속성: 키 속성(밑줄)
ERD
ERD: entity-relationship diagram
entity: 개체 (사각형으로 표시)
- 속성 (타원형으로 표시)
relation: 엔티티간의 관계 (관계도 속성을 가질 수 있다)
약개체: 혼자만으로는 유니크한 속성이 없을 때(부양가족)
- 관계를 맺는 쪽을 이용하여 유니크하게 할 수 있다
다른 필드에 의존적인 속성은 점점점으로 표현(number of emloyee)
복수의 값으로 이루어진 속성은 두개 의 타원형으로 표현
table
1대 1관계에서는 속성을 하나에만 넣으면 되는데
- null값이 적게 생성되는 경우로 선택
외래키: 다른 테이블의 pk(primary key)를 참조, 참조 무결성 제약조건을 따라야 한다
- 참조 무결성 제약조건: 기본키의 유효범위 또는 null값 이어야 한다
- 관계의 속성은 외래키가 들어가는 테이블에 들어간다
관계가 m:n일경우
// 사원이 여러 프로젝트를 맡을 수 있는경우
// 사원의 프로젝트 당 일한 시간을 속성으로 두고자 한다
emp (eid, ...)
proj (pid, ...)
새로 테이블을 만든다
- 이때 pk는 두개가 된다(복합키 pk)
emp-proj (eid, pid, workinghour)
// eid와 pid가 동시에 기본키가 된다
JOIN
inner join: 없는 레코드는 안보여줌
left outer join: 왼쪽 테이블의 없는 레코드도 보여줌
right outer join: 오른쪽 테이블의 없는 레코드도 보여줌
양쪽 다 보이려면 UNION을 이용
Join 복잡도
inner join은 O(n*m)의 복잡도: 너무 느리다
- 카테시안 조인(
CROSS조인):where절이 없는 조인
방법
조인하지 않고 하나의 테이블로 한다(중복 되더라도 성능은 빠르다): 역정규화
DISK
기계적인 HDD <-> 전자적인 SSD
디스크는 순차접근이 빠르다(돌면서)
한 번당 블록단위로
저장 방법
row store: 레코드 순서대로 저장, 일반적인 방법
column store: 컬럼 순서대로 저장, 분석에 용이
OLTP와 Analytics
레코드는 정렬되어있을까?
정렬 안됨(그럼 유일함 체크는? index이용)
b+tree
pk에는 유니크함을 조사해야 되므로 자동으로 b+tree 인덱스가 생김 > clustered index가 생김
- 따라서 pk로 찾는게 매우 빠르다
그럼 다른 필드 검색은 어떻게 할 까??
키워드에 또 인덱스를 만듦 > 그 인덱스는 pk인덱스를 가리킴 : secondary index
join
sort merge join: 정렬이 되어잇는 상태에서 조인
CREATE INDEX …를 이용해서 특정 필드에 인덱스를 설정하면 검색속도가 빨라짐
책추천: 데이터베이스 첫걸음