Project 2- 3일차: Database 세션 심화 [Indexing, Transaction, ACID] **

filtering/ordering/pagination/searching :
 database를 찾는거고,
실시간으로 하는 거고,

index/searching은 검색의 효율화를 위한 설정이 그런거고, 
미리 동적으로 걸어주는 게 Index, transaction 

찾는게 다름.

 

1. Indexing = 검색 

1-1. Linear Search 

하나씩 대조해서, 

이건 이름이 cold brew인가? 아니다 

그럼 또 다음 열로 가서, 이것은 cold brew인가? 아니다 

'맞다'가 될 때까지 하는 것. 

 

직선으로 한 줄씩 간다고 해서 linear search인데, 

그러면 최악의 경우, 

row 가 N개일 경우, N번하게 될 수가 있다.

---

그렇다면,

검색을 더 빨리 할 순 없을까?

 

있다 .

=> 정렬 

1-2. Binary Search 

알파벳으로 정렬 후에, 중간에서부터 시작해서,

중간지점인 M이 Cold brew인가? 아니다

 

그러면 정렬이니까, 그 이후는 알파벳순 정렬으로,

아니겠구나 하고

절반은 날려버린다. 

 

그렇다면, 남은 것의 절반인, 

D 에 가서 Coldbrew인가? 아니다.

 

그러면, D 아래의 절반은 날리고, 

남은 것의 절반인 C가 Coldbrew인가? 

맞다. 

 

그래서, 정렬을 하면, 검색 시에, linear보다 절반은 save할 수 있다는 장점,

---

Linear -> yes or no로 하는거 최악의 경우 열이 N개면 N번해야 함/ -> 정렬 

Binary -> 반씩 줄어가면서 하니까 logN / 중간에서 시작해서 up and down 

 

그렇다면, column이 여러 개이면? 

여러 column을 모두 만족하는 정렬 방법이 있나? 

 

 name 테이블은 정렬이 되어 있지만, (binary)

price 테이블은 결국 정렬 안 됐으니 한 번씩 linear로 다 해야 함 

그렇다면, 정렬 전용 테이블들을 따로 따로 만들자! 

이런 식으로!

정렬해놓은 table = indexing table 

 

Name - index table

Price - index table

product table에 

각각 column 이 name, price를 적용

동시 정렬로,

 

name = coldbrew,

price = 7500 을 찾아냄 

 

(name = coldbrew 이면서 price = 7500 는 아님. 그런 거 없음; 

두 칼럼을 정렬했을 뿐)

 

---

Indexing

-> Index Table 을 사용해서 검색을 빠르게 하는 것 

 

 

MySQL 로 Index Table 만드는 법 

CREATE INDEX [index_name] ON [tableName] (columnName)

 

 

Index table을 만들어 놓았다면,

mysql select로 하면 실행 됨 

 

같은 products 테이블에, column 이 name, price 동시 적용 가능 

where name = "coldbrew" 

where price = 7500

로 찾을 수 있다 

 

 

Index table을 만들지 않았다면,

찾을 수 없음.

 

만약 'promotion index table'을 만들지 않았다면,

select * from products where promotion 하면 Linear로 되는 것.

 

 

순서: Sql 짜고 index 작성하는 게 나음. 
순서가 바뀌면  작동 안 됨, (name price 와 price name은 다름)

 

 

용량도 포기하고 쓰는 것. 

원래 table에도 넣고, index table에도 row 추가 해야 하니까 -> write도 느려짐

 

그래서 검색 속도가 create속도보다 중요하고

디스크 데이터 용량보다 중요하다고생각 될때 사용.

 

그래서 꼭 필요한 데이터일때 index table 만들어야함

 

꿀팁: sql where구★부터 짜고, 검색 속도가 느려졌다ㄴㄴ 판단에 index 만든다 

 

데이터가 엄청 많아야 사용 -> 데이터  몇천개까지도 필요 없음 (linear search도 빠름. 몇 천개정도러는 linear vs binear 다르지 않음)

---

2. Transcation 

 

 

아이유는 300억 나가쓴데 송코딩은 받은 돈이 없게 되는 문제 

  

 

여러 쿼릴르 하나로 묶은게 transaction 

 

모두 성공하면 commit

하나라도 실패하면 롤백 

3개의 query 가 하나의 Transcation

모두가 성공 시 commit

하나의 transcation으로 묶여있기에 하나의 쿼리라도 실패하니 롤백해야

다 해야 하는 걸 묶어서, 하나라도 실패하면 보내고,  

다 성공하면 commit 

롤백이 아니면 commit/ commit하다가 실패하면 롤백 (흑과백) – >ACID의 원자성 성질로 인해 

---

면접때 ACID 아세요? 질문이 들엉로 수 도 잇다.
물어보기 쉬운 질문 - 데이터베이스 질문하다가, 대답 잘하네? 하면서 조금만 더 파보면서 들어가볼까?

현업에서 많이 안쓰이는데도 ㅇㅇ 괜히 물어봄.

깊게 알 필요없고 들얼만 봣으면 됨. 

헉 그게 뭐지? 랑 들어봣다랑은 다르니 

ACID 

transaction이 가능할 수 잇도록 관계형 데이터베이스에서 제공하는 4가지 성질 

 

 

1. 원자성 

• 보존

     2. 일관성 

• Transaction 시작전에 userstable 있었는데 끝나 ㄴ후에 없으면 안됨

 

    3. 고립성 - 모든 transaction은 서로 영향 주지 않음. (transacton A가 B에게 영향 주면 안됨 

    4. 지속성 - transaction 성공하면, commit내용은 저장된다. / 전원손실 돼도 변경 상태 유지 

이 4가지 성질이 보장돼야 한다. 

그렇기 때문에 Transaction이 가능한것.