JVM

Java Virtual Machine 의 약자로 “자바 가상머신” 이라는 뜻

가상 머신이란 가상의 기기를 만들어주는 것을 의미한다.

다시 말해서, 여러가지의 기기위에 Java 프로그램을 실행시킬 수 있는 가상의기기를 만들어주는 것을 의미한다.

놀이터 그림으로 표현하자면 흐름은 아래와 같다.

CompileTime - RunTime

Java 의 놀이터 구성하기 (개발환경 구성)

Java 의 놀이터인 JVM 을 설치하는 방법은 JRE를 설치하는 것이다.

JRE

JRE 는 Java Runtime Environment 즉, 자바 실행 환경 이라는 뜻

하지만, JRE(JVM) 만 있다면 Java 프로그램을 실행만 시킬 수 있다.

JRE 는 .class 파일만 실행 가능하다.

JDK 가 javac 명령을 통해 .java 파일을 실행가능한 .class 파일로 변환해준다.

Java 의 놀이터기능과 함께 Java 프로그램을 개발할 수 있는 JDK 라는것이 있다.

JDK

JDK 는 Java Development Kit 즉, 자바 개발 키트 라는 뜻

우리는 Java 프로그램을 개발할 것 이기 때문에 JDK 를 설치해야한다.

JDK 는 위의 그림처럼 JRE(JVM)의 기능을 포함하고 있다.

JDK는 .java 파일들을 .class 파일들로변환해주는 Java Compiler(javac) 기능이 있다.

JDK는 코드를 디버깅하는 jdb 등의 기능이 있다.

• JDK 디버깅 기능

  JDK 의 Jdb 기능을 통해서 실행중인 프로그램의 코드 실행을 따라다니며 볼 수 있다.

  • Java 프로그램을 실행한다는 것은 곧 Java 코드를 한줄씩 실행하면서 명령을 수행하는것을 의미한다.

  • 우리가 개발한 코드들을 한줄씩 객체와 메소드를 수행하면서 변수들도 변하는 과정을 우리가 볼 수있도록 JDK(자바 개발 키트)는 코드를 따라가면서 변수를 볼 수 있는 “디버깅” 기능을 제공한다.

  • 내가 작성한 코드 라인에 “중단점” 을 설정하고 “디버그” 모드로 프로그램을 실행하면, 프로그램이 중단점의 코드라인을 수행할때 프로그램 흐름이 일시정지되며 변수들을 볼 수 있게 도와준다.

PC에서 개발한 소프트웨어는 보통 메모리가 24GB 만 있어도 충분히 실행할 수 있는데 서버실에 있는 서버는 3264GB 메모리를 가지고 있기 때문에 대량의 소프트웨어를 실행해야 한다.

하지만 IT 서비스로 제공되는 소프트웨어가 다운된다면 서비스의 장애로 이어지기 때문에 1 서버 1 소프트웨어 실행이 안전하다. 그런데 64GB 서버에서 4GB 소프트웨어 하나만 실행하면 낭비가 아닐까?

가상화

이로 인해 "가상화"라는 기술을 사용하여 1 서버 n 소프트웨어 실행을 가능하게 한다.

예전부터 사용하던 가상화 방식은 VM(Virtual Machine) 가상머신 이라는 방식을 사용했는데 프로그램을 실행하고 업그레이드 하는데에 시간이 오래 걸렸다.

이에 반해 컨테이너 가상화 방식은 기존의 가상화 기술보다 가볍고 빠르다는 장점이 있어서 안전하고 효율적인 소프트웨어의 운영이 가능하다.

Docker

이러한 컨테이너를 관리하기 위한 일종의 프로그램이 도커이다.

k8s

그런데 도커마저 여러 대를 운영하면 관리하기 힘들어지는데 이를 관리해주는 오케스트레이션 도구가 쿠버네티스이다. 개발자가 원하는 상태를 문서로 정리한다면 k8s는 알아서 도커 컨테이너를 관리해준다.

정리

• 컨테이너 : 한 대의 서버에서 여러 개의 소프트웨어를 안전하고 효율적으로 운영할 수 있는 가상화 방식

• 도커 : 컨테이너를 관리하기 위한 도구로 일종의 프로그램

• 쿠버네티스 : 서버가 여러 대 있는 환경에서 각각의 서버의 도커에게 대신 지시해주는 오케스트레이션 도구

출처

개발자를 위한 쉬운 도커 (2024 NEW) | 컨테이너, 도커, 쿠버네티스의 개념을 엄청 쉽게 알려드려요. https://www.youtube.com/watch?v=eRfHp16qJq8&t=331

아침에 AWS 6300원이 결제되었다는 알림이 왔다 2/23 에 분명 인스턴스 다 껐는데 .. 뭐지?

VPC 에서 요금이 발생했었다

원인은 탄력적 IP 주소가 활성화 되어있기 때문

탄력적 IP 들어가서 삭제하자 (릴리스)

바로 완치. (내돈 ㅠ)

쿠키와 세션은 HTTP 프로토콜의 특징이자 약점을 보완하기 위해 사용한다.

HTTP 프로토콜은 비연결지향과 상태정보 유지 안함이라는 특징을 가지고 있다. 따라서 서버와 클라이언트가 통신을 할 때 통신이 연속적으로 이어지지 않고 한 번 통신이 되면 끊어진다. 또한 통신이 끊어지면 상태정보가 유지되지 않기 때문에 매번 페이지를 이동할 때마다 로그인은 다시 하거나, 상품 선택 후 구매 페이지에서 선택한 상품의 정보가 없거나 하는 등의 문제가 발생할 수 있다.

이러한 문제를 해결하는 방법이 바로 쿠키와 세션이다.

쿠키(Cookie)

HTTP 의 일종으로 사용자가 어떤 웹 사이트를 방문할 경우, 해당 사이트가 사용하고 있는 서버에서 사용자의 컴퓨터에 저장하는 작은 기록 정보 파일이다.

HTTP 에서 클라이언트의 상태정보를 쿠키 형태로 클라이언트 PC에 저장하였다가 필요 시 정보를 참조하거나 재사용할 수 있다.

특징

• Key-Value 쌍으로 구성되어 있는 데이터 파일이다.

• 쿠키이름, 쿠키값, 만료시간, 전송할 도메인명, 전송할 경로, 보안연결여부, HttpOnly 여부로 구성되어 있다.

• 도메인 당 20개의 쿠키를 가질 수 있다.

• 하나의 쿠키는 4KB(= 4096 byte)까지 저장이 가능하다.

작동 방식

1. 클라이언트가 서버에 로그인 요청

2. 서버는 클라이언트의 로그인 요청의 유효성을 확인하고(아이디와 비밀번호 검사) 응답헤더에 set-cookie: 를 통해 쿠키를 추가하여 응답

3. 클라이언트는 이후 서버에 요청할 때 전달받은 쿠키를 자동으로 요청헤더에 추가하여 요청한다. 헤더에 쿠키값을 자동으로 추가하여 주는데 이는 브라우저에서 처리해주는 작업이다.

쿠키의 기한이 정해져 있지 않고 명시적으로 지우지 않는다면 반 영구적으로 쿠키가 남아있다.

사용 목적

쿠키는 주로 3가지 목적을 위해 사용한다.

1. 세션 관리(Session Management)

   로그인, 사용자 닉네임, 접속 시간, 장바구니 등의 서버가 알아야할 정보들을 저장

2. 개인화(Personalization)

   사용자마다 다르게 그 사람에 적절한 페이지를 보여줄 수 있다.

3. 트래킹(Tracking)

   사용자의 행동과 패턴을 분석하고 기록

쿠키값 확인 및 단점

브라우저 개발자도구의 네트워크에서 쿠키값을 확인할 수 있지만, 가독성이 떨어지고 수정이 불가능하다. 하지만 '브라우저의 쿠키 관리 탭' 또는 '쿠키 관리 플러그인'을 설치하면 쿠키를 쉽게 수정할 수 있다.

이러한 쿠키는 클라이언트에서 수정할 수 있기 때문에 위변조의 위험이 항상 존재한다. 따라서 쿠키값(value)를 암호화해야 하며, 민감하거나 중요한 정보를 담지 않도록 해야한다.

세션(Session)

일정 시간 동안 같은 사용자(브라우저)로부터 들어오는 일련의 요구를 하나의 상태로 보고, 그 상태를 유지시키는 기술이다.

여기서 일정 시간은 방문자가 웹 브라우저를 통해 웹 서버에 접속한 시점부터 웹 브라우저를 종료하여 연결을 끝내는 시점을 말한다.

즉, 브라우저가 종료되기 전까지 클라이언트의 요청을 유지하게 해주는 기술을 세션이라고 한다.

특징

• 웹 서버에 웹 컨테이너의 상태를 유지하기 위한 정보를 저장한다.

• 웹 서버에 저장되는 쿠키(세션 쿠키 / session cookie)이다.

• 브라우저를 닫거나, 서버에서 세션을 삭제했을 때만 삭제가 되기 때문에 쿠키보다 비교적 보안적으로 우수하다.

• 저장 데이터에 제한이 없다. (서버 용량 허용 범위 내에서)

• 각 클라이언트에 고유 세션 ID(Session ID)를 부여한다. 세션 ID를 통해 클라이언트를 구분하여 각 요구에 맞는 서비스를 제공한다.

작동 방식

1. 클라이언트가 서버에 로그인 요청

2. 서버는 클라이언트의 로그인 요청의 유효성을 확인하고(아이디와 비밀번호 검사) unique한 id를 session ID로 생성하여 저장한다.

3. 서버가 응답할 때 응답헤더에 세션 ID를 쿠키에 추가하여 응답합니다.

4. 클라이언트는 이후 서버에 요청할 때 전달받은 세션 ID를 쿠키에 자동으로 요청 헤더에 추가하여 요청한다.

5. 서버에서는 요청 헤더의 세션 ID 값을 저장된 세션 저장소에서 찾아보고 유효한지 확인 후 요청을 처리하고 응답한다.

사용 목적

사용자나 다른 누군가에게 노출되면 안되는 보안적으로 중요한 정보들을 서버 안에서 다루기 위해 사용한다.

단점

세션의 내용은 서버에 저장되기 때문에 계속하여 늘어날 경우 서버에 부하가 발생할 수 있다. 또한 세션에 대한 정보가 서버에 있어 쿠키에 비해 비교적 속도가 느리다.

차이점

1. 저장 위치

쿠키 : 클라이언트의 웹 브라우저가 지정하는 메모리 또는 하드디스크

세션 : 서버의 메모리에 저장

2. 만료 시점

쿠키 : 클라이언트에 설정된 만료 날짜까지 유지, 만료 날짜를 설정하지 않으면 브라우저를 닫을 때까지 유지

세션 : 클라이언트가 웹 애플리케이션에 접속하는 동안 유지되며, 클라이언트가 웹 브라우저를 종료하거나 세션을 만료시키는 경우에만 제거

3. 리소스

쿠키 : 클라이언트에 저장되고, 클라이언트의 메모리를 사용하기 때문에 서버 자원을 사용하지 않음

세션 : 서버에 저장되고, 서버의 메모리로 로딩되기 때문에 세션이 생길 때마다 리소스를 차지함

4. 용량 제한

쿠키 : 클라이언트도 모르게 접속되는 사이트에 의해 설정될 수 있기 때문에 쿠키로 인한 문제가 발생하는 것을 막기 위해 한 도메인 당 20개, 한개의 쿠키 당 4KB로 제한

세션 : 클라이언트가 접속하면 서버에 의해 생성되므로 개수나 용량 제한 없음

정리

세션와 쿠키를 모두 사용하는 이유

세션이 쿠키에 비해 보안이 높은 편이나 쿠키를 사용하는 이유는 세션은 서버에 저장되고, 서버의 자원을 사용하기 때문에 서버 자원에 한계가 있고, 속도가 느려질 수 있다. 따라서 자원관리 차원에서 쿠키와 세션을 적절한 요소 및 기능에 병행 사용하여 서버 자원의 낭비를 방지하며 웹사이트의 속도를 높일 수 있다.

출처

https://velog.io/@octo__/쿠키Cookie-세션Session#쿠키cookie와-세션session을-사용하는-이유

REST(Representational State Transfer)는 월드 와이드 웹과 같은 분산 하이퍼미디어 시스템을 위한 소프트웨어 아키텍처의 한 형식

1. REST는 기본적으로 웹의 기존 기술과 HTTP 프로토콜을 그대로 활용하기 때문에 웹의 장점을 최대한 활용할 수 있는 아키텍처 스타일이다.

2. REST는 네트워크 상에서 Client와 Server 사이의 통신 방식 중 하나이다.

자원을 이름(자원의 표현)으로 구분하여 해당 자원의 상태(정보)를 주고 받는 모든 것을 의미한다. 즉, 자원의 표현에 의한 상태 전달

1. 자원(resource)의 표현(representation)

• 자원 : 해당 소프트웨어가 관리하는 모든 것 ex) 문서, 그림, 데이터, 해당 소프트웨어 자체 등

• 자원의 표현 : 그 자원을 표현하기 위한 이름 ex) DB의 학생 정보가 자원일 때, ‘students’를 자원의 표현으로 정한다.

2. 상태(정보) 전달

• 데이터가 요청되어지는 시점에서 자원의 상태(정보)를 전달한다.
• JSON 혹은 XML를 통해 데이터를 주고 받는 것이 일반적이다.

개념을 간단히 표현하자면, HTTP URI를 통해서 자원을 명시하고 HTTP Method(POST, GET, PUT, DELETE)를 통해서 명시된 자원의 CRUD(Create, Read, Update, Delete)를 요청하는 API를 작성하는 것이라 할 수 있다.

RESTful API의 조건

REST 아키텍처는 다음과 같은 특성을 지켜야 한다.

Uniform Interface (인터페이스 일관성)

인터페이스가 일관되어야 한다. URI로 지정한 리소스에 대한 조작을 통일되고 한정적인 인터페이스로 수행할 수 있어야 한다는 것이다. RESTful API라면 HTTP 표준 프로토콜을 따르는 모든 플랫폼에서 사용이 가능하다.

Stateless (무상태성)

API 호출한 클라이언트 상태에 대한 정보를 따로 서버에 저장하고 관리하지 않는다. 이에 따라 API 서버는 들어오는 요청에 대한 처리만 할 수 있어 서비스의 자유도가 높아지고 구현이 단순해지는 특징을 가지고 있다.

Cacheable (캐시 처리 가능)

HTTP라는 기존의 웹 표준을 활용하기 때문에, 캐시 기능을 사용할 수 있다. 잘 관리되는 캐싱은 클라이언트-서버 간의 상호작용을 부분적으로 또는 완전히 제거하여 성능을 향상시킬 수 있다고 한다.

Self-descriptiveness (자체 표현 구조)

REST API 메세지만 보고도 쉽게 이해할 수 있는 구조로 표현되어야 한다. HTTP Method 명칭이 자체 표현 구조를 따르는 예시라고 할 수 있다.

Client-Server 구조

Client와 Server의 역할이 확실히 구분되어야 하며, 서로간 의존성을 낮출 수 있어야 한다. 서버는 API를 제공하고 비즈니스 로직 처리 및 데이터 저장에 책임이 있으며, 클라이언트는 사용자 인증이나 상태정보를 직접 관리하는 것에 책임이 있다.

Layered System (계층형 구조)

REST API 서버는 다중 계층으로 구성되어 있어야 한다. RESTful API 서버는 순수 비즈니스 로직을 수행하는 API 서버와 그 앞단에 사용자 인증, 암호화, 로드 밸런싱을 하는 계층을 추가해서 구조상의 유연성을 둘 수 있다.

REST API URI 설계 가이드

1. 소문자를 사용하고 단어는 언더바가 아닌 하이픈으로 구분

여러 단어를 나열해야 하는 경우 카멜 표기법이 아닌 하이픈을 활용한 소문자로 URI를 만들어야 한다.

2. 슬래시 구분자로 계층 관계를 표현하고 마지막에는 포함시키지 않는다

정확한 계층 관계를 표현할 수 있어야 하기 때문에, 마지막에 포함시키지 않도록 하여 혼란을 주지 않아야 한다.

3. URI에서는 리소스에 대한 행위를 포함시키지 않는다

리소스에 대한 행위는 HTTP Method를 통해서 충분히 전달이 가능하다. 명료한 URI 작성을 위해서 리소스에 대한 행위를 포함시키지 않도록 하라.

4. 파일 확장자를 URI에 포함시키지 않는다

리소스 자료의 포맷을 URI 안에 포함시키지 않아야 한다. Request의 헤더에 Accept 속성을 통해서 파일의 형식을 지정해 줄 수 있다.

정리

REST 하게 만든 API 를 RESTful API 라고 한다. REST에서 말하는 모든 REST 아키텍처 스타일을 지켜야만 진정한 의미의 RESTful API 라고 말할 수 있다.

- Uniform Interface (인터페이스 일관성)
- Stateless (무상태성)
- Cacheable (캐시 처리 가능)
- Self-descriptiveness (자체 표현 구조)
- Client-Server 구조
- Layered System (계층형 구조)

REST API 설계 규칙

소문자 사용과 하이픈(-) 사용
슬래시(/) 로 계층 관계 표현, 마지막은 불포함
리소스에 대한 행위 불포함
파일 확장자 불포함

그러나 모든 API가 모든 요소를 엄격하게 준수할 필요는 없으며, 상황에 따라 유연하게 적용될 수 있다.

출처

https://tedjunny.tistory.com/entry/RESTful한-API-설계하기 https://hahahoho5915.tistory.com/54

HTTP 프로토콜의 Keep-Alive 기능은 클라이언트와 서버 간 요청 및 응답 과정을 효율적으로 유지하기 위해 사용된다. Keep-alive 를 활성화하면 하나의 TCP 연결을 여러 번 재사용하며 응답과 요청을 수행할 수 있다.

Keep-Alive

HTTP 프로토콜에서 클라이언트와 서버 간 여러 요청을 단일 TCP 연결을 재사용하는 방식으로 처리하는 기능을 말한다. HTTP/1.1 프로토콜부터 도입됐다. 이 기능을 활성화하면 여러 HTTP 요청 및 응답 과정에서 발생하는 네트워크 오버헤드를 줄일 수 있다.

keep-alive를 사용하는 경우 HTTP 요청 헤더에 Connection: Keep-Alive 라는 값을 포함시킨다.

HTTP/1.1 200 OK
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html; charset=utf-8
Date: Thu, 11 Aug 2016 15:23:13 GMT
Keep-Alive: timeout=5, max=1000
Last-Modified: Mon, 25 Jul 2016 04:32:39 GMT
Server: Apache

(body)

사용 이점

keep-alive가 없으면 클라이언트와 서버는 각 요청과 응답에 대해 매번 새로운 TCP 연결을 생성하고 닫아야 한다. 이 방식은 네트워크 리소스가 비효율적으로 사용된다. 반면 keep-alive를 사용하면 단일 TCP 연결에서 여러 요청과 응답이 이루어지기 때문에 네트워크 지연 시간이 줄어들고 웹 사이트 성능이 좋아진다.

초기 HTTP/1.0 프로토콜에서는 각 HTTP 요청에 대해 매번 TCP 연결을 새로 생성해야 했기 때문에 위에서 언급한 문제들이 존재했다. 이를 해결하기 위해 HTTP/1.1 프로토콜에 해당 기능이 도입됐다.

위 이미지는 4개의 트랜잭션에 대해 연속적으로 4개의 커넥션을 생성하여 처리하는 방식과 하나의 지속 커넥션으로만 처리하는 방식을 비교한 이미지이다.

후자에서는 커넥션을 맺고 끊는 데 작업이 없어졌기 때문에 시간이 단축되었다.

keep-alive 의 상황을 비유하자면, 전화 통화하는 상황을 떠올릴 수 있다. 
한 고객이 고객센터에 전화를 걸어 제품에 대해 궁금한 정보를 하나씩 묻는다고 해보자. 
이때 하나의 질문을 할 때마다 대답을 듣고 전화가 끊어진다고 생각해 보자. 
전화를 걸고 다시 물어보는 과정이 반복된다면 매우 피곤할 것이다. 
한번 연결된 전화를 통해 모든 궁금증을 해결할 수 있는 편이 훨씬 효율적이다.

예시

1. Image를 4개를 보여주어야 한다.

2. Client는 동시에 2개의 Image만 받아올 수 있다.

3. Image는 받아오는데 2초가 걸린다.

4. Port를 여는데 1초가 걸린다.

keep-alive 비활성화

처음 Server에 2개의 Port를 열고 Image를 받고 Client Socket의 닫는다. ( 3초 ) 
다시 Server에 2개의 Port를 열고 Image를 받고 Client Socket의 닫는다. ( 3초 ) 
총 6초가 걸린다.

keep-alive 활성화

처음 Server에 2개의 Port를 열고 Image를 받는다. ( 3초 ) 
재요청 시 기존에 열어 둔 Port로 Image를 받아온다. ( 2초 )
총 5초가 걸린다.

정리

HTTP 프로토콜은 클라이언트가 서버에 요청을 보내고 서버가 응답을 보내는 동안에만 연결을 유지한다. 이후에는 연결이 종료되고 다시 연결을 맺어야 한다.

하지만 Keep Alive 를 사용하면 클라이언트와 서버 간의 연결을 유지할 수 있다. 이는 웹 페이지를 로드하는 데 필요한 추가 연결 설정 시간을 줄여 성능을 향상시킬 수 있다.

출처

https://change-words.tistory.com/entry/HTTP-Keep-Alive https://goodgid.github.io/HTTP-Keep-Alive/

송신측의 데이터 전달과 네트워크의 데이터 처리 속도 차이를 해결하기 위한 기법

한 라우터에 데이터가 몰리는 경우 등의 네트워크 혼잡을 피하기 위해 송신측에서 보내는 데이터의 전송속도를 강제로 줄이는 작업이다.

네트워크 내에 패킷의 수가 과도하게 증가하는 현상을 방지하는 현상도 혼잡제어라고 한다.

송신측과 수신측의 전송속도를 다루는 흐름제어와 달리, 혼잡 제어는 호스트와 라우터를 포함한 넓은 관점에서의 전송 문제를 다룬다.

Congestion 의 발견

TCP 는 송신한 패킷에 대해서 ACK 를 수신한다. 만약 정해진 시간이 지날 때까지 ACK 가 도착하지 않으면 congestion 이 발생한 것으로 판단한다. (timeout)

ACK(acknowledgment)

데이터 통신에서 수신자가 송신자에게 데이터를 정상적으로 받았음을 알리는 신호

Window Size

TCP 통신에서 데이터를 전송하는 속도를 조절하는 중요한 매개변수이다. TCP는 데이터를 전송할 때 수신 측이 데이터를 수신할 수 있는 만큼의 윈도우 크기를 설정하게 된다. 이 윈도우 크기는 데이터를 얼마나 많이 한 번에 전송할 수 있는지를 결정하며, 네트워크 성능과 효율에 영향을 미친다.

혼잡제어 해결방법

1. AIMD (Additive Increase / Multicative Decrease) 합 증가 / 곱 감소

패킷을 하나씩 보내고 문제없이 도착하면 윈도우 크기(단위 시간 내에 보내는 패킷의 수)를 1씩 증가시켜가며 전송하는 방법

만약 패킷 전송을 실패하거나, 일정시간을 넘으면 패킷을 보내는 속도를 절반으로 줄이게 된다.

매우 공평한 방식으로, 여러 호스트가 한 네트워크를 공유하고 있으면 나중에 진입하는 쪽이 불리하지만, 시간이 지날수록 평행상태로 수렴하는 특징이 있다.

2. Slow Start (느린 시작)

합 증가 / 곱 감소 방식과 마찬가지로, 패킷을 하나씩 보내는 것부터 시작하고, 패킷이 문제 없이 도착하면 각각의 ACK 패킷마다 윈도우 크기를 1씩 늘려준다.

위와 같은 방법으로 한 주기가 지나면 윈도우 크기는 2배가 되며, 이러한 전송속도는 지수 함수의 꼴로 증가한다.

만약 혼잡제어 현상이 발생하면, 윈도우 크기를 1로 떨어뜨린다.

Cwnd(congestion window)

송신자가 현재 네트워크 상황에 맞춰 전송할 수 있는 데이터의 양을 나타낸다.

TCP 통신에서는 데이터를 전송할 때마다 이 Cwnd 크기에 따라 전송량이 조절된다.

혼잡 회피(Congestion Avoidance)

Congestion 이 발생한 것으로 판단되면(timeout), 전송되는 패킷의 양을 초기 상태로 줄여서 다시 시작한다.

TCP Tahoe 방식

이외에도 TCP Reno, TCP-SACK, TCP-New Reno, TCP-Vegas, TCP Cubic, Multipath TCP ...

정리

TCP Congestion Control 은 네트워크에서 발생할 수 있는 혼잡 현상을 관리하고 해결하기 위한 기능의 집합이다. 이러한 기능들은 네트워크에서의 데이터 전송 과정에서 발생할 수 있는 혼잡을 감지하고 조절하여 네트워크 성능을 최적화하고 데이터의 손실을 최소화한다.

출처

TCP : 체증 제어/혼잡 제어 (congestion control) https://www.youtube.com/watch?v=4TvP_-3KBH4&t=1493

락은 대표적인 동시성 제어 기법 중 하나로, 데이터베이스의 일관성과 무결성을 유지하기 위해 트랜잭션의 순차적 진행을 보장할 수 있는 직렬화 장치이다.

일반적으로 락은 둘 혹은 그 이상의 사용자가 동시에 같은 데이터를 접근하는 것을 방지하기 위해 사용한다.

트랜잭션만으로는 해결할 수 없는 요청이 유실되는 경우가 발생하는 갱신 손실 문제나 동시에 발생하는 따닥 요청등을 해결할 때 사용한다.

낙관적 락(Optimistic Lock)

자원에 락을 걸어서 선점하지말고, 동시성 문제가 발생하면 그때 가서 처리 하자는 방법론이다.

• 트랜잭션의 충돌이 발생하지 않을 것이라고 기대한다.

• 일단 충돌이 나는 것을 막지 않고, 충돌이 난 것을 감지하면 그때 처리한다.

• 일반적으로 version 의 상태를 보고 충돌을 확인하며, 충돌이 확인된 경우 롤백을 진행시킨다. (hashcode나 timestamp를 이용해서 충돌을 확인할 수도 있다.)

• DB 단에서 동시성을 처리하는것이 아닌, 어플리케이션 단에서 처리한다.

유저가 동시에 TILTE 데이터를 수정하는 상황

장점

• 충돌이 안난다는 가정하에, 동시 요청에 대해서 처리 성능이 좋다.

  단점

• 잦은 충돌이 일어나는 경우 롤백 처리에 대한 비용이 많이 들어 오히려 성능에서 손해를 볼 수 있다.
• 롤백 처리를 구현하는게 복잡할 수 있다.

비관적 락(Pessimistic Lock)

자원 요청에 따른 동시성 문제가 발생할 것이라고 예상하고 락을 걸어버리는 방법론이다.

• 트랜잭션의 충돌이 발생한다고 가정한다.

• 하나의 트랜잭션이 자원에 접근시 락을 걸고, 다른 트랜잭션이 접근하지 못하게 한다.

• 데이터베이스에서 Shared Lock(공유, 읽기 잠금) 이나 Exclusive Lock(배타, 쓰기 잠금) 을 건다.

• Shared Lock 의 경우, 다른 트랜잭션에서 읽기만 가능하다. 또한 Exclusive lock 적용이 불가능하다. (읽는 동안 변경하는 것을 막기 위해)

• Exclusive lock 의 경우, 다른 트랜잭션에서 읽기, 쓰기가 둘다 불가능하다. 또한 Shared, Exclusive Lock 적용이 추가적으로 불가능하다. (쓰는동안 읽거나, 다른 쓰기가 오는것을 막기위해)

장점

• 충돌이 자주 발생하는 환경에 대해서는 롤백의 횟수를 줄일 수 있으므로 성능에서 유리하다.
• 데이터 무결성을 보장하는 수준이 매우 높다.

  단점

• 데이터 자체에 락을 걸어버리므로 동시성이 저하되는 성능 손해를 많이 보게 된다. 특히 읽기가 많이 이루어지는 데이터베이스의 경우에는 손해가 더 두드러진다.
• 서로 자원이 필요한 경우에, 락이 걸려있으므로 데드락(Deadlock)이 일어날 가능성이 있으며, 이에 대한 처리가 필요하다.

데드락이란?

두 개 이상의 프로세스나 스레드가 서로가 가진 자원을 대기하며 무한히 기다리는 상황

정리

낙관적락

데이터에 대한 동시 액세스를 허용하되, 충돌을 검출하여 데이터의 일관성을 유지한다. 실제로 데이터 충돌이 자주 일어나지 않을 것이라고 예상되는 시나리오에서 좋다.

비관적락

데이터에 대한 액세스를 다른 프로세스로부터 차단하여 데이터의 일관성을 유지한다. 데이터의 무결성이 중요하고, 충돌이 많이 발생하여 잦은 롤백으로 인한 효율성 문제가 발생하는 것이 예상되는 시나리오에서 좋다.

출처

낙관적 락 VS 비관적 락 - 김영수 | 백엔드 데브코스 3기 | 20230203 https://www.youtube.com/watch?v=SoQ4ExWnetg&t=336s https://unluckyjung.github.io/db/2022/03/07/Optimistic-vs-Pessimistic-Lock/

릴레이션이란?

릴레이션(relation)은 데이터베이스에서 정보를 구분하여 저장하는 기본 단위이며, 엔티티에 관한 데이터를 데이터베이스에서 릴레이션에 담아서 관리한다.

릴레이션은 일종의 표 형태로, 행과 열의 집합으로 구성된다. 각 행은 레코드나 튜플이라고 불리며, 각 열은 속성(attribute)이라고 불린다.

RDBMS에선 릴레이션을 테이블 이라 하며, NoSQL에선 컬렉션 이라 부른다.

함수적 종속성(Functional Dependency)

완전 함수적 종속(Full Functional Dependency)

완전 함수적 종속이란, 종속자가 기본키에만 종속되며, 기본키가 여러 속성으로 구성되어 있을경우 기본키를 구성하는 모든 속성이 포함된 기본키의 부분집합에 종속된 경우이다.

해당 릴레에션의 기본키는 '고객ID'와 '상품코드' 속성으로 구성되어 있다. 여기서 '수량' 속성은 기본키를 구성하는 '고객ID', '상품코드' 속성을 모두 알아야 식별할 수 있다. 따라서 '수량'은 완전 함수 종속된 관계이다.

부분 함수적 종속(Partial Functional Dependency)

부분 함수적 종속이란, 릴레이션에서 종속자가이 기본키가 아닌 다른 속성에 종속되거나, 기본키가 여러 속성으로 구성되어 있을경우 기본키를 구성하는 속성 중 일부만 종속되는 경우이다.

기본키가 '고객ID' 와 '제품코드' 속성으로 구성된 위의 릴레이션에서 '주문상품'은 기본키 중 '제품코드'만 알아도 식별할 수 있다. 이 경우에는 '주문상품' 속성은 기본키에 부분 함수 종속된 관계이다.

제1 정규형(1NF)

릴레이션을 구성하는 모든 도메인이 원자값으로 된 정규형

제2 정규형(2NF)

제1 정규형을 만족하면서 릴레이션에 존재하는 부분 함수적 종속을 제거하여, 모든 속성이 기본키에 완전 함수 종속이 되도록 만들어진 정규형

이행적 함수 종속(Transitive Functional Dependecy)

릴레이션에서 X, Y, Z라는 3 개의 속성이 있을 때 X→Y, Y→Z 이란 종속 관계가 있을 경우, X→Z가 성립될 때 이행적 함수 종속이라고 한다. 즉, X를 알면 Y를 알고 그를 통해 Z를 알 수 있는 경우를 말한다.

이 릴레이션에서 '상품번호'를 알면 '소분류'를 알 수 있고, '소분류'을 알면 '대분류'도 알 수 있다. 따라서 '상품번호'를 알면 '대분류'를 알 수 있으므로 이행적 함수 종속 관계이다. 이 때, 대분류는 소분류에 의해 관계되는 항목이지만, 상품번호를 통해 귀속되어있다. 따라서 이런 관계를 이행적 함수 종속이라고 한다.

제3 정규형(3NF)

제2 정규형을 만족하면서 릴레이션을 구성하는 속성들 간의 이행적 종속관계를 분해하여 속성들이 비이행적 함수 종속관계를 만족하도록 만들어진 정규형

릴레이션의 분석 지침

릴레이션이 잘 설계되었는지, 문제는 없는지 간단히 확인하는 기본 지침

기본 지침을 체크해보면, 잘 설계되었는지 대략적으로 확인할 수 있다.

1. 스키마에서 속성의 의미가 명확한지 확인한다.

속성의 이름을 의미적으로 모호하지 않게 작명해야 한다.

-> 회원 테이블의 경우, 날짜 시간 이라고 작명하기 보다는, 더 명확하게 가입 날짜 시간 이라고 작명해준다.

-> 게시글 데이터를 저장하기 위해 만든 게시글 릴레이션에는 게시글과 관련된 속성만 존재하게 한다.

위 예시처럼, 게시글 번호 를 기본키로 하는 게시글 릴레이션에 회원번호 작성자 이름 작성자 생년월일 등과 같은 게시글과 관계가 먼 속성들이 존재하여 데이터가 중복되는 부분들이 많이 생기면 메모리 문제, 중복 문제 뿐만 아니라 다른 문제도 야기할 수 있다.

2. 튜플들에서 중복되는 값들이 있는지 확인한다.

삽입 이상

실수로 작성자의 이름을 김수민으로 잘 못 입력될 수 있다. 나중에, 릴레이션의 튜플들을 확인했을 때, 회원 번호 1번이 김민수 인지 김수민 인지 확실하게 알 수 없어 릴레이션의 신뢰성을 잃게된다.

수정 이상

회원 번호 1번인 회원의 이름을 특정한 이유로 일부만 변경되었을 때(실수로) , 삽입 이상 때와 같은 이유로 릴레이션의 신뢰성을 잃게된다.

삭제 이상

3번 게시글 튜플을 삭제 시, 게시글과 관련된 제목 , 내용 과 같은 데이터는 이유가 있어 삭제했다고 해도, 회원과 관련된 데이터도 모두 사라지게 된다. 이는, 데이터 누락을 야기하게 된다.

3. 튜플들에 저장된 NULL 값을 확인한다.

속성에 NULL 값이 빈번하게 저장되면, 불필요한 저장 공간을 사용하게 된다. -> 속성에 빈번하게 NULL 값이 저장된다는 의미가, 불필요한 정보라는 의미로 받아들일 수 있다. 따라서, 메모리 관점에서 이러한 속성이 해당 릴레이션에서 필수적인 속성인지 검토해볼 필요가 있다.

NULL 값이 존재하면, 튜플의 의미가 모호해지거나 통계적 관점에서도 쓸모없는 데이터가 되어버리기 때문에, 별도의 릴레이션으로 분리하는 것을 고려하는 것이 좋다.

4. 가짜 튜플이 생성되는지 확인한다.

위와 같은 경우가 릴레이션을 잘못 분리한 예시이다.

릴레이션을 분리했다가 다시 합쳤을 뿐인데, (0003,데이터베이스,A0003) 과 같은 이전에는 존재하지 않았던 튜플이 생성되었고, 이를 가짜 튜플 이라고 한다.

이처럼, 릴레이션을 적절하게 분리하지 않거나, 잘못된 설계를 하면, 두 릴레이션을 JOIN 할 시 가짜 튜플 을 만들어 낸다.

정리

정규화

• 제2 정규형 : 릴레이션에 존재하는 부분 함수적 종속을 제거하여, 모든 속성이 기본키에 완전 함수 종속이 되도록 만들어짐

• 제3 정규형 : 릴레이션을 구성하는 속성들 간의 이행적 종속관계를 분해하여 속성들이 비이행적 함수 종속관계를 만족하도록 만들어짐

릴레이션의 분석 지침 4가지

• 릴레이션의 속성이 명확하게 작명되었는지 확인

• 릴레이션의 데이터가 중복되는 부분이 많은지 확인

• 속성 데이터가 NULL 값이 빈번하게 존재한다면, 필요한 속성인지 검토

• 릴레이션 분리 시, 적절하게 분리되어 가짜 튜플을 생성하지 않는지 확인

출처

https://dodo000.tistory.com/20 https://swingswing.tistory.com/15 https://inkyu-yoon.github.io/docs/Learned/DataBase/RelationRule#1-스키마에서-속성의-의미가-명확한지-확인한다

하지만 특정 문자나 문자열이 포함되어 있는지를 검색하고 싶은 경우도 많을 것이다.

이런 경우 LIKE 를 사용하여 패턴 매칭으로 검색할 수 있다.

LIKE 로 패턴 매칭

LIKE 를 사용하면 열 값이 부분적으로 일치하는 경우에도 참이 된다.

// LIKE 조건식
열명 LIKE '패턴'

LIKE 는 이항 연산자처럼 왼쪽에 매칭 대상을 지정하고 오른쪽에는 패턴을 문자열로 지정한다. 단, 수치형 상수는 지정할 수 없다.

패턴을 정의할 때는 % 그리고 _와 같은 메타문자를 사용할 수 있다.

와일드 카드라고 불리는 메타문자는 패턴 매칭 시 임의의 문자 또는 문자열에 매치하는 부분을 지정하기 위해 쓰이는 특수 문자이다.

퍼센트%는 임의의 문자열을 의미하고 언더스코어_는 임의의 문자 하나를 의미한다.

메타문자가 없어도 조회는 가능하지만 이럴 경우 완전 일치로 검색되므로 LIKE 를 사용하는 의미가 없어진다.

SELECT * FROM sample25;

예제 테이블의 text 열에서 'SQL' 문자열을 포함하는 행을 패턴 매칭으로 검색해보자

SELECT * FROM sample25 WHERE (text LIKE 'SQL%');

분명 no 열이 3인 행도 SQL 문자열을 포함하는데 조회 결과에 포함되지 않은 이유가 무엇일까?

그 이유는 text 열의 데이터가 SQL 문자열로 시작하지 않았기 때문이다. 다시 말해 SQL 문자열 앞에도 문자열이 존재하므로 % 메타문자를 패턴 앞에도 붙여줘야 한다.

SELECT * FROM sample25 WHERE (text LIKE '%SQL%');

LIKE로 %를 검색하기

예제 테이블에서 no열이 2인 행의 text열 값을 보면 메타문자인 %와 _가 포함되어 있다.

만약 메타문자와 동일한 문자로 LIKE로 검색할 경우 어떻게 패턴을 정의해야 할까?

프로그래밍 언어에서는 이런 경우 대체로 이스케이프라는 방법으로 처리한다.

이스케이프 문자\를 메타문자 앞에 붙이면 메타문자도 패턴에 사용할 수 있다.

SELECT * FROM sample25 WHERE (text LIKE '%\%%');

문자열 상수 ' 의 이스케이프

메타문자는 이스케이프로 처리할 수 있음을 확인하였다.

그렇다면 패턴과 같이 문자열 상수 안에 '를 포함하고 싶다면 어떻게 해야 할까?

이때는 이스케이프 문자가 아니라 동일한 문자인 '를 앞에 한 번 더 붙여주면 된다.

WHERE (text LIKE 'It''s')

위의 예시를 보면 실제로 It's라는 문자열을 검색하는 명령임을 알 수 있다.

정리

= 연산자로는 동일한 값만 비교 가능한 아쉬움을 패턴 매칭으로 해결할 수 있음을 알게 되었다.

하지만 보다 복잡한 패턴을 비교해야 하는 경우는 패턴 매칭보다는 정규 표현식(Regular Expression)을 사용하는 편이 더 나을 수 있다.

대부분의 데이터베이스가 정규 표현식을 지원하고 정규 표현식이 더 많은 메타문자를 지원하기 때문에 간단한 패턴에 대해서 이러한 패턴 매칭을 사용하면 훨씬 유연하게 조회를 할 수 있을 것이다.

출처

https://lxxjn0-dev.netlify.app/first-step-sql-lec-08

특정 조직의 여러 사용자가 '공유'하여 사용할 수 있도록 '통합'해서 '저장'한 '운영' 데이터의 집합이다

• 공유 데이터 : 특정 조직의 여러 사용자가 함께 소유하고 이용할 수 있는 공유 데이터

• 통합 데이터 : 최소의 중복과 통제 가능한 중복만 허용하는 데이터

• 저장 데이터 : 컴퓨터가 접근할 수 있는 매체에 저장된 데이터

• 운영 데이터 : 조직의 주요 기능을 수행하기 위해 지속적으로 꼭 필요한 데이터

특징

• 데이터의 구조화 : 데이터를 구조화하여 저장한다. 이는 데이터가 쉽게 검색, 추가, 삭제, 수정될 수 있도록 도와준다.

• 데이터의 독립성 : 데이터와 응용프로그램을 독립시킨다. 이는 데이터의 논리적 구조와 물리적 구조를 분리함으로써 데이터베이스 시스템의 유연성을 높여준다.

• 동시성 제어 : 여러 사용자가 동시에 접근할 수 있도록 해준다. 이 때, 데이터베이스 시스템은 데이터의 일관성을 유지하기 위해 동시성 제어를 수행한다.

• 데이터의 보안성 : 데이터의 무결성과 안전성을 보장하기 위한 다양한 보안 메커니즘을 제공한다.

• 데이터의 지속성 : 시스템 장애나 비정상적인 종료 상황에서도 데이터를 지속적으로 보존한다.

장단점

장점

• 데이터 중복 최소화 : 중복을 피함으로써 데이터 일관성을 유지하고 저장 공간을 절약할 수 있다.

• 데이터의 일관성 : 데이터의 일관성을 유지하기 위한 동시성 제어와 트랜잭션 처리를 제공하여 데이터의 정확성을 보장한다.

• 데이터의 공유성 : 여러 사용자가 동시에 데이터에 접근할 수 있도록 허용하여 데이터의 공유성을 제공한다.

• 데이터의 보안성 강화 : 데이터베이스 시스템은 다양한 보안 메커니즘을 제공하여 민감한 데이터를 보호한다.

• 데이터의 표준화 : 데이터의 구조화와 표준화를 통해 데이터의 일관성을 유지하고 관리하기 쉽게 해준다.

단점

• 비용 : 데이터베이스 시스템을 구축하고 유지보수하는 데에는 비용이 많이 들 수 있다.

• 복잡성 : 데이터베이스는 복잡한 구조를 가질 수 있으며, 이를 이해하고 관리하기 위해서는 전문적인 지식이 필요하다.

• 시스템의 종속성 : 데이터베이스 시스템을 선택하면 해당 시스템에 종속되는 경우가 있을 수 있다.

• 보안 문제 : 데이터베이스에 저장된 정보는 해킹, 무단 접근 등의 보안 위협에 노출될 수 있다. 이에 대한 보안 대책이 필요하다.

• 성능 문제 : 대용량의 데이터베이스를 다룰 때 성능 저하가 발생할 수 있으며, 이를 최적화하기 위해 추가적인 노력이 필요할 수 있다.

정리

데이터베이스는 데이터를 구조화하여 효율적으로 관리하고 사용할 수 있도록 하는 매우 중요한 도구이다. 하지만 구축 및 유지보수 비용, 복잡성, 보안 문제 등의 단점도 고려해야 한다.

그래서 dump 를 하기 위해 AWS 계정을 받아옴

우선 팀장님 EC2 부터 다시 켜놓고 작업 시작

dump 과정

내 계정에 DB용 EC2 인스턴스 하나 생성해준다

그 다음 ubuntu 접속 후 mariadb 설치

$ sudo su
$ apt-get update
$ apt-get install mariadb-server mariadb-client

설치가 되면 mysql -u root -p 로 접속하는데 비번 설정이 안되어있음

아래 명령어로 비번 설정하기

$ sudo mysql
$ use mysql;
$ set password for 'root'@'localhost' = password('비밀번호'); // 비밀번호를 설정
$ FLUSH PRIVILEGES; // 변경사항 적용

설정해준 비번치고 재접속 후 새로 스키마 생성하기

ubuntu 서버에 fcc 폴더 생성

아래 명령어를 입력하여 dump 진행

$ mysqldump -h 원격지IP -u fcc(원격지계정) -p fcc(원격지대상DB) > fcc/dump.sql;
$ use fcc;
$ source dump.sql

성공적으로 dump 가 완료되었다 !

MariaDB 외부 접속 허용하기

$ sudo su -
$ vi /etc/mysql/mariadb.conf.d/50-server.cnf

// port 주석 해제 (없으면 기입)
// bind-address 127.0.0.1 -> 0.0.0.0 으로 변경 (필수)

$ systemctl restart mariadb // 재시작

// MariaDB 접속
$ sudo su -
$ mysql -u root -p

// 권한 확인
mysql> use mysql;
mysql> select host, user, paswor from user;

host 에 % 가 아닌 localhost 밖에 없어서 신규 유저 생성

// 유저 생성
mysql> create user 'YOUR_USER'@'%' identified by 'YOUR_PASSWORD';
// 유저 변경
mysql> update user set host='%' where host='YOUR_HOST' and user='YOUR_USER';

// 유저 권한 변경
mysql> grant privileges on YOUR_DATABSE.* to 'YOUR_USER'@'%' with grant option;

포트 3306 인바운드 규칙 추가

DB 접속 완료 !! 도와주신 하영님 감사합니다 :)

출처 : https://8ugust-dev.tistory.com/19

관계형 DB 설계에서 중복을 최소화하고 데이터 일관성을 유지하기 위해 데이터의 구조를 조직화하는 프로세스이다.

주로 테이블을 작은 단위로 분리하여 중복을 제거하고, 이상 현상(anomalies)을 방지하는 데 사용된다.

Normal forms

정규화 되기 위해 준수해야 하는 몇 가지 rule 들이 있는데, 이 각각의 rule 을 normal form(NF) 이라고 한다.

DB 정규화 과정

제1 정규형

원자값(Atomic Value, 하나의 값)을 갖도록 테이블을 분해하는 작업

장점 : 데이터의 중복을 최소화하고 데이터 일관성을 유지할 수 있음 단점 : 중첩된 데이터를 허용하지 않기 때문에 데이터 구조를 더 복잡하게 만들 수 있음

제2 정규형

현재 테이블의 주제와 관련없는 컬럼을 다른 테이블로 빼는 작업

Partial Dependency : 부분적 종속
Composite Primary Key : 복합키

장점 : 데이터의 수정 작업이 편리해짐 단점 : 테이블의 분리로 인해 일부 쿼리가 복잡해질 수 있음

제3 정규형

일반 컬럼에만 종속된 컬럼은 다른 테이블로 빼는 작업

장점 : 데이터 수정 시 발생할 수 있는 이상 현상을 방지함 단점 : 정규화된 데이터베이스는 조인을 많이 필요로 하므로 읽기 작업이 많은 시스템에서 성능 문제가 발생할 수 있음

관계형 DB 들은 정규화를 해두는게 일반적이지만 비관계형 DB 들은 정규화를 안하는 경우가 많다.

역정규화 (Denormalization)

역정규화는 성능을 향상시키기 위해 정규화된 DB 를 다시 중복을 포함하는 형태로 변경하는 프로세스이다.

테이블을 너무 많이 잘게 쪼개면 여러 테이블들이 모두 동시에 조인을 하게 되기 때문에 성능이 느려지는 이슈가 발생할 수 있고, 관리하기 어려워질 수 있다.

• 일반적으로 쿼리의 성능을 향상시키기 위해 사용되며, 특히 읽기 작업이 많은 시스템에서 유용하다.

• 데이터의 일부를 중복 저장하거나 중복 인덱스를 생성함으로써 데이터에 대한 읽기 액세스를 최적화한다.

• 하지만 데이터 일관성을 유지하기 위해 조심스럽게 사용되어야 한다.

정리

정규화는 데이터 일관성과 구조를 유지하고 중복을 최소화하기 위해 데이터를 정리하는 반면, 역정규화는 읽기 성능을 향상시키기 위해 중복을 허용하는 방향으로 데이터를 재구성하는 것이다.

DB 를 설계할 때 과도한 조인과 중복 데이터 최소화 사이에서 적정 수준을 선택할 필요가 있다.

출처

데이터 정규화가 뭔지 설명해보세요 (개발면접타임) https://youtu.be/Y1FbowQRcmI?si=qohrNhajyETA2evF

(1부) DB 정규화(normalization)는 DB를 설계하는 공식적인 방법이죠~ 1부에서는 정규화 개념과 정규화 과정의 앞 부분인 1NF, 2NF를 설명합니다 :) https://youtu.be/EdkjkifH-m8?si=aEX_ni05tFE1jQPj

(2부) DB 정규화(normalization) 2부입니다!! 3NF, BCNF와 2NF 참고 사항, 역정규화(denormalization)까지 설명합니다!! https://youtu.be/5QhkZkrqFL4?si=aUKZ81mNL7mLalSJ

쉬운 예시로, 책 뒷 편에 ‘색인’이 바로 이 인덱스의 역할이라고 보면 된다. 색인을 통해 원하는 키워드에 대한 페이지로 바로 이동할 수 있다.

책의 색인이 여러 페이지에 기재되어 있는 것처럼 DB의 인덱스가 잘 설정되었을 경우, 데이터베이스 메모리에 일정 공간을 사용해 저장이 되고, 데이터를 조회할 때 소모되는 메모리를 효율적으로 사용하게 한다.

인덱스의 특징

인덱스는 WHERE 절에서 효과가 있다

인덱스는 SELECT - FROM - WHERE 절 중 WHERE 절에 사용할 컬럼에 대한 효율화라고 볼 수 있다.

WHERE 절을 사용하지 않고 인덱스가 걸린 컬럼을 조회하는 것은 성능에 아무런 영향이 없다.

예를 들어, ‘학생’ 테이블에 ‘학번’, ‘이름’, ‘전화번호’가 있다고 가정해보자. 인덱스는 ‘학번’, ‘전화번호’에 걸려 있다.

다음 중 인덱스가 영향을 주는 쿼리는 어떤 것일까?

1번) SELECT '학번' FROM '학생';
2번) SELECT '전화번호' FROM '학생' WHERE '이름' = "김철수";
3번) SELECT * FROM '학생' WHERE '학번' = 1;

정답은 3번) WHERE 절에 사용할 때 성능을 향상시킨다.

무조건 많이 설정하면 좋은걸까?

인덱스는 하나 혹은 여러 개의 컬럼에 대해 설정할 수 있다. 단일 인덱스를 여러 개 생성할 수도, 여러 컬럼을 묶어 복합 인덱스를 설정할 수도 있다.

그러나 무조건 많이 설정하는게 검색 속도 향상을 높여주지는 않는다. 인덱스는 데이터베이스 메모리를 사용하여 테이블 형태로 저장되므로 개수와 저장 공간은 비례한다.

따라서, 조회시 자주 사용하고 고유한 값 위주로 인덱스를 설정하는게 좋다.

DML(Data Manipulation Language) 각각에는 어떤 영향을 미칠까?

SELECT 쿼리에서 성능이 잘 나오지만, INSERT, UPDATE, DELETE 쿼리에서는 때에 따라 다르다.

UPDATE, DELETE 는 WHERE 절에 잘 설정된 인덱스로 조건을 붙여주면 조회할 때 성능은 크게 저하되지 않으나 (업데이트 할 데이터를 찾을 때의 속도가 빨라지는 것이지, 업데이트 자체가 빨라지는 것은 아님!)

INSERT 의 경우, 새로운 데이터가 추가되면서 → 기존에 인덱스 페이지에 저장되어 있던 탐색 위치가 수정되어야 하므로 효율이 좋지 않다.

즉, 인덱스는 원하는 데이터를 빠르게 찾을 때 빛을 발한다.

그럼 어떤 컬럼에 인덱스를 설정하는게 좋을까?

인덱스는 한 테이블당 보통 3~5개 정도가 적당하다. 물론 테이블의 목적 등에 따라 개수는 달라질 수 있다.

인덱스는 컬럼을 정해서 설정하는 것이므로 후보 컬럼의 특징을 잘 파악해야 한다. 아래 4가지 기준을 사용하면 효율적으로 인덱스를 설정할 수 있다.

카디널리티 (Cardinality)

✔️ 카디널리티가 높을 수록 인덱스 설정에 좋은 컬럼이다. = 한 컬럼이 갖고 있는 값의 중복 정도가 낮을 수록 좋다.

컬럼에 사용되는 값의 다양성 정도, 즉 중복 수치를 나타내는 지표이다. 후보 컬럼에 따라 상대적으로 중복 정도가 낮다, 혹은 높다로 표현된다.

예를 들어, 10개 rows를 가지는 ‘학생’ 테이블에 ‘학번’과 ‘이름’ 컬럼이 있다고 해보자.

• ‘학번’은 학생마다 부여 받으므로 10개 값 모두 고유하다.
  • 중복 정도가 낮으므로 카디널리티가 높다.
• ‘이름’은 동명이인이 있을 수 있으니 1~10개 사이의 값을 가진다.
  • 중복 정도가 ‘학번’에 비해 높으므로 카디널리티가 낮다고 표현할 수 있다.

선택도 (Selectivity)

✔️ 선택도가 낮을 수록 인덱스 설정에 좋은 컬럼이다. 5~10% 정도가 적당하다.

데이터에서 특정 값을 얼마나 잘 선택할 수 있는지에 대한 지표이다. 선택도는 아래와 같이 계산한다.

= 컬럼의 특정 값의 row 수 / 테이블의 총 row 수 * 100
= 컬럼의 값들의 평균 row 수 / 테이블의 총 row 수 * 100

예를 들어, 10개 rows를 가지는 ‘학생’ 테이블에 ‘학번’, ‘이름’, ‘성별’ 컬럼이 있다고 해보자. 학번은 고유하고, 이름은 2명씩 같고, 성별은 남녀 5:5 비율이다.

• ‘학번’의 선택도 = 1/10 * 100 = 10%
  • SELECT COUNT(1) FROM '학생' WHERE '학번' = 1; (모두 고유하므로 특정 값 : 1)
• ‘이름’의 선택도 = 2/10 * 100 = 20%
  • SELECT COUNT(1) FROM '학생' WHERE '이름' = "김철수"; (2명씩 같으므로 특정 값 : 2)
• ‘성별’의 선택도 = 5/10 * 100 = 50%
  • SELECT COUNT(1) FROM '학생' WHERE '성별' = F; (5명씩 같으므로 특정 값 : 5)

즉, 선택도는 특정 필드값을 지정했을 때 선택되는 레코드 수를 테이블 전체 레코드 수로 나눈 것이다.

활용도

✔️ 활용도가 높을 수록 인덱스 설정에 좋은 컬럼이다.

해당 컬럼이 실제 작업에서 얼마나 활용되는지에 대한 값이다. 수동 쿼리 조회, 로직과 서비스에서 쿼리를 날릴 때 WHERE 절에 자주 활용되는지를 판단하면 된다.

중복도

✔️ 중복도가 낮을 수록 인덱스 설정에 좋은 컬럼이다.

중복도는 인덱스로 선택된 값이 얼마나 고유한지를 나타낸다.

중복도가 낮을수록 인덱스의 효과가 높아진다. 즉, 인덱스로 선택된 값이 서로 다른 레코드에서 자주 발생하는 경우에는 인덱스가 더 유용합니다.

예를 들어, 성별 열은 중복도가 높지만 주민등록번호와 같은 고유한 값은 중복도가 매우 낮다.

정리

인덱스는 WHERE 절에서 사용할 때 성능을 향상시킨다.

조회 시 자주 사용하고 고유한 값 위주로 인덱스를 설정하는게 좋다.

• 카디널리티 : 높을 수록 적합
• 선택도 : 낮을 수록 적합 (5~10% 적정)
• 활용도 : 높을 수록 적합
• 중복도 : 낮을 수록 적합

이러한 요소들을 고려하여 인덱스를 설계하면 데이터베이스의 성능을 최적화할 수 있다.

출처

https://yurimkoo.github.io/db/2020/03/14/db-index.html

해시 테이블은 데이터 요소의 주소/인덱스 값이 해시 함수에서 생성되는 데이터 구조 유형이다. 인덱스 값이 데이터 값에 대한 키로 동작하므로 매우 빠른 데이터 액세스가 가능하다.

해시 테이블은 키-값 쌍을 저장하지만 키는 해싱 함수를 통해 생성된다. 따라서 키 값 자체가 데이터를 저장하는 배열의 인덱스가 되기 때문에 데이터 요소의 검색 및 삽입 기능이 훨씬 빨라진다. 조회하는 동안 키가 해시되고 결과 해시는 해당 값이 저장된 위치를 나타낸다.

해싱의 개념은 버킷 배열에 항목(키/값 쌍)을 배포하는 것이다. 키가 주어지면 알고리즘은 항목을 찾을 수 있는 위치를 제안하는 인덱스를 계산한다.

B-tree index

최대 2개의 자식 노드만을 가지는 이진탐색트리(BST)를 일반화하여 2개 이상의 자식 노드를 가질 수 있도록 확장한 균형 트리이다.

자녀 노드의 최대 개수를 원하는대로 결정해서 사용할 수 있다.

최대 m 개의 자녀를 가질 수 있는 B-tree를 m 차 B-tree 라고 한다.

m : 각 노드의 최대 자녀 노드 수
m - 1 : 각 노드의 최대 key 수
m / 2 (올림) : 각 노드의 최소 자녀 노드 수
m / 2 (올림) - 1 : 각 노드의 최소 key 수

속성

• 모든 리프 노드는 동일한 수준에 있어야 한다.

• 루트를 제외한 모든 노드에는 최소 [m/2]-1개의 키와 최대 m-1개의 키가 있어야 한다.

• 루트를 제외한 모든 비 리프 노드(즉, 모든 내부 노드)에는 최소 m/2개의 자식이 있어야 한다.

• 루트 노드가 리프 노드가 아닌 경우 최소 2개의 자식이 있어야 한다.

• n-1 개의 키가 있는 비 리프 노드에는 n개의 자식이 있어야 한다.

• 노드의 모든 키 값은 오름차순 이어야 한다.

차이점

1. 검색 방법

• Hash 인덱스 : 해시 함수를 사용하여 키를 해싱하고, 해시 테이블에 저장한다. 해시 테이블은 해시 값과 해당하는 데이터 레코드의 포인터를 저장한다. 따라서 검색 시 해시 값을 계산하여 해당하는 위치로 바로 이동하여 데이터를 찾는다. 이는 일반적으로 O(1)의 시간 복잡도를 가진다.

• B-Tree 인덱스 : B-Tree 는 이진 트리의 확장된 형태로, 노드당 여러 키를 가질 수 있다. 이진 탐색 트리와는 달리 균형을 유지하며, 각 노드의 자식은 키 값에 대한 범위를 가진다. 따라서 검색 시 루트부터 시작하여 트리를 탐색하며 원하는 키를 찾는다. 이는 일반적으로 O(log n)의 시간 복잡도를 가진다.

2. 범위 검색

• Hash 인덱스 : 해시 함수를 사용하기 때문에 키의 범위 검색이 어렵다. 범위 검색을 하려면 모든 해시 값에 대해 순차적으로 탐색해야 한다.

• B-Tree 인덱스 : B-Tree는 범위 검색에 효과적이다. 각 노드가 키 값에 대한 범위를 가지기 때문에 범위 검색 시에도 효율적으로 데이터를 찾을 수 있다.

3. 데이터 정렬

• Hash 인덱스 : 해시 함수를 사용하기 때문에 데이터가 해시 값에 따라 무작위로 배치된다.

• B-Tree 인덱스 : B-Tree는 키 값에 따라 정렬된 상태로 데이터가 저장된다.

4. 인덱스 크기

• Hash 인덱스 : 일반적으로 B-Tree 인덱스보다 작은 크기를 가진다. 하지만 해시 충돌이 발생할 경우 공간 효율성이 저하될 수 있다.

• B-Tree 인덱스 : Hash 인덱스보다 큰 크기를 가질 수 있다.

5. 적용 가능성

• Hash 인덱스 : 등 값이 정확히 일치해야 하는 경우에 유용하다. 예를 들어 고유한 식별자를 가진 테이블에 매우 적합하다.

• B-Tree 인덱스 : 범위 검색이나 정렬된 데이터에 대한 검색이 필요한 경우에 유용하다. 대다수의 상황에서 일반적으로 사용된다.

정리

Hash table 은 O(1)으로 탐색시간이 빠르지만 이는 단 하나의 데이터를 탐색하기 때문이다. 또한 저장되는 값들은 정렬되어 있지 않기 때문에 특정 값보다 크거나 작은 값을 찾을 수 없다. 그리고 해시 충돌이 발생할 경우, 성능 저하의 문제와 탐색에 걸리는 시간이 증가 할 수 있다.

반면에 B-Tree를 사용할 경우 평균적으로 O(logN)이라는 빠른 성능으로 탐색, 삽입, 수정, 삭제할 수 있으며, 정렬이 되어 있기 때문에 >,< 과 같은 범위탐색에 효율적으로 접근할 수 있다. 또한 노드마다 배열로 구현되어 있기 때문에 참조포인터를 RB-Tree 에 비해 조금 사용하여 방대한 데이터 접근에 더 적합하다.

따라서 DataBase 의 여러 고려사항을 따졌을 때 B-Tree 가 가장 적합한 자료구조로 채택이 된다.

출처

https://applepick.tistory.com/155

자바에서 Deque(Double Ended Queue) 는 Queue 인터페이스를 상속받은 인터페이스이며, Queue 와 Stack 의 메서드를 모두 제공한다.

자료의 입출력을 양 끝에서 할 수 있다. 인덱스로 요소에 액세스, 삽입, 제거를 허용하지 않는다.

삽입

삭제

조회

public class Application {
    public static void main(String[] args) {
        Deque<String> deque = new ArrayDeque<>();
        deque.addFirst("첫 번째 요소"); // "첫 번째 요소"
        deque.add("두 번째 요소"); // "첫 번째 요소", "두 번째 요소"
        deque.push("세 번째 요소"); // "세 번째 요소", "첫 번째 요소", "두 번째 요소"
        System.out.println(deque.pop());
        System.out.println(deque.pop());
    }
}
// [출력 결과]
// 세 번째 요소
// 첫 번째 요소

종류

Deque<Integer> queue = new ArrayDeque<>();
Deque<Integer> queue2 = new LinkedList<>();

일반적으로 Deque의 구현체는 ArrayDeque 와 LinkedList 가 있다.

ArrayDeque

• Deque 인터페이스의 구현체이며 크기를 재설정 할 수 있다.

• null 요소 추가 불가

• 양쪽 끝에서 추가, 제거하는 것이 효율적이다

• 메모리 소모량이 적을 때는 iterate 효율이 좋은 ArrayDeque 를 사용하는 것이 좋다

LinkedList

• List 의 구현체다.

• null 요소를 추가할 수 있다

• 반복중에 현재 요소를 제거하는 것이 효율적이다

• ArrayDeque 보다 많은 메모리를 소모한다

• 스택의 사이즈가 커지거나 심한 변동이 예상될 때는 즉각적인 메모리 공간 확보를 위해 LinkedList 를 사용한다.

대부분의 상황에서는 Deque 를 사용할 때 ArrayDeque 를 사용한다.

그럼 Deque 만 써도 되는거 아님?

1. 문제 상황에 따른 선택

스택과 큐가 각자 잘 맞는 상황이 있습니다. 예를 들어, 괄호 짝 맞추기 문제는 스택을, 프린터 큐 문제는 큐를 사용하는 것이 더 자연스럽습니다. 덱을 사용하면 구현이 복잡해질 수 있습니다.

2. 가독성과 유지 보수

스택과 큐는 각각의 역할이 명확하므로, 코드의 가독성을 높이고 유지 보수를 용이하게 합니다. 덱을 사용하면 코드가 복잡해지고 오류 발생 가능성이 높아질 수 있습니다.

3. 효율성

스택과 큐는 각각의 목적에 맞게 최적화된 연산을 제공합니다. 반면에 덱은 양쪽 끝에서의 연산을 모두 지원하므로, 특정 상황에서는 스택이나 큐보다 덜 효율적일 수 있습니다.

출처 : GPT-4 답변

정리

Deque(덱 또는 데크) 란 쉽게 말해 양방향 큐이다. Stack 과 Queue 대신 Deque 를 사용할 수 있다.

LinkedList 나 ArrayDeque 로 사용될 수 있으며, ArrayDeque 로 사용 시 Stack 으로 사용하면 Stack 보다 빠르고, Queue 로 사용하면 LinkedList 보다 빠를 수 있다.

출처

https://soft.plusblog.co.kr/24 https://ttl-blog.tistory.com/170 https://velog.io/@may_yun/JAVA-Stack-대체-Collection-Deque

변수에 저장되기 전의 값을 리터럴이라고 한다.

int score = 100;        // 변수 : score
final int MAX = 100;    // 상수 : MAX

선언 방법

자바에는 String 을 선언하는 방법이 리터럴과 객체로 선언할 수 있다.

//리터럴
String a = "hello";
String b = "hello";

//객체
String c = new String("hello");
String d = new String("hello");

System.out.println(a.equals(b));     // true
System.out.println(a == b);          // true

System.out.println(c.equals(d));     // true
System.out.println(c == d);         // false

System.out.println(a.equals(c));     // true
System.out.println(a == c);            // false

리터럴 선언 방식은 Heap 영역 안에 있는 String Constant Pool(상수풀) 에 위치한다. String Constant Pool 에 이미 존재하는 문자열이라면 같은 주소값을 공유한다.

따라서 변수 a, b 는 비교하였을 때, 문자열과 주소값이 모두 같은 것을 확인할 수 있다.

String Constant Pool 이란

자바 메모리 중 Heap 영역 안에 위치하여 String 을 별도로 관리하는 장소다.
Heap 안에 있기 때문에 모든 스레드가 공유할 수 있고 가비지 콜렉터의 대상이 된다.

객체 선언 방식은 Heap 영역에 할당된다. 새로운 인스턴스를 생성할 때마다 Heap 영역에 객체가 새로 생긴다.

따라서 변수 c, d 를 비교하였을 때 문자열은 같지만 Heap 영역에서 서로 다른 객체로 생성되었기 때문에 주소값은 다르다.

문자열 리터럴은 String Constant Pool 영역에, 객체는 Heap 영역안에 위치하므로 변수 a, c 는 서로 다른 주소값을 참조한다.

System.out.println(a == c.intern());     //true

intern() 메서드는 String Constant pool 에서 리터럴 문자열이 있으면 반환하고, 없다면 새로 문자열을 넣어주고 그 주소값을 반환한다.

new 연산자로 생성한 변수 c 에 intern() 메서드를 적용하면 리터럴 변수인 a 와 참조하는 주소값이 같아진다.

1. intern() 메소드 실행
2. String Constant Pool 에 문자열 존재하는지 확인
3. 동일한 주소값 리턴

정리

리터럴

• 상수풀이라는 특별한 메모리 영역에 저장된다.

• 서로 같은 문자열 리터럴을 사용하는 경우, 동일한 객체로 인식된다.

• == 연산자를 사용하여 동등성을 비교할 수 있다.

• 자바는 상수풀에서 중복된 문자열을 관리하므로 같은 문자열 리터럴을 사용하면 같은 객체를 참조하게 된다.

객체

• new 연산자로 문자열을 생성하면 새로운 객체가 heap 메모리에 할당된다.

• 동일한 문자열이라도 별도의 객체로 취급된다.

• 불필요한 메모리 사용이 발생할 수 있다.

• == 로 동등성을 비교하면 객체의 참조값을 비교하게 되므로 equals() 를 사용하여 내용을 비교해야 한다.

일반적으로 문자열을 다룰 때는 리터럴 방식을 사용하는 것이 권장되며, 이는 코드의 가독성을 높이고 불필요한 메모리 사용을 최소화할 수 있다.

출처

https://velog.io/@kiiiyeon/자바-스트링-객체-생성-방법

객체 hashcode 란 객체를 식별하는 하나의 고유 정수값을 말한다.

쉽게 말해서 객체의 지문이다.

• 객체의 해시코드(hash code)를 반환하는 메소드

• Object 클래스의 메소드로써, 모든 클래스는 Object 클래스를 상속하기 때문에 사실상 모든 객체에서 가지고 있는 메소드

• hashCode() 는 객체의 주소를 int 로 변환해서 반환한다.

import java.util.Objects;

public class Main {
    public static void main(String[] args) {
        Person person1 = new Person("kimsana");
        Person person2 = new Person(new String("kimsana"));
        Person person3 = person2;
        Person person4 = new Person("kimsana");

        System.out.println(person1.hashCode()); // 798154996
        System.out.println(person2.hashCode()); // 681842940
        System.out.println(person3.hashCode()); // 681842940
        System.out.println(person4.hashCode()); // 1392838282
        System.out.println(person1.equals(person4)); // false

        // 재정의 하면 전부 106222
        // equals 도 재정의 해줘야함
    }
}

// @EqualsAndHashCode 이거 쓰면 원콤
class Person {
    String name;

    public Person(String name) {
        this.name = name;
    }

    @Override
    public int hashCode() {
        return Objects.hashCode(name); // name 에서 해시 코드 생성
    }
}

• equals() 를 오버라이딩하면, hashCode() 도 오버라이딩해야 한다. equals() 의 결과가 true 인 두 객체의 해시코드는 같다.

String str1 = new String("abc");
String str2 = new String("abc");
System.out.println(str1.equals(str2));    // true
System.out.println(str1.hashCode());    // 96354
System.out.println(str2.hashCode());    // 96354

• String class 는 equals() 메소드를 재정의해서 주소값 비교가 아닌 문자열 '값'만을 비교한다. (참고로 반대로 '주소값'을 비교하는 건 '==' 연산자를 많이 쓴다.)

equals()와 hashCode()를 함께 재정의해야 하는 이유

1. equals() 메서드가 두 객체를 동등하다고 판단한다면, 두 객체의 hashCode() 값은 반드시 같아야 한다. 따라서 equals() 가 true를 반환하는 두 객체는 항상 같은 해시 코드를 가져야 한다.

2. hashCode() 값이 같다고 해서 두 객체가 반드시 동등하다고 판단하는 것은 아니다. 하지만 해시 코드가 다른 두 객체는 반드시 서로 다르다고 판단해야 한다. 이는 해시 기반 컬렉션(HashMap, HashSet)에서 객체를 효율적으로 검색하기 위해 필요한 규칙이다.

3. hashCode() 메서드를 재정의하여 객체의 내용을 기반으로 한 해시 코드를 생성하면, 동일한 내용의 객체는 동일한 해시 코드를 갖게 된다. 이로 인해 해시 기반 컬렉션에서 효율적인 검색 및 삽입이 가능해진다.

정리

• equals() 로 같은 객체는 같은 hashCode() 결과가 나와야 한다.

• hashCode() 로 같은 객체가 항상 equals() 메서드로 같은 객체는 아니다.

• 이 두 메서드를 함께 재정의하지 않으면 해시 기반 컬렉션을 올바르게 사용할 수 없고, 예상치 못한 동작이 발생할 수 있다. (해시 충돌, 동등성 비교 오류 등)

출처

https://velog.io/@mooh2jj/equals와-hashCode는-언제-사용하는가

인터페이스(interface)는 자바에서 다중 상속을 지원하지 않는 문제를 해결하고, 코드의 유연성을 높이기 위해 사용된다.

여러 클래스가 공통된 메서드를 구현하도록 강제함으로써 코드의 일관성을 유지하고, 다형성을 통해 다양한 객체를 통일적으로 다룰 수 있도록 한다.

두 객체간의 '연결, 대화, 소통'을 돕는 '중간 역할'을 한다. 선언(설계)과 구현을 분리시킬 수 있게 한다.

사용 시점

1. 다형성 구현

인터페이스는 하나의 객체가 아니라 여러 객체들과 사용이 가능하므로 어떤 객체를 사용하느냐에 따라서 실행 내용과 리턴 값이 다를 수 있다.

다형성이란

• 자바의 상속 구조는 단일 상속의 원칙을 갖기 때문에 하나의 클래스가 여러 부모 클래스를 상속할 수 없다.

• 서로 다른 부모 클래스를 가지는 클래스간에도 같은 인터페이스를 구현할 수 있다.

• 같은 인터페이스를 구현하고 있는 클래스간에는 그 인터페이스로 하여금 대표성을 갖게 할 수 있다.

public class InterfaceAssist {
    public static void main(String[] args) {
        play(new Soccer());
        play(new BassGuitar());
    }

    public static void play(IBehavior ib) {
        ib.play();
    }
}

public interface IBehavior {
    void play(); // public abstract 생략
}

public class Soccer extends Sport implements IBehavior {
    @Override
    public void play() {
        System.out.println("Playing Soccer");
    }
}

public class BassGuitar extends Guitar implements IBehavior {
    @Override
    public void play() {
        System.out.println("Playing BassGuitar");
    }
}

2. 약한 결합

약한 결합은 소프트웨어의 요소 간의 의존성을 최소화하고 유연성을 높이는 개념이다. 여러 클래스가 서로 독립적으로 존재하면서도 상호 작용할 수 있는 구조를 지원한다.

• 하나의 프로그램의 다수의 클래스들이 서로 관계를 형성하게 되고 각 클래스들은 역할에 따라 구분한다.

• 클래스들간에 관계를 밀접하게 구성하게 되면 특정 클래스에서 변경이 일어날 경우 많은 클래스들이 영향을 받는다. (Tight Coupling)

• 따라서, 클래스 간에 관계를 구성할 때 그 관계를 느슨하게 관리하는 것이 중요하다. (Loose Coupling)

• 클래스와 클래스 사이에 인터페이스를 구성하면 직접적인 접근이 없는 느슨한 관계를 구성할 수 있다.

public class Person {
    private Chicken chicken;

    public Person() {
        this.chicken = new Chicken();
    }

    public void startEat() {
        chicken.eat();
    }
}

public class Chicken {
    public void eat() {
        System.out.println("치킨을 먹습니다.");
    }
}

강한 결합은 어떠한 객체가 다른 객체에 강한 의존성을 가지고 있음을 뜻한다.

public interface Food {
    void eat();
}

public class Chicken implements Food {
    @Override
    public void eat() {
        System.out.println("치킨을 먹습니다.");
    }
}

public class Pizza implements Food {
    @Override
    public void eat() {
        System.out.println("피자를 먹습니다.");
    }
}

public class Person {
    private Food food;

    public Person(Food food) {
        this.food = food;
    }

    public void startEat() {
        food.eat();
    }
}

3. 다중 상속이 필요할 때

다중 상속은 한 클래스가 여러 개의 클래스로부터 상속받는 것을 말한다. 자바에서는 클래스에서의 다중 상속이 허용되지 않지만, 인터페이스를 통한 다중 상속은 가능하다.

• 여러 인터페이스를 구현함으로써 한 클래스가 다양한 기능을 동시에 제공할 수 있다.

• 각 인터페이스는 독립적으로 분리된 역할을 수행한다. 이는 코드를 더욱 모듈화하고 유지보수하기 쉽게 만들어준다.

• 여러 인터페이스의 기능을 재사용하여 새로운 클래스를 작성할 수 있다. 이는 코드의 중복을 피하고 유지보수성을 향상시킨다.

  interface Swimmable {
    void swim();
  }
  

interface Flyable { void fly(); }

class FlyingFish implements Swimmable, Flyable { public void swim() { // 구현 내용 }

public void fly() {
    // 구현 내용
}

}

```

인터페이스의 장점

• 두 대상 사이의 '중간' 역할을 해준다. -> 직접 거치지 않고 중간 단계를 거친다. (중개인)

• 선언과 구현을 분리시킬 수 있다. -> 변경사항이 있어도 수정 범위가 적다.

• 개발 시간을 단축할 수 있다. -> 개발시 협업 시스템에서 미완성, 추상메서드(내용없는) 를 통해 = 완성되었다고 가정하고 동시에 개발 가능

• 변경에 유리한 유연한 설계가 가능하다. -> (선물 상자에 내용물이 바뀌어도 상관없는 것처럼)

• 클래스들의 관계를 맺어줄 수 있다. (다형성/추상화)

출처

https://velog.io/@damiano1027/Java-강한-결합과-약한-결합

자바 기초 강의 - 3-14강 인터페이스의 활용 https://youtu.be/enD9V74_kRs?si=Mh-L7nUE2IHpQVQo

[자바의 정석 - 기초편] ch7-38인터페이스와 다형성 https://youtu.be/EnBLkMYt1XQ?si=y4VWBb5yTW4KMsjn

자바 언어에서 final은 오직 한 번만 할당할 수 있는 entity 를 정의할 때 사용된다.

final 로 선언된 변수가 할당되면 항상 같은 값을 가진다. 만약 final 변수가 객체를 참조하고 있다면, 그 객체의 상태가 바뀌어도 final 변수는 매번 동일한 내용을 참조한다.

final 키워드는 클래스, 필드, 메소드, 지역변수, 파라미터에 적용할 수 있다.

• 클래스에 final 은 상속을 허용하지 않는다.

• 메소드의 final 은 오버라이딩을 허용하지 않는다.

• 필드, 지역변수, 파라미터에 final을 적용하면 한번 초기화 한 이후에는 다른 값으로 변경할 수 없다.

Final 변수

final 필드의 초기화 방식은 필드 선언 시점의 초기화, 초기화 블록, 생성자를 통한 초기화 방법 3가지가 있다.

public class FinalExam {
    private final String message = "Final Message"; // (1)

    private final String message;
    {
        message = "Final Message"; // (2)
    }

    public FinalExam(String message) {
        this.message = message; // (3)
    }

    public final void showMessage() {
        System.out.println(message);
    }

    // final 로 선언된 인자값
    public void showMessage(final String message) {
        // message = "New Message!";
        // Cannot assign a value to final variable 'message'
        System.out.println(message);
    }
}

final 메소드

메소드를 final 로 선언하면 상속받은 클래스에서 오버라이딩이 불가능하다. Dog 객체는 Pet 의 makeSound() 메소드를 재정의할 수 없다.

public class Pet {
    public final void makeSound() {
        System.out.println("ahaha");
    }
}

public class Dog extends Pet {
    // final로 된 메소드는 override 할 수 없음
     public void makeSound() { 

     }
}

final 클래스

클래스에 final 을 선언하면 상속 자체가 불가능하다. 그냥 클래스 그대로 사용해야 한다.

public final class FinalClass {
    ...
}

// final 클래스로 선언되어 상속할 수 없음
public class OtherClass extends FinalClass {
    ...
}

자바에서 기본적으로 제공하는 라이브러리 클래스는 final 을 사용함
java.lang.System, java.lang.String ...

정리

final 은 최종이라는 의미. 변수, 메소드, 클래스 각각 어디에 붙냐에 따라 다르지만 개념은 같다.

불변성, 상수값 유지, 상속과 오버라이딩의 방지 등 이러한 특성들은 소프트웨어 개발에서 버그를 줄이고 코드를 유지보수하기 쉽게 만들어준다.

따라서 final 키워드는 코드의 안정성과 예측 가능성을 높이기 위한 강력한 도구로 사용된다.