13주차 [OS] Context switching

Database/인덱스를 사용하는 이유(장단점).md

@@ -0,0 +1,120 @@
+# 인덱스를 사용하는 이유(장단점)
+## 요약
+> 인덱스는 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조입니다.  
+> 사용 시 테이블 조회 속도를 높여 DB 성능을 향상시키며, Full Scan하지 않아 시스템 부하를 줄여줍니다.  
+> 하지만 항상 정렬된 상태로 유지해야하기에 추가적인 쓰기작업이 필요하며 이를 저장하기 위한 저장공간이 필요합니다. 때문에 잘못 사용할 경우 성능 저하의 역효과를 발생시킵니다.  
+
+
+## 인덱스(Index)란?
+- 데이터베이스 테이블의 검색 속도를 향상시키기 위한 자료구조.
+- 추가적인 쓰기 작업과 저장공간을 활용
+-> 이를 관리하기 위해 DB에 ~~약 10%에 해당하는~~ 저장공간 필요
+- **PK는 자동으로 Index가 생성됨** -> NHN 기출
+![인덱스 구조](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/Database/index_structure.png?raw=true)
+
+> 인덱스 없이 조회하면 모든 튜플(레코드)를 검색하지만 인덱스를 사용한다면 인덱스를 탐색하고 일치할 시에 해당 튜플로 데이터를 검색. -> 속도 **up**  
+
+
+## 인덱스를 사용하는 이유
+- 인덱스 테이블은 데이터들이 정렬되어 있음! -> **정렬과 연관지어 기억하자**
+
+### 조건 검색 Where 절의 효율성
+- 인덱스 테이블은 데이터들이 정렬되어 저장되어 있기 때문에 해당 조건(where)에 맞는 데이터를 빠르게 찾아낼 수 있음
+
+### 정렬 Order by 절의 효율성
+- 이미 정렬되어 있기 떄문에 order by에 의한 Sort과정을 피할 수 있음
+
+### MIN, MAX의 효율적인 처리 가능
+- MIN값과 MAX값을 레코드의 시작값과 끝 값 한 건씩만 가져오면 되기에 Full Scan보다 효율적  
+
+
+## 인덱스의 장단점
+### 장점
+- 테이블을 조회하는 속도와 그에 따른 성능을 향상
+- 전반적인 시스템의 부하를 줄임(Full Scan을 안해서)
+
+### 단점
+- 인덱스를 관리하기 위해 DB의 ~~약 10%에 해당하는~~ 추가적인 저장공간 필요
+- 인덱스를 관리하기 위해 추가 작업 필요
+- 잘못 사용할 경우 성능 저하의 역효과 발생
+
+
+## 인덱스 관리
+ - Index를 항상 **최신의 데이터를 정렬된 상태로 유지**해야 원하는 값을 탐색 할 수 있음
+ - INSERT, UPDATE, DELETE(데이터 추가, 수정, 삭제) 수행 시 정렬 필요! -> 부하**UP**
+ - INSERT, UPDATE, DELETE 시 추가적인 연산 필요
+ -> 부하를 최소화하기 위해 데이터 삭제라는 개념에서 **인덱스를 사용하지 않는다** 라는 작업으로 대신함
+	 - INSERT : 새로운 데이터에 대한 인덱스 추가
+	 - DELETE : 삭제하는 데이터의 인덱스를 사용하지 않는다는 작업 진행
+	 - UPDATE : 기존의 인덱스를 사용하지 않음 처리, 갱신된 데이터에 대한 인덱스 추가
+
+
+## 인덱스 생성 전략
+- 조건절에 자주 등장하는 컬럼(호출 빈도가 높음)
+- 같거나 크고, 작음으로 자주 사용되는 컬럼(where 또는 order by에서 쓰이는 컬럼)
+- 중복되는 데이터가 최소한인 컬럼(분포도가 좋다 = 데이터가 서로 다르고 넓게 퍼져 있다)
+- 조인 조건으로 자주 사용되는 컬럼
+
+
+## 인덱스 자료구조
+### 해시테이블
+- key : 데이터(= 컬럼의 값)
+- value : 데이터의 위치
+- 장점 
+	- 빠른 데이터 탐색에 유용
+	- 시간 복잡도 O(1)
+- 단점
+	- 등호 연산에만 특화
+	- DB는 부등호(>, <) 연산이 많아서 **사용 부적합**
+![인덱싱_해쉬](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/Database/indexing_hash.png?raw=true)
+
+## B+ Tree
+- 대부분의 DB 인덱싱 자료구조
+- 특징
+	- 리프노드에만 인덱스와 함께 데이터를 갖고있고, 나머지 노드들은 인덱스만을 가짐
+	- 리프노드들은 연결리스트로 이루어짐 -> 탐색이 0번노드부터 일어나는 연결리스트에 비해 시간 효율이 좋음!(log2(N))
+	- 데이터 노드의 크기는 인덱스 노드와의 크기와 같지 않아도 됨
+- 예시
+	- 인덱스
+![인덱싱_B+Tree1](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/Database/indexing_b%2Btree1.jpeg?raw=true)
+
+	- B+ Tree
+![인덱싱_B+Tree2](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/Database/indexing_b%2Btree2.jpeg?raw=true)
+
+> BTree : 모든 노드에 데이터를 담음  
+> 리프노드 : 자식이 없는 노드. 잎이라고도 함  
+> B+ Tree 알고리즘에 대해서는 추후 정리할 예정입니다.  
+
+
+
+## TMI : 결합 인덱스
+- 두 개 이상의 컬럼을 합쳐서 인덱스를 만드는 것
+- 단일 컬럼으로는 분포도가 나쁘지만, 여러 개의 컬럼을 합친다면 좋은 분포도를 가지며, where절에서 and 조건에 많이 사용되는 컬럼을 결합 인덱스로 생성함
+
+### 결합 인덱스 컬럼 생성 전략
+- where절에서 and 조건으로 자주 결합되고, 결합할 시 분포도가 좋아지는 컬럼
+- 다른 테이블과 조인의 연결고리로 자주 사용되는 컬럼
+- order by에서 자주 사용되는 컬럼
+- 하나 이상의 키 컬럼 조건으로 같은 테이블의 컬럼들이 자주 조회될 때
+
+### 예시
+- 결합 인덱스 생성 예시
+`create index emp_pay_idx on emp_pay(급여년월, 급여코드, 사원번호);`
+- 결합 인덱스 사용 예시
+```
+select * from emp_pay where 급여년월 = '202107';
+select * from emp_pay where 급여년월 = '202107' and 급여코드 = '정기급여'; 
+select * from emp_pay where 급여년월 = '202107' and 급여코드 = '정기급여' and 사원번호 = '20210401';
+```
+
+> 단 급여코드만을 검색할 때는 결합 인덱스의 첫 번째 컬럼인 급여년월의 조건식이 없기 때문에 결합 인덱스로 조회하지 않음! -> 급여년월, 급여코드, 사원번호의 순서대로 조회  
+  - 결합 인덱스 효율성 감소
+	1. LIKE 검색 : 2021%같이 검색할 경우 2021에 해당하는 모든 급여코드, 정기급여로 생성된 결합 인덱스를 조회해서 B*Tree에서 조회하기 어려움
+	2. 결합 인덱스 칼럼 순서(이하 급여년월(1), 급여코드(2), 사원번호(3) 컬럼을 숫자로 말하겠습니다)
+		- 1, 3 / 2 / 2, 3 / 3 으로 조회할 경우 결합 인덱스 순서대로 조회하지 않아서 Full Scan이 발생합니다
+
+
+- 출처
+	- [Database 인덱스(index)란? - MangKyu’s Diary](https://mangkyu.tistory.com/96)
+	- [DB 데이터베이스 인덱스(Index) 란 무엇인가?](https://coding-factory.tistory.com/746)
+	- [자료구조 그림으로 알아보는 B+Tree](https://velog.io/@emplam27/%EC%9E%90%EB%A3%8C%EA%B5%AC%EC%A1%B0-%EA%B7%B8%EB%A6%BC%EC%9C%BC%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-B-Plus-Tree)

OS/Context Switching.md

@@ -0,0 +1,132 @@
+# Context Switching
+## 요약
+- Interrupt이란 예상치 못하거나, 외부에서 발생한 이벤트, CPU 사용시간 만료 등으로 인해 프로세스를 잠시 중단하는 것
+- Context Switching란 Interrupt 발생 시 현재 프로세스의 상태를 저장하고, 새 프로세스의 저장된 상태를 다시 적재하는 작업
+- Context Switching시 시간과 비용이 발생하는데 이를 Overhead라 하며, 이를 줄이기 위해 Thread를 사용
+- Multi-Process는 overhead 비용이 발생하며, Multi-Thread는 overhead는 줄였지만 동기화 문제를 주의해야함
+
+## Context Switching
+### Context란
+- CPU가 해당 프로세스를 실행하기 위한 프로세스의 정보를 말함
+- 운영체제는 프로세스를 제어하기 위해 PCB(Process Control Block)에 프로세스 상태 정보를 저장함
+
+### Scheduling이란
+- 자원에 작업을 할당하는 행위
+- 자원은 Processor, 네트워크 연결, 외부 장치 등을 의미하며, 작업은 thread, process 혹은 data flows를 의미
+- scheduling은 scheduler라는 프로세스에 의해 수행되며, 모든 자원이 골고루 사용될 수 있게 디자인됨
+> 프로세서(Processor) : CPU 등 하드웨어 측면  
+> 프로그램(Program) : 실행 파일  
+> 프로세스(Process) : 실행 중인 프로그램  
+
+### Context Switching이 필요한 이유
+- CPU의 코어가 1개(자원이 1개)라면 동시에 단 하나의 프로세스만 실행 가능
+- 반응속도가 매우 느리고 사용하기 불편
+- 따라서 CPU Scheduling을 통해 하나의 CPU를 여러 작업들이 공유할 수 있게 CPU 시간을 나누어 작업
+- 이때 프로세서가 지금까지 실행되던 프로세스를 중지하고(Interrupt) 다른 프로세스의 PCB 정보를 바탕으로 Thread를 실행하는 것을 Context Switching이라고 함
+
+### Interrupt
+- 예상치 못하거나, 외부에서 발생한 이벤트로 인해 프로세스를 잠시 중단하는 것
+- 컴퓨터 시스템에서 발생하는 예외적인 사건을 신속히 처리하기 위한 기법
+- 종류
+	- 입출력 요청
+	- CPU 사용시간 만료
+	- 자식 프로세스 만들때
+	- 인터럽트 처리를 기다릴 때
+	- 생략
+
+### Context Switching
+- 현재 진행하고 있는 Task(Process, Thread)의 상태를 저장하고 다음 진행할 Task의 상태 값을 읽어 적용하는 과정
+- 진행과정
+	- Task 정보는 Register에 저장되고 PCB로 관리
+	- 현재 실행하고 있는 Task의 PCB 정보를 저장
+	- 다음 실행할 Task의 PCB 정보를 읽어 Register에 적재, 이전에 진행했던 과정을 연속적으로 수행
+
+### PCB(Process Control Block)
+- Process State : 프로세스 상태(Create, Ready, Running, Waiting, Terminated)
+- **PC**(Process Counter) : 다음 실행할 명령어의 주소값
+- **SP**(Stack Pointer) : 스택에 데이터가 채워진 마지막 위치를 가리키는 레지스터
+- CPU Registers : accumulator, index register, stack pointers, general purpose registers
+![PCB 구조](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/OS/PCB%E1%84%80%E1%85%AE%E1%84%8C%E1%85%A9.png?raw=true) 
+> PC, SP 중요  
+
+## 문제점
+### Cost 비용
+- Cache 초기화
+- Memory Mapping 초기화
+- Kernel은 항상 실행(메모리 접근을 위해)
+
+### Overhead
+- 사용된 시간과 사용된 메모리의 양을 의미
+- Context Switching이 잦게 발생할수록 Overhead 비용이 발생하여 성능이 떨어짐
+- P0에서 P1으로 Context Switching할 시 P1의 상태를 PCB에서 가져오는데 시간이 소요됨(P1의 유휴 상태(idle))
+![Context Switching](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/OS/ContextSwitching.jpg?raw=true)  
+
+### 해결방안
+- Context Switching은 자주 발생하기 때문에 가능한 효율적으로 구현해야하며 또한 최소한의 자료들을 주기억 장소로 옮겨야 함
+- 이를 위해 Thread를 이용
+
+### Thread Context Switching
+- 프로그램이 단일 프로세스로 생성되면 하나의 실행점(Excution)만이 존재함으로 병행 처리가 불가능
+- 프로그램이 여러 프로세스로 생성되면 각 프로세스마다 동일한 많은 정보들이 중첩 유지되어 관리되기에 비효율적
+- 단일 프로세스를 다수의 Thread로 생성하여 병행성을 증진, 실행환경을 공유
+- 최종적으로 Context Switching 시 메모리 전환이 없기에 오버헤드를 줄임
+
+## 정리
+### Multi-Process 장점
+- 독립된 구조로 안전성 높음
+- 프로세스 중 하나에 무제가 생겨도 다른 프로세스에 영향X
+
+### Multi-Process 단점 : Multi-Process Context Switching
+- context와 함께 메모리 전환도 이루어짐
+- Register 메모리 전환 이루어짐
+- Process 메모리 할당 필요
+- TLB(Transtation Lookaside Buffer) 플러싱 발생
+	- TLB는 가상 메모리 공간 할당 속도를 높여줌(물리, 가상 매핑 캐시 역할)
+	- TLB가 일어나 다시 메모리를 읽고 매핑해야 함
+- 캐싱은 메모리를 유지하여 지역성 효율을 높이는데 의미가 있지만 메모리를 재생성하기 때문에 효율이 급감
+- 결론 - context, memory, 주소 공간 모두 전환
+
+### Multi-Thread 장점
+- 시스템 자원소모 감소
+- 시스템 처리율 향상(처리비용 감소 -> Thread 간 데이터 공유)
+- 프로그램 응답시간 단축(Thread간 힙 영역 공유로 데이터 통신)
+
+### Multi-Thread Context Switching
+- context 전환만 이루어짐
+- 메모리 전환이 없기에 할당 X
+- 캐싱 효율 좋음
+- 공유 메모리라면 메모리 접근 시 지역성 효율이 높음
+- 커널 스레드 간 교환, 종료 후엔 사용자 스레드 전환
+
+### Multi-Thread 단점
+- 동기화 문제 발생(병목현상, 데드락 등)
+- 주의 깊은 설계 필요
+- 하나의 Thread에 문제가 생기면 전체 프로세스가 영향을 받음)
+
+### 비교
+- Context Switching 비용은 Process가 많이 듬
+- Thread는 Stack 영역을 제외한 모든 메모리를 공유하기 때문에 Context Switching 발생 시 Stack 영역만 변경 진행
+- 반면에 Process는 thread의 context뿐만 아니라 processor의 context까지 모두 변경해야함
+
+### 재미 요소
+- Internet Explore
+	- 멀티 스레드
+	- 메모리 사용 낮음
+	- 여러 화면 중 하나에 문제가 생기면 익스플로어 전체 종료
+- Chrome
+	- 멀티프로세스
+	- 메모리 사용 높음
+	- 하나의 탭이 문제가 되도 다른 화면에는 미치지 않음
+
+
+
+## 출처
+- [콘텍스트 스위칭(Context Switching) :: 으뜸별](https://beststar-1.tistory.com/26)
+- [OS - Context Switch(컨텍스트 스위치)가 무엇인가?](https://jeong-pro.tistory.com/93)
+- [Context Switching 이란?](https://velog.io/@curiosity806/Context-Switching%EC%9C%BC%EB%A1%9C-%EC%95%8C%EC%95%84%EB%B3%B4%EB%8A%94-process%EC%99%80-thread)
+- [2. CPU와 프로세스 · What is OS System?](https://jihooyim1.gitbooks.io/iknowosbasic/content/contents/02.html)
+- [Context Switching와 Interrupt](https://velog.io/@hayeon/Context-Switching%EC%99%80-Interrupt)
+- [OS기초 인터럽트 제대로 이해하기](https://velog.io/@adam2/%EC%9D%B8%ED%84%B0%EB%9F%BD%ED%8A%B8)
+- [OS 멀티 프로세스와 멀티 스레드 관점에서 본 Context Switching](https://velog.io/@jaeyunn_15/OS-%EB%A9%80%ED%8B%B0-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EB%A9%80%ED%8B%B0-%EC%8A%A4%EB%A0%88%EB%93%9C-%EA%B4%80%EC%A0%90%EC%97%90%EC%84%9C-%EB%B3%B8-Context-Switching)
+- [OScontext switching](https://junghyungil.tistory.com/105)
+- [멀티 프로세스(Multi Process)와 멀티 스레드(Multi Thread) - wooody92’s blog](https://wooody92.github.io/os/%EB%A9%80%ED%8B%B0-%ED%94%84%EB%A1%9C%EC%84%B8%EC%8A%A4%EC%99%80-%EB%A9%80%ED%8B%B0-%EC%8A%A4%EB%A0%88%EB%93%9C/)