[29. March] 데이터베이스 개념 / TIL

데이터베이스

• 관계형 데이터베이스
• 비관계형 데이터베이스
• 레플리카

---

데이터베이스

• 데이터를 저장하고, 요청 시 해당 데이터를 찾아서 제공한다.
• 데이터베이스 검색 성능이 낮을 때, 좀 더 효율적이게 특정 키의 값을 확인하고 제공하기 위해 인덱스를 이용한다.
• 인덱스를 사용하지 않으면 요청받은 데이터를 찾기 위해 전체 데이터 베이스를 스캔해야하는 문제가 발생한다.
• 특정 기준으로 인덱싱 되어 있다면, 인덱싱 후 검색 시 효율성이 증가한다.
• 인덱스 
  - 데이터베이스에 저장된 기본데이터에서 파생된 부가적인 메타데이터 (복사본)
  - 원하는 데이터의 위치를 찾는데 도움을 주는 이정표 역할 (ex. 목차)
  - 인덱스의 추가 삭제는 허용되지만, 데이터베이스의 내용에는 영향을 주지 않고, 쿼리 성능에만 영향을 준다.
  - 쿼리 성능이 저하되는 이유는 쿼리 문을 통해 데이터 검색을 하면 데이터를 빨리 찾을 수 있게 해주는게 인덱스인데,
    인덱스가 없어지면 데이터를 찾는 속도가 줄어들 수 있기 때문이다.

---

관계형 데이터베이스 (SQL)

• 테이블의 구조와 데이터 타입을 사전에 정의하고, 테이블에 정의된 내용에 알맞는 형태의 데이터만 삽입할 수 있다.
• 테이블 간의 관계를 직관적으로 파악할 수 있다.
• 행과 열로 구성된 테이블에 데이터를 저장한다.
  - 열 (column) : 데이터 속성에 대한 정보 저장
  - 행 (row) : 각 열의 데이터 형식에 맞는 데이터 저장
• SQL을 활용하여 원하는 정보를 쿼리할 수 있으며, *스키마가 뚜렷하게 보인다.
  - SQL : 구조화된 쿼리 언어 / 데이터베이스에 쿼리를 보내 원하는 데이터를 가져오거나 삽입할 수 있다.
  - 스키마 (schema) : 데이터가 구성되고 저장되는 방식을 정의하는 구조 또는 프레임워크
  - 쿼리 (query) : 데이터를 검색어로 필터하기 위한 질의문
• 대표적 RDB : MySQL, Oracle, SQLite, MariaDB 등

---

비관계형 데이터베이스 (NoSQL)

• 데이터가 고정되어 있지 않은 데이터베이스
• shema-on-read : 데이터를 읽어올 때 스키마에 따라 데이터를 읽어온다.
• 데이터를 입력하는 방식에 따라, 데이터를 읽어올 때 영향을 미친다.
• 대표적 DB : MongoDB, Casandra

---

SQL vs NoSQL

종류	SQL	NoSQL
데이터 저장 (Storage)	SQL을 이용해서 저장 / 미리 작성된 스키마를 기반으로 정해진 형식에 맞게 저장	key-value, documemt, wide column, graph 등의 방식으로 저장
스키마 (Schema)	고정된 형식의 스키마 데이터 속성별로 열에 대한 정보를 미리 지정 데이터베이스를 전체 수정하는 경우 오프라인으로 전환할 필요가 있다.	동적으로 스키마 형태를 관리 행을 추가할 때 즉시 새로운 열을 추가할 수 있고, 개별 속성에 대해 모든 열에 대한 데이터를  반드시 입력하지 않아도 된다.
쿼리 (Querying)	테이블 형식과 관계에 맞춰 정보를 요청하는 질의문	데이터 그룹 자체를 조회하는 것에 초점을 둔다. UnQL로 데이터 요청 UnQL : 구조화 되지 않은 쿼리 언어
확장성 (Scalability)	수직 확장	수평 확장

---

레플리카 (Replica)
- 데이터베이스의 복사본을 저장하는 각각의 노드
- 원본이 되는 데이터베이스와 같은 데이터를 다른 위치에 존재하는 여러 노드에 유지하는 방식

---

특징

• 시스템 장애가 발생하면 다른 레플리카를 새로운 리더로 연결하여 가용성을 확보한다.
• 사용자의 요청이 하나의 데이터베이스에 집중될 경우, 레플리카를 읽기 전용 데이터베이스로 활용할 수 있다.
  이렇게 되면 사용자 트래픽이 각 데이터베이스로 분산되기 때문에 성능향상에 도움을 준다.
• 레플리카의 위치를 각 지역에 분산시키면 거리에 의한 지연 시간을 감소시킬 수 있다.
• 레플리카들의 데이터베이스가 정확히 같은 데이터를 가지고 있게 해야 한다.

---

데이터베이스를 레플리카에 복제하는 방법

• 동기식 복제 : 리더의 데이터 처리와 별개로 레플리카에서의 데이터 처리까지 모두 완료되어야 프로세스가 진행된다.
  - 프로세스가 완료되면, 레플리카와 리더 DB가 일관성 있게 최신 데이터 복사본을 가지고 있는 것을 보장할 수 있다.
  - 레플리카가 데이터 처리 작업을 완료할 수 없는 경우, 리더 DB도 프로세스를 진행하기 못한다. 그 경우 리더는 모든
    쓰기를 차단하고 동기 레플리카가 회복되기를 기다리기 때문에 시스템 운영이 멈출 수 있다.
• 비동기식 복제 : 동기와 다르게 레플리카의 처리 응답을 기다리지 않고 리더 DB가 자신의 작업을 완료하면 바로 응답한다.
  - 레플리카가 처리를 지속할 수 없더라도 리더는 쓰기 처리를 계속할 수 있다.
  - 레플리카가 읽기 전용으로 이용되고 있을 경우 사용자에게 리더와 같은 응답을 주지 못하거나, 데이터 불일치가
    발생할 수 있고, 불일치 상태가 길어지면 큰 문제가 될 수 있다.
  - 리더가 복구할 수 없는 상황이 발생하면 팔로워에게 복제되지 못한 모든 처리가 유실될 수 있으며, 클라이언트에게는
    정상 작동을 알린 이후여도 지속성을 보장하지 못하는 문제가 발생할 수 있다.
• 반동기식 복제 : 동기식과 비동기식을 나누어 사용한다.
  
  

---

파티셔닝

 

• 데이터를 작은 범위로 나누어 요청 데이터에 해당하는 파티션에만 접근하여 정보를 조회할 수 있어, 성능 저하를 피할 수 있다.
• 쏠림 현상을 방지하기 위해 일반적으로 파티셔닝과 복제는 함께 사용된다.
• 쏠림 현상 : 일정 파티션에 요청이 몰리는 현상 (핫스팟 : 불균형하게 부하가 높아진 파티션)
• 파티셔닝을 진행할 때는 각 서비스의 목적에 따라 검색 효율성을 높이는 것이 좋을지, 핫스팟 발생을 방지하는 것이 좋을지, 균형을 유지할 수 있는 적절한 방법을 구현해야 한다.

---

캐싱 - 동일 데이터의 잦은 조회

 

• 캐시 (Cache) : 임시로 복제된 데이터를 저장하는 장소로 사용자가 더 효율적이고 빠르게 원하는 데이터에 접근할 수 있게 하기 위해 설정된다.
• 사용자의 요청이 반복되는 데이터를 빠르게 제공하기 위해서 캐시를 활용하면, 원본 데이터가 존재하는 데이터베이스에 액세스 하는 것보다 훨씬 빠른 속도로 데이터를 제공하면서 전반적인 애플리케이션 환경이 개선된다.
• 캐시를 사용하며 원본 데이터베이스에 대한 쿼리 수를 줄이고, 데이터베이스 자체를 스케일링 할 필요성을 낮추면, 성능 향상과 더블어 비용을 절감하는 효과를 낼 수 있다.

---

캐시 타입

• Cache-aside : 먼저 캐시에서 원하는 데이터를 검색하여, 데이터가 캐시에 존재하지 않으면 데이터베이스에 직접 연결하도록 코드를 구성하고, 데이터베이스에서 직접 데이터를 확보했다면 애플리케이션은 해당 데이터를 캐시에 복사한다. 읽기 처리가 많은 워크로드에 적합한 캐시 방법이다.
• Read-through / Write-through Cache : 데이터베이스와 일렬로 배치되며, 캐시를 주 데이터 저장소처럼 취급한다. 데이터의 일관성을 보장하며, 애플리케이션 코드를 단순화하고 원본 데이터베이스에 전달되는 요청을 최소화할 수 있다.
  - Read-through를 통해 읽기 요청이 발생하면, 최초 데이터를 로드할 때만 캐시가 데이터베이스에 접근한다.
    읽기 처리가 많은 워크로드에 적합한 캐시 방법이다.
  - Write-through를 통해 쓰기 요청이 발생하면, 캐시에 데이터를 추가한 뒤 데이터베이스에도 데이터를 추가한다.
    항상 최신 상태를 유지하며 데이터 일관성을 보장 받을 수 있다.
• Write-behind / write-back Cache : 일단 캐시에 데이터를 저장하여 캐시가 백그라운드에서 비동기 방식으로 데이터를 기록한다. 쓰기가 완료되는 것을 기다릴 필요 없이 다음 작업을 진행할 수 있다.
  쓰기처리가 많은 워크로드에 적합한 캐시 방법이다. 

---

스트림 처리 - 배치 작업에 따른 성능 저하

 

• 데이터 배치작업 : 유입되는 데이터를 실시간 처리가 아닌 특정량 또는 특정기간 모아서 한번에 처리함. (일괄 처리)
• 단점
  - 예약된 일이 순차적으로 실행되기 때문에 앞선 프로그램의 실행이 끝나야 뒤에 등록된 데이터가 실행된다.
  - CPU가 필요없는 시간대에도 응용 프로그램이 CPU를 점유하고 있을 수 있어, 총 실행 시간이 오래걸릴 수 있다.
  - 성능 저하의 핵심은 CPU나 메모리 부하가 아닌 비효율적인 I/0 때문이다.

---

• 데이터 스트림 처리 : 스트리밍 데이터를 실시간으로 분석하며, 데이터의 크기를 알 수 없고 무한하고 연속적일 때 사용 된다.
  - 데이터 출력 속도는 데이터 입력 속도만큼 빠르며, 스트림 프로세서는 데이터를 몇 번의 패스로 처리한다.
  - 데이터가 생성되자마자 분석 시스템에 하나씩 데이터가 공급된다. 
• 특징
  - 시간에 민감하여 특정 시간이 지나면 중요성을 잃게 되기 때문에 짧은 시간에 분석 및 처리 되어야 한다.
  - 데이터 스트림은 연속적이고 실시간으로 발생하지만 시스템 요구사항에 따라 항상 그 순간에 실행되지는 않는다.
  - 스트림 데이터는 서로 다른 소스에서 오는 경우가 많아서 소스의 불일치로 인해 다양한 형식이 포함되어 있을 수 있다.
  - 다양성과 전송 매키너짐의 차이로 데이터 요소가 누락되거나 손상될 수 있고, 요소가 순서대로 도착하지 않을 수 있다.
  - 실시간으로 이루어지기 때문에 데이터 스트림은 휘발성이 높다.  반복적인 데이터 전송이 어렵고, 새 데이터는 마지막
    데이터와 동일하지 않을 수 있다. 

---

• 효율적인 DB 처리 방법 / 데이터 배치 처리 vs 데이터 스트림 처리

-	Batch	Stream
데이터 크기	방대한 양의 미사용 데이터	개별적이거나 소수의 기록
데이터 범위	사용 가능한 모든 데이터	최신 이벤트
성능	높은 지연 시간 (hour ~ day)	짧은 지연 시간 (msec ~ sec)
분석	대규모 데이터 세트에 복잡한 분석	간단한 분석, 실시간 응답
사용 예	은행 업무, 정산시스템	실시간 운송추적, 결제처리 시스템 서버 및 애플리케이션 로그

---

이벤트 : 상태 변화, 중대한 사건 발생 / 이벤트 기반 아키텍처

• 조직이 실시간으로 변화에 대응하여 의사 결정을 내릴 수 있는 유연한 시스템을 확보할 수 있도록 지원한다.
• 이벤트 생성자 : 이벤트를 감지하며 메시지로 해당 이벤트를 나타낸다. 이벤트 소비자 또는 이벤트 결과를 알지 못한다.
• 이벤트 소비자 : 이벤트 발생 알림을 받으며 이벤트를 처리할 수도 있고, 영향을 받기만 할 수도 있다.