14주차 [OS] Inter Process Communication

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/Inter Process Communication.md

@@ -0,0 +1,92 @@
+# 프로세스 간 통신 방법(Inter Process Communication, IPC)
+## 요약
+
+## 프로세스 간 통신 (Interprocess Communication, IPC)
+### 프로세스 간 통신?
+- 프로세스는 완전히 독립된 실행객체 -> 다른 프로세스의 영향을 받지 않음
+- 프로그램은 혼자 독자적으로 수행할 수도 있지만 프로그램들 사이에 정보를 교환함으로서 계산 속도를 증가시키거나 편의성을 향상시킬 수 있음
+- 각 프로세스는 자신의 독립적인 메모리 공간을 가지고 다른 프로세스들에 의해 침범당하지 않도록 보호하고 있기 때문에 프로세스 간 통신을 위해서는 별도의 메커니즘이 필요
+
+### 통신하려면?
+- 프로세스가 통신이 가능하다? -> 서로 다른 프로세스가 데이터를 주고 받을 수 있다는 것
+- 동시에 접근 가능한 메모리, **프로세스들이 공유하는 메모리가 필요**
+- 커널 영역에서 IPC라는 내부 프로세스간 통신을 제공
+
+### 커널(Kernel)?
+- 운영체제 자체도 소프트웨어이기 때문에 메모리에 올라가야 사용할 수 있음
+- 메모리를 효율적으로 사용하기 위해 **항상 필요한 부분만을 메모리에 올림**
+- 메모리에 상주하는 운영체제 = 커널(Kernel)
+	- 운영체제의 핵심적인 부분을 의미하기도 함
+
+### 종류
+- 공유 메모리 (Shared Memory)
+- 메시지 전달 (Message Passing)
+	- 메시지 큐 (Message Queue)
+- 파이프 (Pipe)
+	- 보통 파이프 (Ordinary Pipe)
+	- 지명 파이프 (Named Pipe)
+- 소켓 (Socket)
+- 메모리 맵 (Memory Map)
+- RPC (Remote Procedure Call)
+	- 세마포어 (Semaphore)
+	- 뮤텍스 
+
+## 공유 메모리 (Shared Memory)
+### 정의
+- 프로세스들 사이에 공유되는 메모리 영역을 구축하는 방법
+- 데이터 자체를 공유하도록 지원
+- 커널이 관리하며, 프로세스가 공유 메모리 할당을 커널에 요청하면 커널은 해당 프로세스에 메모리 공간을 할당
+	- 공유 메모리가 각 프로세스에게 Attach(첨부)하는 방식으로 작동
+![공유 메모리](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/OS/shared_memory.png?raw=true)   
+
+### 생성과 연결
+- 프로세스 A
+	- 공유 메모리 할당을 커널에 요청하면 메모리 공간 할당
+	- 프로세스 Stack, Heap 중간 영역에 공유 메모리가 연결되게(Attach) 되어있음
+- 프로세스 B
+	- 자신의 주소 영역에 공유 메모리를 영역
+	- A가 만든 공유 메모리를 어떤 Key로 만들었는지 알고 있음
+
+### 특징
+- 프로세스간 Read, Write를 모두 필요할 때 사용
+- 대량의 정보를 다수의 프로세스에게 배포 가능
+- 중개자 없이 곧바로 메모리에 접근 -> 모든 IPC 중 가장 빠르게 작동
+
+
+## 메시지 전달 (Message Passing)
+### 정의
+- 커널 메모리 영역에 메시지 전달을 위한 채널을 생성
+- 협려갛는 프로세스들 사이에 메시지 형태로 정보를 Send/Receive 하는 방법
+- 메시지 큐(Message Queue)를 사용
+![메시지 전달](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/OS/message_passing.png?raw=true)   
+
+
+### 메시지 큐
+- Queue를 사용해 메시지를 주고 받음 -> FIFO(First In First Out) 방식
+- 먼저 들어온 메시지를 먼저 수신하지만, 메시지 큐의 msgtype에 따라 특정 메시지를 먼저 수신할 수도 있음
+- EnQueue로 송신하고 deQueue로 수신
+![](Inter%20Process%20Communication/E6FBE8B9-166D-41F8-BC6A-B9BD34AF7261.png)
+![메시지 큐](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/OS/message_queue.png?raw=true)   
+
+> Message Queue VS Message Passing  
+
+## Shared Message VS Message Passing
+### Shared Message
+- 중계자가 없어 효율이 좋지만 다른 프로세스가 접근할 수 있도록 접근 금지를 풀어야 함
+- 동시에 같은 메모리 위치를 접근하는 문제가 발생할 수 있음
+
+### Message Passing
+- 커널의 중계를 통해 메시지를 전달하며 큐를 사용해 비교적 안전
+- Queue에 제정하고 꺼내는 과정에서 발생하는 Overhead로 인해 효율성 떨어짐 
+![공유 메모리 vs 메시지 전달](https://github.com/leeejuhyeong/images/blob/main/no-study-no-future/OS/comparison.png?raw=true)   
+
+
+## 파이프 (Pipe)
+### 정의
+- 메시지 전달(Message Passing)의 일종
+- 통신을 위한 메모리 공간(버퍼)을 생성하여 프로세스가 데이터를 주고 받음
+
+
+
+
+

Spring/생성자 주입을 사용해야하는 이유.md

@@ -0,0 +1,153 @@
+# 생성자 주입을 사용해야하는 이유
+# 요약
+- [객체의 불변성 확보](bear://x-callback-url/open-note?id=B5467B00-E1D6-4C5B-8FA4-83B1A3B2975E-1500-00000B9786F1BC1D&header=1.%20%EA%B0%9D%EC%B2%B4%EC%9D%98%20%EB%B6%88%EB%B3%80%EC%84%B1%20%ED%99%95%EB%B3%B4)
+- [테스트 코드 작성 용이](bear://x-callback-url/open-note?id=B5467B00-E1D6-4C5B-8FA4-83B1A3B2975E-1500-00000B9786F1BC1D&header=2.%20%ED%85%8C%EC%8A%A4%ED%8A%B8%20%EC%BD%94%EB%93%9C%EC%9D%98%20%EC%9E%91%EC%84%B1)
+- [final키워드 작성으로 실수를 줄이고 Lombok과의 연계가 좋다](bear://x-callback-url/open-note?id=B5467B00-E1D6-4C5B-8FA4-83B1A3B2975E-1500-00000B9786F1BC1D&header=3.%20final%20%ED%82%A4%EC%9B%8C%EB%93%9C%20%EC%9E%91%EC%84%B1%20%EB%B0%8F%20Lombok%EA%B3%BC%EC%9D%98%20%EA%B2%B0%ED%95%A9)
+- [순환 참조 에러를 사전에 방지한다](bear://x-callback-url/open-note?id=B5467B00-E1D6-4C5B-8FA4-83B1A3B2975E-1500-00000B9786F1BC1D&header=4.%20%EC%88%9C%ED%99%98%20%EC%B0%B8%EC%A1%B0%20%EC%97%90%EB%9F%AC%20%EB%B0%A9%EC%A7%80)
+
+
+# 1. 객체의 불변성 확보
+- 대부분 의존 관계 주입은 애플리케이션 종료시점까지 변하면 안됨!
+- Setter를 열어두는 것은 좋은 설계 방법이 아님(누군가 실수로 변경할 수 있음)
+-> OCP(Open/closed principle) 위배
+- 생성자 주입은 생성 시 딱 1번만 호출됨으로 불변하게 설계할 수 있음
+- final 키워드 설정 가능(불변임으로)
+
+
+# 2. 테스트 코드의 작성
+## 생성자 주입이 아닐 경우
+- 필드 주입을 사용한다면 테스트 환경은 실제 코드의 DI 프레임워크 위에서 동작하지 않고, 순수한 자바 코드로 동작 -> **Null Point Exception 에러 발생, 테스트 하는 것이 불가능**
+
+### 실제 코드
+```
+@Service
+public class UserServiceImpl implements UserService {
+
+	@Autowired
+	private UserRepository userRepository;
+
+	public UserRepository getUserRepository() {
+		return userRepository;
+	}
+}
+```
+
+### 테스트 코드
+```
+public class UserServiceTest {
+	@Test
+	public void injectionTest() {
+		UserService userSerivce = new UserServiceImpl();
+		UserRepository ur = userService.getUserRepository();
+		System.out.println(ur);
+	}
+```
+
+>  DI 프레임워크가 없는 순수한 자바 코드 테스트임으로 의존 관계 주입이 누락되어 UserRepository가 null인 NPE발생  
+
+- 위의 문제를 해결하기 위해선 Setter를 사용하면 되지만**, 싱글톤 패턴을 해칠 수 있다.** 또한 수정자 주입과 다를 바가 없으면서 수정자 주입 역시 **OCP 위배**한다는 문제가 있음
+
+> OCP(Open/closed principle) : 개방-폐쇄 원칙, 확장에 대해 열려 있어야 하고, 수정에 대해서는 닫혀 있어야 한다.  
+
+
+## 생성자 주입일 경우
+- 의존 관계 주입이 누락될 경우 **컴파일 오류**가 발생
+- 어떤 값을 필수로 주입해야하는 지 확실하게 알 수 있음!
+
+### 실제 코드
+```
+@Service
+public class UserServiceImpl implements UserService {
+
+	private UserRepository userRepository;
+
+	@Autowired
+	public UserServiceImpl(UserRepository userRepository) {
+		this.userRepository = userRepository;
+	}
+
+	public UserRepository getUserRepository() {
+		return userRepository;
+	}
+}
+```
+
+### 테스트 코드
+```
+public class UserServiceTest {
+	@Test
+	public void injectionTest() {
+		UserService userSerivce = new UserServiceImpl();
+		UserRepository ur = userService.getUserRepository();
+		System.out.println(ur);
+	}
+```
+
+> 컴파일 오류 발생 :  `java: constructor UserServiceImpl in class (패키지명).UserServiceImpl cannot be applied to given types; required: (패키지명).UserRepository`  
+
+
+# 3. final 키워드 작성 및 Lombok과의 결합
+## final 키워드 작성
+- 생성자 주입은 final 키워드 사용 가능
+-> 값 설정 누락 시 컴파일 시점에 오류 발생
+- 누락된 의존성 확인이 빠름!
+
+## Lombok과의 결합
+- `@RequiredArgsConstructor`
+-> final이 붙은 필드(변수)를 모두 모아 생성자를 자동으로 생성
+- 필드 주입보다 더 간결한 코드!
+
+> **최종 코드**  
+```
+@Service
+@RequiredArgsConstructor
+public class UserServiceImpl implements UserService {
+
+	private final UserRepository userRepository;
+}
+```
+
+
+# 4. 순환 참조 에러 방지
+## 필드 or 수정자 주입의 경우
+- 예시 (닭은 알을 낳고, 알은 닭으로 부화하고)
+```
+@Component
+public class Chicken {
+	@Autowired Egg egg;
+
+	public void layEgg() {
+		egg.hatch();
+	}
+}
+```
+
+```
+@Component
+public class Egg {
+	@Autowired Chicken chicken;
+
+	public void hatch() {
+		chicken.layEgg;
+	}
+}
+```
+
+> 두 메소드는 서로를 순환하며 호출하다가, 메모리에 CallStack이 쌓여 StackOverFlow 에러를 발생  
+
+## 생성자 주입의 경우
+- 애플리케이션 구동 시점(객체 생성 시점)에 컴파일 오류를 발생시켜 순환 참조 에러를 방지
+
+```
+Description: The dependencies of some of the beans in the application context form a cycle: 
+┌─────┐
+| chicken defined in file [(경로)/Chicken.class] 
+↑     ↓ 
+| egg defined in file [(경로)\Egg.class] 
+└─────┘
+```
+
+> 생성자 주입의 컴파일 에러가 오류 잡기 좋다..  
+
+## 출처
+- [스프링 핵심 원리 - 기본편 - 인프런 | 강의](https://www.inflearn.com/course/%EC%8A%A4%ED%94%84%EB%A7%81-%ED%95%B5%EC%8B%AC-%EC%9B%90%EB%A6%AC-%EA%B8%B0%EB%B3%B8%ED%8E%B8/dashboard)