JinCheol (20231105): SQL 레벨업 1-2장

Document/2023/0903/jincheol/[1주차]_Jincheol_데이터베이스 첫걸음(1-4장).md

@@ -0,0 +1,235 @@
+# 1장 데이터베이스란 - 용도와 역할
+
+## 데이터베이스 기본기능
+
+### 데이터베이스 기본기능
+
+#### 1. 데이터의 검색과 갱신
+
+- 데이터베이스의 용도로써 가장 중요한 기능은 "검색" 이다.
+- 다시 말해 '원하는 데이터를 찾는다'는 것. (추출이라고도 함) EX) Google의 검색엔진.
+- 검색엔진은 방대한 데이터를 보존하는 DB에서 검색대상을 키워드로 히트한 데이터를 꺼내감.
+- 검색을 수행할 수단이 있다는 점이 DB에서 요구되는 가장 중요한 기능.
+
+<b> 넓은 의미에서 갱신은 등록/수정/제거 </b>
+
+- 등록,수정,제거 3가지 기능을 통틀어 '갱신'이라 일컫음.
+- 이렇게 넓은의미도 있지만, 좁은의미로서 '기존 데이터 수정'도 존재.
+- 데이터베이스에서 사용자가 수행하는 조작 : 검색과 갱신
+- 갱신 -> 등록,수정,제거의 하위단위로 재구성
+
+<b> 데이터 포맷에 유의한다 </b>
+
+- 데이터베이스를 조작할 떄 중요한 것은 데이터를 어떤 포맷(형식)으로 관리하는가, 검색이나 갱신에서 효율적인가 등의 문제 존재
+- 가령, 동성동명의 박XX 씨가 2명 존재하면 해당 2명은 다른 인물이기에 DB에서도 이 2명을 '다른 사람' 이라는 것을 알도록 관리해야함. (이러한 원칙을 고유성이라고함.)
+
+<b> 처리 성능에 유의한다 </b>
+
+- '어느 정도의 빠르기로 처리 가능한가'
+- 검색 성능을 어떻게 향상할 것인가 하는 주제는 영원한 숙제
+
+#### 2. 동시성 제어
+
+- 비지니스나 공공목적으로 이용하는 데이터베이스에는 불특정다수의 사용자가 동시에 접근하는 것이 보통.
+- 즉, 데이터베이스는 동시에 복수의 사용자로부터 검색/갱신 처리를 받음.
+- 이때 문제 되는 것이 '갱신의 무결성을 어느정도로 보장하는가?'
+
+<b> 동시성 제어 발생 가능 상황 </b>
+
+1. A : 파일보고 있음.. B : 파일 열 수 없음. (최초로 연 사람만이 읽을 수 있음)
+2. A : 파일보고 있음.. B : 오직 Read-Only만 가능
+3. A : 파일보고 있음.. B : 역시 파일 볼 수 있음 (데이터 반영은 "마지막"으로 수행된 동작 기준 적용)
+
+- B 입장에서는 '1'이 가장 행위 제한이 심하고 '3'이 가장 느슨.
+- 따라서 B 입장에서는 '3'이 가장 바람직한 상황
+
+- 그러나 A 입장에서는 '3'은 위험하고 의도하지 않은 상황.
+- 따라서, A의 바람직한 상황은 누구에게도 갱신을 방해받지 않는 '1'의 상황.
+
+- 데이터베이스를 복수의 사용자가 동시에 공유하고 이용하려면 '같은 데이터'를 갱신하는 상황에 대한 '제어'가 필요.
+- 어느 사용자는 OK , 다른 사용자는 NOT OK -> '트레이드오프 관계'
+- 이렇게 복수 사용자의 갱신을 조절하기 위한 기능을 데이터베이스의 중요한 두번째 기능인 '동시성 제어' 또는 '배타 제어'라고 함.
+
+#### 3. 장애 대응
+
+- 데이터베이스에 요구되는 세번째 중요 기능은 '장애애 강할 것'
+- 쉽게 말해 좀처럼 부서지기 어려우며 부서졌다 한들 복원 가능하다 라는 의미
+
+<b> 데이터 소실 문제 대책 </b>
+
+- 1. 데이터 다중화
+- 2. 백업
+
+#### 4. 보안
+
+- 데이터베이스에 보존된 데이터를 어떻게 숨길 것인가?
+- 사용자는 시스템 이용 시 데이터베이스의 존재를 의식할 일 거의 없음
+- 실제로 데이터베이스는 사용자로부터 가능한 보이지 않게 설계됨
+
+- 이유 1 : 사용자에게 가까운 기술이란 대다수가 클라이언트 기술 중심이라 서버의 기술은 그다지 의식되지 X
+- 여기서 클라이언트는 사용자가 직접 사용하는 단말기, 예를들면 PC, 태블릿, 스마트폰 등
+- 사용자로서 시스템 사용시 직접 조작하는 것은 어디까지나 클라이언트뿐이고 서버에 배치된 데이터베이스 등의 소프트웨어를 직접 조작하는 일은 없음
+
+- 이유 2 : 데이터베이스에 들어있는 데이터는 기밀성이 지극히 높아 일반에 공개할 수 없는 내용이 상당수 포함되어 있음.
+
+# 2장 관계형 데이터베이스란 - 가장 대표적인 데이터베이스
+
+## 관계형 데이터베이스란 무엇인가
+
+- 관계형 데이터베이스에서 말하는 '관계'란 단어는 보통 인간관계라든지 국제관계라고 할때 사용하는 관계란 단어와는 의미가 다름
+- 여기서 말하는 관계는 '2차원 표'를 표기할 때 사용하는 단어 EX) Excel, Google Docs 스프레드 시트
+- '데이터를 2차원 표를 사용해 관리하는 데이터베이스'
+
+## SQL 기초지식
+
+- SQL (Structured Query Language)
+- 4가지 기본 조작(검색,등록,갱신,제거)
+- SELECT, INSERT, UPDATE, DELETE
+
+### 테이블, 행, 열의 의미
+
+<b> 테이블 </b>
+
+- 2차원 표
+- 관계형 데이터베이스에서 데이터를 관리하기 위한 유일한 단위
+- 어떤 테이블에 어떤 데이터를 포함하는가는 시스템의 기능을 좌우하는 중요한 의미 내포
+- 테이블에 너무 많은 정보 -> 정보 정합성 유지 어려움
+- 데이터 너무 엄격하게 분산 -> 성능 저하
+
+### 관계형 데이터베이스를 다루기 위한 사전 지식
+
+<b> DBMS와 데이터베이스 차이 </b>
+
+- 데이터베이스라는 것은 기능이나 구조를 나타내는 '추상적인' 개념
+- DBMS는 그것을 실현하기 위해 작성된 구체적인 '소프트웨어'
+- 따라서 오라클,MySQL은 DBMS지 데이터베이스 X
+- 시스템 목적이나 규모에 따라 다르지만, 사용되는 소프트웨어은 크게 3가지로 나뉨 -> 1.운영체제 2.미들웨어 3.어플리케이션
+- DBMS는 '미들웨어'에 위치
+- 미들웨어(DB)는 OS에 설치하여 움직이는 걸 의미 (=OS에서 동작한다.)
+
+# 3장 데이터베이스에 얽힌 돈 이야기 - 초기비용과 운영 비용
+
+# P A S S
+
+# 4장 데이터베이스와 아키텍처 구성 - 견고하고 고속의 시스템을 구축하기 위해
+
+## 다중화에 대해 생각해보자
+
+- DB 2대 중 1대가 고장나도 다른 1대로 동작시켜 서비스 정지를 막을 수 있는데, 이것이 '다중화' 혹은 '고가용성'
+
+## 데이터베이스의 아키텍처
+
+<b> Stand-alone의 특징 </b>
+
+- 데이터베이스가 동작하는 머신이 LAN이나 인터넷 등의 네트워크에 접속하지 않고 '독립되어' 동작하는 구성
+- 이 구성에서는 데이터베이스의 미들웨어, 어플리케이션 소프트웨어가 같은 DB 서버에서 동작
+- 사용자는 직접 DB서버에 접근 필요.
+- 서버가 네트워크에 접속되지 않아서 물리적으로 떨어진 장소에서 접근도 불가능.
+- 나름의 장점은 구축이 간단해 소규모 작업이나 테스를 빠르게 할 수 있음
+- 성능이나 가용성 무시하면 노트북 사용해서도 만들 수 있음.
+- 보안이 높음. -> 직접 USB 메모리등을 사용하지 않는 이상 서버가 바이러스에 감염되거나 공격받는 일 X
+
+<b> 클라이언트/서버 특징 </b>
+
+- stand-alone 방식이 물리적으로 떨어진 곳에서는 접속할 수 없다는 것과 사용자가 동시 작업할 수 없는 두가지 단점을 극복할 방법으로서의 방안
+- 데이터베이스를 네트워크에 연결
+- 네트워크에 연결하면 복수 사용자가 물리적으로 떨어진 곳에서 데이터베이스 접근 가능해짐.
+- 데이터베이스 서버 1대에 복수 사용자의 단말이 접속하는 구성 -> 클라이언트/서버 구성
+- 단점은 인터넷에 직접 접속해 DB에 접속하므로 보안위험 + 불특정 다수의 사용자가 사용하는 클라이언트 어플리케이션 관리 비용
+- 불특정 다수의 사용자가 사용하는 클라이언트 어플리케이션 관리 비용이라는게..
+- 우리는 웹 페이지에 접속할 때 윈도우,맥,스마트폰 같은 클라이언트 환경 차이 의식 하지 않음
+- 하지만 클라이언트/서버는 개인이 이용하는 PC에 어플리케이션 설치해 동작하게 함 (Native App)
+- 하지만 인터넷을 통해 전 세계 불특정 다수의 사용자가 이용하는 어플리케이션은 '각종 환경'에 대응해 애플리케이션을 작성해야 하고 각각에 대한 버전 관리, 버그 수정 버전을 배포하는데 비현실적인 비용이 요구됨.
+
+<b> Web3 계층 </b>
+
+- 웹 서버 계층(Apache, Nginx), 어플리케이션 계층(Tomcat), 데이터베이스 계층(MySQL, MongoDB)
+- 클라이언트와 데이터베이스 계층 '사이에' 웹,어플리케이션 계층 추가된 형태
+- 웹서버는 HTTP 요청을 직접 받아서 그 처리를 뒷단의 어플리케이션 계층에 넘기고 해당 결과 클라에게 반환
+- 어플리케이션 계층은 비지니스 로직을 구현한 어플리케이션이 동작하는 층
+- 웹 서버로부터 연계된 요청처리, 필요 시 DB서버에 접속해서 데이터 추출 및 가공 결과 웹 서버로 반환.
+- 사용자로부터 직접적인 접속 요청을 받는 역할 : 웹 서버 계층
+- 비지니스 로직 구현 집중 : 어플리케이션 계층
+
+## DB 서버의 다중화 - 클러스터링
+
+<b> DB 서버의 다중화 </b>
+
+- 병렬화해서 대수를 증가시키는 웹 서버나 어플리케이션 서버와 비교하면 다중화에 대해 고민할 부분이 많음.
+- 이유는 DB 서버가 데이터를 보존하는 '영속 계층' 이기 때문.
+
+<b> DB와 다른 서버의 차이 </b>
+
+- 데이터베이스는 데이터를 장기간 보존하는 매체가 필요
+- 결국, DB서버의 아키텍처는 '저장소'와 묶어서 한 세트로 고민해야 함.
+
+<b> 가장 기본적인 다중화 </b>
+
+- DB 서버만을 다중화하고 저장소는 하나만 두는 구성
+- 이 경우 데이터가 보존되는 저장소가 1개라서 정합성 신경 X
+- Active - Active : 클러스터를 구성하는 컴포넌트를 동시에 가동.
+- Active - Stanby : 클러스터를 구성하는 컴포넌트 중 실제 가동하는 것은 Active, 남은 것이 대기(Standby).
+
+<b> Active - Active 구성의 장점 </b>
+
+- 1. 시스템 다운 시간이 짧음
+- 복수의 DB서버가 '동시'에 동작하고 있어 한 대가 다운되어 동작 불능이 되도 남은 서버가 처리 지속해 전체 정지 막음
+- 2. 성능 향상 가능
+- DB 서버가 증가하면 동시에 가동하는 CPU나 메모리도 증가하기 때문.
+- 단, 저장소가 병목(bottleNeck) 되기 때문에 생각한 만큼 성능 향상 꾀하지 못할 수 있음
+- Active - Standby 구성에서는 보통 스탠바이 상태 디비 서버는 사용되지 않다가 Active DB에서 장애가 발생할 때 사용.
+- 이때문에 전환 시차가 생기고 (보통 수십 초) 그 사이 시스템은 서비스 지속 불가능한 상태가 됨
+- Active - Stanby 구성에서 Stanby 서버가 Active서버가 고장났을 때 알 수 있는 이유는 일정 간격(보통 수 초 ~ 수십 초)으로 Active DB에 이상이 없는지를 조사하기 위한 통신 수행 ---> 'HeartBeat'
+
+<b> Active - Standby 구성 종류 </b>
+
+- 1. Cold-Standby : 평소에는 Standby DB가 동작하지 않다가 Active DB가 다운된 시점에 작동하는 구성.
+- 2. Hot-Standby : 평소에도 Standby DB가 작동하는 구성.
+- Hot 은 전환시간은 짧지만, 그만큼 비쌈 (Active - Acitve에 비하면 저렴)
+
+## DB서버와 데이터의 다중화 - 리플리케이션
+
+<b> 리플리케이션이란 </b>
+
+- DB서버와 저장소 세트를 '복수'로 준비하는 것.
+- DB서버 뿐만 아니라 데이터도 다중화 수행
+- Master / Slave 구조
+- Master 서버에 장애가 일어날 시 Slave로 요청을 보내서 페일오버(FailOver)가 가능해짐.
+- 따라서, 특정 장애가 발생해도 계속해서 서비스를 유지할 수 있는 특성인 HA(High Availability - 고가용성)가 보장된다.
+- Read / Write 수행 중 Read에 대한 요청이 많으면 Slave 서버에게 요청 분산해 부하 분산 가능
+- 매우 가용성이 높은 아키텍처
+- 재난 복구 계획으로 이용
+- '달걀을 한 바구니에 다 담지 않는' 전략
+
+<b> 리플리케이션이 주의점 </b>
+
+- 리플리케이션에서 중요한 점은 Active 측 저장소의 데이터는 항상 사용자로부터 갱신되므로 StandBy 측 데이터에도 갱신을 반영하여 최신화하지 않으면 Active 측과의 데이터 정합성 유지 불가능.
+- 쉽게 말해 StandBy 데이터가 점점 과거의 것이 됨.
+- 리플리케이션에서는 Active측 DB 서버에서 갱신된 데이터를 일정 주기로 StandBy 측 DB 서버에 써내려감.
+- StandBy 측의 갱신 주기를 얼마로 할 것인가와 성능 사이에 트레이드오프 관계 발생
+- StandBy 측 디비 서버에서도 기록이 성공한 것을 확인한 단게에서 Active 측의 갱신도 완료된 것으로 보는 형식이므로 데이터 보호의 관점에서는 바람직하지만 이 확인 처리를 어느 정도 생략하면 성능을 향상 시킬 수 있기 때문.
+
+## 성능을 추구하기 위한 다중화 - Shared Nothing
+
+<b> Shared Disk와 Shared Nothing </b>
+
+- 앞서 Active - Active 구성의 디비는 저장소 부분이 병목되는 경우가 있다고 언급
+- 복수의 서버가 1대의 디스크(저장소)를 공유하기 때문
+- 이렇게 복수의 서버가 1대의 디스크를 사요하는 구성을 'Shared Disk'
+- 액티브 - 액티브 구성은 디비 서버를 늘려도 무한으로 처리율이 향상되지 않고 어딘가에서 한계점에 도달.
+- 저장소가 공유 자원이라 쉽게 늘리기 어렵고 디비 서버 대수가 증가할수록 디비 서버간의 '정보공유'를 위한 오버헤드가 크기 때문
+- 이 단점 극복 대책안이 'Shared Nothing'
+- 보통 엄청나게 큰 테이블을 잘개 쪼개고 (horizontal Partitioning) 쪼개진 테이블을 '독립된' DB서버에 저장하는 방식.
+- 따라서 가령, 쪼개진 A테이블을 Jincheol DB 서버에 다른 쪼개진 B테이블은 Jincheol2 DB 서버에 저장해 요청마다 해당 요청이 부합되는 테이블을 가진 DB서버로 요청을 분산시킨다.
+- 그래서 데이터가 많이 쌓이는 테이블은 이런식으로 샤딩을 적용해 각각의 독립된 DB서버로 구축해 트래픽을 분산시켜 주는것이 좋다.
+- Shared Nothing은 문자 그대로 아무것도 공유 X
+- 네트워크 이외의 자원을 모두 분리하는 방식
+- 서버와 저장소의 세트를 늘리면 병렬처리 때문에 선형적으로 성능이 향상되는 장점 존재
+- Shared Nothing 방식은 비용 대비 성능이 좋음
+- DB 서버를 횡으로 나열하기 때문에 구조가 간단하며 원칙적으로 DB 서버 수에 비례해서 저장소가 증가.
+- 단점은..!
+- 저장소를 공유하지 않는다는 겻은 결국 디비 서버가 동일한 1개의 데이터에 접근할 수 없다라는 것을 의미.
+- 고양시 데이터를 가진 디비 서버가 접근할 수 있는건 고양시 데이터뿐, 부천시 광명시 데이터는 접근 불가
+- 또한 시별 인구 데이터를 합산해서 경기도 인구 계산하려는 경우 각 테이블로부터의 JOIN 연산 요구됨
+
+## 끝 !