반응형

트랜잭션

< 트랜잭션 정의 >

  • 한꺼번에 모두 수행되어야 할 일련의 연산들
  • 병행 제어 및 회복 작업시 처리되는 작업의 논리적 단위
  • 하나의 트랜잭션은 Commit / RollBack된다

< 트랜잭션 특징(ACID) >

  • 원자성(Automicity) : Do or Nothing, 트랜잭션 내의 모든 명령은 완벽히 수행되거나 전부가 취소되어야 한다.
  • 일관성(Consistency) : 트랜잭션 실행이 성공적으로 완료되면 일관성 있는 데이터베이스의 상태는 일관되어야 한다.
  • 독립성(Isolation) : 어느 하나의 트랜잭션 실행중에 다른 트랜잭션 연산이 끼어들 수 없다.
  • 지속성(Durability) : 완료된 트랜잭션은 시스템의 고장나도 영구적으로 반영되어야 한다.

  • Commit 연산 : 한개의 트랜잭션에 대한 작업이 성공적으로 끝났고, 데이터베이스가 일관된 상태에 있을 때 이 트랜잭션이 수행한 연산이 완료됨을 알려주는 연산
  • Rollback 연산 : 하나의 트랜잭션 처리가 비정상적으로 종료되어 데이터베이스의 일관성을 깨뜨렸을 때, 트랜잭션의 원자성을 구현하기 위해 이 트랜잭션이 수행한 모든 연산을 Undo하는 연산이다.
    • Redo : 고장 발생 전, 트랜잭션이 완료 명령을 수행했다면 로그를 이용해 복원하고 Check Point 이후부터 다시 수행하는 방식
    • Undo : 고장 발생 전, 트랜잭션이 완료 명령을 수행하지 못했다면 DB에 반영된 갱신 사항을 처음까지 취소

병행제어 기법

< 병행제어의 목적 >

  • 데이터베이스 공유를 최대화한다.
  • 시스템 활용도를 최대화한다.
  • 데이터베이스 일관성을 유지한다.
  • 사용자 응답 시간을 최소화한다.

< 로킹(Locking) 기법 >

  • 트랜잭션들이 어떤 로킹 단위를 액세스하기 전에 Lock을 요청해서 Lock이 허락되야 그 로킹 단위를 액세스 하는 기법
  • 로킹 단위 : 병행제어에서 한꺼번에 로킹할 수 있는 객체의 크기를 의미하며 로킹의 단위가 크면 로크 수가 작아 관리하기 쉽지만 병행성 수준이 낮아진다.
    • 로킹 단위가 크면 lock 개수가 적어 관리하기 쉽지만 병행성 수준이 낮아진다.
    • 로킹 단위가 작으면 lock 개수가 많아 관리하기는 복잡하지만 병행성 수준이 높아진다.
  • 데이터를 갱신할 때 잠금(Lock) → 실행(Execute) → 해제(Unlock)
  • 교착상태(Deadlock) : Lock상태가 오래 유지되어 다른 Transaction들이 더이상 진행하지 못하고 무한정 대기상태를 뜻한다

  • 공유 잠금(Shared-Lock) : 한 트랜잭션이 데이터 x에 lock-S 를 걸면 다른 트랜잭션은 데이터 x에 대해 read 가능 / write 불가능
  • 배타 잠금(Exclusive-Lock) : 한 트랜잭션이 데이터 x에 lock-X 를 걸면 다른 트랜잭션은 데이터 x에 대해 read 불가능 / write 불가능
 공유 잠금베타 잠금
공유 잠금접근 허용대기
배타 잠금대기대기

< 2-단계 잠금 규약(Two-Phase Lock Protocol) 기법 >

  • 트랜잭션 스케쥴의 직렬성을 보장하는 대표적인 기법
  • 확장 단계(Growing Phase)
    • Lock을 설정하는 단계, 해제 불가
    • 새로운 lock 연산만 수행할 수 있고 unlock 연산은 수행할 수 없는 단계
  • 축소 단계(Shirinking Phase)
    • Lock을 해제하는 단계, 잠금 불가
    • unlock 연산만 실행할 수 있고 일단 unlock 연산을 실행하면 lock 연산은 실행할 수 없는 단계
  • 장점 : 직렬성 보장 / 단점 : 교착 상태 예방 불가능

< 타임 스탬프(Time Stamp Ordering) 기법 >

  • 시스템에 도착한 순서대로 타임 스탬프를 부여하여, 순서대로 실행하도록 한다.
  • 교착 상태가 발생하지 않는다.

< 로킹 규약 >

  1. 트랜잭션 T가 read(x)나 write(x) 연산을 하려면 반드시 먼저 lock(x) 연산을 실행해야 한다.
  2. 트랜잭션 T가 실행한 lock(x)에 대해서는 T가 모든 실행을 종료하기 전에 반드시 unlock(x)을 실행시켜야 한다.
  3. 다른 트랜잭션에 의해 이미 x에 lock이 걸려있다면 다시 lock(x)를 실행할 수 없다.
  4. 트랜잭션 T가 lock(x)를 실행하지 않았다면 T가 unlock(x)를 실행할 수 없다.

무결성

  • 무결성 : 데이터의 정확성과 일관성을 유지하고 보증하는 것
    • 고유 무결성 : 릴레이션의 특정 속성에 대해서 각 튜플이 갖는 값들이 서로 달라야 한다.
    • 개체 무결성 : 릴레이션에서 기본키를 구성하는 속성은 NULL 값이나 중복값을 가질 수 없다.
    • 참조 무결성 : 외래키 값은 NULL 이거나 참조 릴레이션의 기본키 값과 동일해야 한다.
  • cf) 정확성 : 데이터베이스의 저장된 데이터 값과 현실 세계의 실제값이 일치하는 정도

보안

  • 데이터베이스의 일부분 또는 전체에 대해서 권한이 없는 사용자가 엑세스하는 것을 금지하기 위한 기술
  • 데이터베이스 사용자들은 일반적으로 서로 다른 객체에 대해 다른 접근 권리/권한을 갖게 된다.

< 암호화 기법 >

< 개인키 암호 방식 = 대칭형 암호 알고리즘 >

  • 동일한 키로 데이터 암호화/복호화 진행
  1. 수신자에게 키를 전달하는 방법
    • Key를 비대칭형 암호 알고리즘을 이용하여 암호화 시킨 후 전송
  2. 실제 Key를 전송하지 않고도 A와 B가 동일한 Key를 생성할 수 있도록 하는 Diffie-Hellman 알고리즘 사용

< 공개키 암호 방식 = 비대칭형 암호 알고리즘 >

  1. A는 공개키(public key)와 개인키(private key) 를 생성한다.
    • A의 공개키를 이용하여 암호화된 데이터는 A의 개인키로만 복호화가 가능하다.
    • A의 개인키를 이용하여 암호화된 데이터는 A의 공개키로만 복호화가 가능하다.
  2. A와 B는 각자의 공개키를 서로에게 알려준다.
    • A : 공개A키, 개인A키, 공개B키
    • B : 공개B키, 개인B키, 공개A키
  3. A는 B에게 데이터를 전송하기 위해 B의 공개B키를 이용하여 데이터를 암호화한 후 전송한다
  4. 암호화된 데이터는 개인B키를 가지고 있는 B만 해독할 수 있다.

< 권한 부여 기법 >

  • GRANT : 권한 부여 명령
    • GRANT 사용자 등급 TO 사용자 ID 리스트
  • REVOKE : 권한 취소 명령
    • REVOKE 사용자 등급 FROM 사용자 ID 리스트

분산 데이터베이스

< 분산 데이터베이스 정의 >

  • 논리적으로는 하나의 시스템에 속하지만 물리적으로는 네트워크를 통해 여러 개의 사이트에 분산되어 있는 데이터베이스
  • 장점 : 자료의 공유성 향상, 시스템 성능 향상, 신뢰성 및 가용성이 높다
  • 단점 : DBMS가 수행할 기능이 복잡, DB설계가 복잡, 소프트웨어 개발 비용이 증가


반응형
반응형

관계형 데이터페이스 구조

  • 릴레이션(Relation): 데이터베이스 테이블
  • 튜플(Tuple) : 릴레이션을 구성하는 각각의 행, 튜플의 수를 카디널리티라 부른다.
  • 속성(Attribute) : 데이터베이스를 구성하는 가장 작은 논리적 단위
  • 도메인(Domain) : 도메인은 하나의 애트리뷰트가 취할 수 있는 같은 타입의 원자들의 집합

< 릴레이션의 특징 >

  • 한 릴레이션에 포함된 튜플은 모두 다르다.
  • 튜플 사이의 순서가 없고 삽입/삭제 등으로 인해 시간에 따라 변한다.
  • 속성 값은 논리적으로 더 이상 쪼갤 수 없는 원자값만을 저장한다.

관계형 데이터베이스 제약 조건

  • 후보키 : 기본키로 사용할 수 있는 속성, 모든 튜플에 대해서 유일성과 최소성을 만족한다.
    • 유일성 : 하나의 키 값으로 하나의 튜플을 유일하게 식별 가능해야 한다.
    • 최소성 : 모든 레코드들을 유일하게 식별하는 데 꼭 필요한 속성만으로만 구성되어야 한다.
  • 기본키 : 후보키중 선택한 주 키로 NULL 값을 가질 수 없다.
  • 대체키 : 후보키가 둘 이상일 때 기본키를 제외한 나머지 후보키를 말한다.
  • 외래키 : 관계를 맺고 있는 두 실레이션에서 한 릴레이션이 참조하고 있는 다른 릴레이션의 기본키와 같은 릴레이션의 속성을 말한다.
  • 무결성 : 데이터의 정확성과 일관성을 유지하고 보증하는 것
    • 개체 무결성 : 릴레이션에서 기본키를 구성하는 속성은 NULL 값이나 중복값을 가질 수 없다.
    • 참조 무결성 : 외래키 값은 NULL 이거나 참조 릴레이션의 기본키 값과 동일해야 한다.

관계 대수 및 관계 해석

< 관계 대수 >

  • 관계형 데이터베이스에서 원하는 정보와 어떻게 유도하는지 기술하는 절차적인 언어11st_result

< 관계 해석 >

  • 관계 데이터의 연산을 표현하는 방법으로 원하는 정보를 정의할 때는 계산 수식을 사용한다.
  • 원하는 정보가 무엇인지만 정의하는 비절차적 특징을 지닌다.
  • 튜플 관계해석과 도메인 관계해석이 있다.

정규화

< 정규화 목적 >

  • 종속성 이론을 이용하여 잘못 설계된 관계셩 스키마를 더 작은 속성의 세트로 쪼개 바람직한 스키마로 만들어 가는 과정
  • 데이터 구조의 안정성을 최대화해 중복성 및 종속성을 배제시키는 방법으로 사용한다.
  • 효과적인 검색 알고리즘을 생성하고 중복을 배제해 삽입/삭제/갱신 이상의 발생을 방지한다.
    • 삽입 이상 : 릴레이션에 데이터를 삽입할 때 의도와는 상관없는 원하지 않는 값들도 함께 삽입되는 현상
    • 삭제 이상 : 릴레이션에 한 튜플을 삭제할 때 의도와는 상관없는 값들도 함께 삭제되는 현상
    • 갱신 이상 : 릴레이션에서 튜플에 있는 속성 값을 갱신할 때 일부 튜플의 정보만 갱신되어 정보에 모순이 생기는 현상

< 정규화 과정 >

  • 제 1정규형 : 다치가 존재하지 않는 릴레이션
  • 제 2정규형 : 부분 함수적 종속성 x (기본키가 기본키가 아닌 속성에 종속 관계를 가짐)
    • R(AB, C, D), A->C 일때 R1(A, C), R2(AB, D)
  • 제 3정규형 : 이행적 종속 관계 x (기본키가 아닌 속성이 다른 속성에 종속 관계를 가짐)
    • R(A,B, C, D), C->D 일때 R1(C, D), R2(AB, D)
  • BCNF : 3 정규형에서 결정자이며 후보키가 아닌것 제거
  • cf) 종속 관계 : ‘학번’에 따라 ‘이름’이 결정될 때 ‘이름’을 ‘학번’에 함수 종속적이라 하며 ‘학번->이름’으로 표기한다.

데이터베이스 언어

  • DDL(Data Definition Language)
    • DB 구조, 데이터 형식, 접근 방식 등 DB를 구축하거나 수정할 목적으로 사용되는 언어
    • 외부 스키마 명세를 정의하고 논리적/물리적 데이터 구조 정의
    • CREATE, ALTER, DROP, RENAME 등의 명령어를 사용한다.
      • CREATE SCHEMA/DOMAIN/TABLE/INDEX 이름
      • ALTER TABLE 테이블이름 ADD/ALTER/DROP 속성이름
      • DROP SCHEMA/DOMAIN/TABLE/VIEW [CASCADE/RESCTRICTED]
  • DML(Data Manipulation Language)
    • 사용자가 데이터를 처리할 수 있게하는 도구로 사용자와 DBMS간의 인터페이스를 제공한다.
    • SELECT, INSERT, DELETE, UPDATE 등의 명령어를 사용한다.
    • SELCT ~ FROM ~ WHERE ~ GROUP BY ~ HAVING ~
    • INSERT ~ INTO ~ VALUES ~
    • DELETE ~ FROM ~ WHERE ~
    • UPDATE ~ SET ~ WHERE ~
  • DCL(Data Control Language)
    • 무결성, 보안 및 권한 제어, 회복 등을 하기 위한 언어다.
    • GRANT(권한 생성), REVOKE(권한 삭제)

뷰(VIEW)

  • 사용자에게 접근이 허용된 자료만을 제한적으로 보여주기 위해 유도된 가상 테이블이다.
  • 물리적으로 저장장치에 존재하지 않지만 있는 것처럼 간주한다.
  • 기본 테이블과 같은 구조를 가지며 조작도 기본 테이블과 거의 같다.
  • 정의된 뷰는 다른 뷰의 정의에 기초가 될 수 있다.
  • 뷰가 정의된 기본 테이블이나 뷰를 삭제하면 그 테이블을 기초로 정의된 다른 뷰도 삭제된다.

  • 장점 : 접근 제어를 통한 자동 보안과 사용자 데이터를 간단하게 해준다.
  • 단점 : ALTER VIEW로 정의를 변경할 수 없다. 삽입/삭제/갱신 연산에 제약이 따른다.

시스템 카탈로그 (=데이터 사전)

  • 시스템 자체에 관련이 있는 다양한 객체에 관한 정보를 포함하는 시스템 데이터베이스이다.
  • 데이터 객체에 대한 정의나 명세에 관한 정보를 유지/관리하는 시스템 테이블이다.
  • 데이터 정의어의 결과로 구성되는 기본 테이블, 뷰, 인덱스, 접근 권한 등의 데이터베이스 구조 및 통계 정보를 저장한다.
  • 카탈로그는 DBMS가 스스로 생성하고 유지한다.
  • 시스템 테이블로 구성되어 있어 일반 이용자도 SQL을 이용하여 내용을 검색할 수 있다.
  • INSERT/DELETE/UPDATE 문으로 카탈로그를 갱신하는 것은 허용되지 않는다.


반응형
반응형

데이터베이스 개념

< 데이터베이스 정의 >

  • 통합된 데이터 : 자료의 중복을 배제한 데이터의 모임
  • 저장된 데이터 : 저장 매체에 저장된 자료
  • 운영 데이터 : 조직의 고유 업무 수행을 위해 반드시 필요한 자료
  • 공용 데이터 : 여러 응용 시스템들이 공동 소유하는 자료

< 데이터베이스 특징>

  • 실시간 접근성 : 실시간 처리에 대한 응답이 가능해야 한다.
  • 계속적인 변화 : 데이터 삽입, 수정, 삭제, 갱신으로 항상 최신의 데이터를 유지해야 한다.
  • 동시 공용 : 다수의 사용자가 동시에 같은 내용의 데이터를 이용할 수 있어야 한다.
  • 내용 참조 : 데이터를 참조시 사용자가 요구하는 데이터 내용으로 데이터를 찾는다.

DBMS 기능

< DBMS 정의 >

  • 사용자와 데이터베이스 상에서 사용자의 요구에 따라 정보를 생성 및 관리해주는 소프트웨어
  • 파일 시스템의 단점인 종속성, 중복성의 단점을 해결한다.

< DBMS 필수 기능 >

  • 정의(Definition) 기능
    • 데이터베이스에 저장할 데이터의 형과 구조에 대한 정의, 이용 방식, 제약 조건 등을 명시하는 기능
    • 데이터와 데이터 관계를 명확히 명세할 수 있어야 한다.
  • 조작(Manipulation) 기능
    • 데이터 검색/갱신/삽입/삭제 등을 체계적으로 처리하기 위해 사용자<->데이터베이스 사이의 인터페이스 수단 제공
  • 제어(Control) 기능
    • 데이터의 무결성이 유지되어야 한다.
    • 사용자별 허가된 데이터만 접근할 수 있도록 권한 검사를 수행한다.
    • 여러 사용자가 데이터베이스를 동시에 접근해 데이터를 처리할 때 처리 결과가 항상 정확성을 유지하도록 병행 제어를 수행해야 한다.

스키마

  • 데이터베이스의 구조와 제약조건에 관한 전반적인 명세를 기술한 메타데이터 집합이다.
  • 스키마는 데이터 개체(Entity), 속성(Attribute), 관계(Relationship) 및 제약 조건에 전반적으로 정의한다.
  • 외부 스키마
    • 사용자가 각 개인의 입장에서 필요로 하는 데이터베이스 논리적 구조를 정의한 것
    • 일반 사용자는 SQL을 이용해 DB를 쉽게 사용할 수 있다.
  • 개념 스키마
    • 데이터베이스의 전체적인 논리적 구조로 단순 스키마라고 하면 개념 스키마를 의미한다.
    • 개체간의 관계와 제약조건, 접근권한, 보안 및 무결성 규칙에 관한 명세를 정의한다.
  • 내부 스키마
    • 물리적 저장장치의 입장에서 본 데이터베이스 구조로 시스템 설계자가 보는 관점의 스키마를 의미한다.
    • 실제로 데이터베이스에 저장될 레코드의 물리적인 구조를 정의하고 저장 데이터 표현 방법, 내부 레코드 물리적 순서 등을 나타낸다.

데이터 모델

  • 개체(Entity) : 레코드에 대응하는 것으로 어떤 정보를 제공하는 역할 수행
  • 속성(Attribute) : 데이터의 가장 작은 논리적 단위로서 파일 구조상의 데이터 항목 또는 데이터 필드에 해당

< E-R 모델 >

11st_result

  • 개체와 개체간의 관계를 기본 요소로 이용하여 데이터를 개념적인 논리 데이터로 표현하는 방법

데이터베이스 설계

< 데이터베이스 설계 고려 사항>

  • 무결성 : 삽입, 삭제, 갱신 등의 연산 후에도 저장된 데이터가 정해진 제약 조건을 항상 만족해야 함
  • 일관성 : 데이터베이스에 저장된 데이터들 사이나 특정 질의에 대한 응답이 처음부터 끝까지 일정해야 함
  • 회복 : 시스템 장애가 발생시 장애 발생 직전 상태로 복구할 수 있어야 함
  • 보안, 효울성, 데이터베이스 확장 등…

< 개념적 설계 >

  • 현실 세계에 대한 인식을 추상적 개념으로 표현하는 과정
  • 개념 스키마 모델링과 트랜잭션 모델링을 병행 수행한다.
  • 요구 분석 단계에서 나온 결과를 DBMS에 독립적인 E-R 다이어그램으로 작성

< 논리적 설계 >

  • 현실 세계 자료를 컴퓨터가 처리할 수 있는 물리적 저장장치에 저장할 수 있도록 변환하기 위해 논리적 구조로 변환시키는 과정
  • 데이터 타입과 데이터 타입들 간의 관계로 표현되는 논리적 구조의 데이터로 모델화
  • 개념 스키마를 평가 및 적재하고 DBMS에 따라 서로 다른 논리적 스키마를 설계하는 단계
  • 트랜잭션 인터페이스 / 테이블 설계

< 물리적 설계 >

  • 논리적 구조로 표현된 데이터를 물리적 저장장치에 저장할 수 있는 물리적 구조의 데이터로 변환하는 과정
  • 데이터베이스 파일의 저장 구조 및 액세스 경로를 결정한다
  • 저장 레코드의 형식, 순서, 접근 경로와 같은 정보를 사용하여 데이터가 저장되는 방법을 묘사한다.
  • 저장 레코드 양식 설계, 레코드 집중의 분석 및 설계, 접근 경로 설계 등이 필수적으로 포함
  • 기본적인 데이터 단위는 저장 레코드이며 여러 타입의 저장 레코드 집합이다
  • 고려 사항 : 인덱스 구조, 레코드 크기, 레코드 개수, 트랜잭션 갱신과 참조 성향 등


반응형
반응형

* Sharding(샤딩)

샤딩은 수평 분할(Horizontal Partitioning)과 동일하며, 인덱스의 크기를 줄이고, 작업 동시성을 늘리기 위한 것이다.

수평 분할(Horizontal Partitioning)이란 스키마(schema)가 같은 데이터를 두 개 이상의 테이블에 나누어 저장하는 디자인을 말한다. 

가령 같은 주민 데이터를 처리하기 위해 스키마가 같은 '서현동주민 테이블'과 '정자동주민 테이블'을 사용하는 것을 말한다. 

데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리한다.


* Sharding(샤딩)의 단점

프로그래밍적, 운영적인 복잡도가 높아진다. 

즉, 샤딩을 시작하기 전에 샤딩을 피하거나 지연시킬 수 있는 방법을 찾는게 우선이다.

1. 좀더 고스펙의 컴퓨터를 사용한다.

2. Read(Select) 명령이 많다면 Cache나 Database Replication을 적용한다.

3. Table의 일부 Column만 사용한다면 수직 분할(Vertically Partitioning)을 사용한다 / Cold & Hot data를 사용한다.


참고) Database Replication이란?

2개 이상의 DBMS를 Master와 Slave로 나누어 동일한 데이터를 저장한다.

Master DB는 Insert, Update, Delete의 기능을 수행하고, Slave DB에 실제 데이터를 복사한다.

Slave DB 시간이 오래걸리는 Select문의 기능을 수행하여 전체적인 Select문 성능을 향상시킨다.


참고) Cold / Hot Data 란?    Naver D2 :: Cold Storage 소개

Hot data : 자주 사용되는 데이터 

Cold data : 드물게 사용되거나 아예 사용되지 않는 데이터

Cold Storage : 에너지 절감을 위해 연산 능력에서 손해를 보더라도 낮은 가격과 저전력으로 자주 사용되지 않는 데이터를 처리하는 데이터 저장 장치 및 시스템 


* Sharding(샤딩)의 주요 관점

분산된 DB에서 어떻게 Data를 읽어올 것인지?

분산된 DB에 Data를 어떻게 잘 분산시킬지?

>> Shard Key를 어떻게 정의하는지에 따라 달라진다.


Case 1. Algorithm Sharding

Database id를 단순하게 나누어 샤딩하는 방식

Sharding Key는 hash(key) % NUM_DB 같은 방식

* 장점

같은 값을 가지는 key-value 데이터베이스에 적합하다.

* 단점

Cluster를 포함하는 Node 갯수가 변하게 되면 Resharding이 필요하다.

Hash Key로 분산되기 때문에 공간에 대한 효율이 부족하다.


Case 2. Dynamic Sharding

클라이언트는 Locator Service에 접근하여 Shard Key를 얻는다.

* 장점

Cluster가 포함하는 Node 갯수가 변하면 Shard Key를 추가하기만 하면 된다.

>> 확장에 유연하게 대처가능하다.

* 단점

Data Relocation시에는 Locator Service의 Shard key Table도 일치시켜야 한다.

Locator에 의존할 수 밖에 없는 구조이다.


Case 3. Entity Group

RDBMS의 Join, Index, Transaction을 사용하여 복잡도를 줄이는 방식과 유사

동일한 파티션의 관련 엔티티를 저장하여 단일 파티션 안에서 추가 기능을 제공하는 방식

* 장점

하나의 물리적인 Shard에 쿼리를 진행하면 효율적이된다.

사용자의 증가에 따른 확장성이 좋은 파티셔닝이다.

* 단점

특정 파티션간 쿼리가 자주 요구되는 경우가 있다.


* 참고자료

Database의 샤딩(Sharding)이란?

How Sharding Works

반응형
반응형

대부분의 시중은행은 ‘Oracle DB’라는 제품을 이용해서 데이터, 즉 고객의 돈을 관리한다. 

Oracle DB는 안정성과 성능은 이미 인정받았다. 하지만 비용이 비싸서 큰 회사가 아니면 사용하기 힘들다.


특히, Oracle DB를 쓰는 가장 큰 이유는 RAC(Real application clusters)라는 기능 때문인데, 

RAC는 간단히 말하면 하나의 DB를 여러 서버가 공유하는 기술이다.


하나의 DB를 여러 서버가 공유하기 때문에 서버 하나가 장애가 나도 데이터 정합성이 유지된다. 

즉, 서버 장애 때문에 고객의 돈이 사라지지 않는다는 의미다.



그러나 MySQL은 서버들이 DB를 공유하지 않고 서버마다 다른 DB가 있다. 

이 때문에 MySQL은 마스터와 슬레이브라는 구조의 시스템을 운용한다. 

마스터 서버로 시스템을 운용하면서 슬레이브 서버는 마스터 서버의 데이터를 특정 시점마다 복제한다. 

마스터에 장애가 나도 복제된 데이터를 가지고 있는 슬레이브로 대체해서 운용하면 된다는 이론이다.



그러나 마스터와 슬레이브가 완전 동기화 되지 않는 것이 문제다. 

마스터 서버에서 데이터가 발생한 후 슬레이브에 복제되기 전에 장애가 발생한다면 그 데이터는 유실된다. 

은행의 경우 데이터는 돈이기  때문에 고객의 돈이 사라진다. 은행이 MySQL과 같은 DB를 사용하지 않는 이유다.


카카오뱅크는 MySQL을 사용하면서 이 문제를 해결했다.

슬레이브가 마스터의 데이터를 비동기 방식으로 복제해도 데이터가 유실될 가능성을 막았다는 것이다.



카카오뱅크는 로스리스 리플리케이션(Lossless Replication)이라는 기능과 MHA(Master High Availability)라는 기능을 조합해 데이터 무손실을 유지한다.


로스리스 리플리케이션은 마스터에 변경이 생기면 ‘릴레이 로그’라는 것을 슬레이브에 남긴다. 

슬레이브가 마스터를 복제하기 전에도 릴레이 로그가 남는다. 

이는 마스터가 슬레이브에 데이터를 넘기기 전에 셧다운 된다고 해도, 슬레이브에 남아있는 릴레이 로그를 활용해서 마스터와 똑같은 데이터를 생성할 수 있다는 것이다.

MHA는 이를 기반으로 재빨리 복구하는 역할을 한다.


참고할 레퍼런스가 턱없이 부족함에도 불구하고, 금융업에 MySQL을 도입하였다는 것 자체가 신기한 도전인 것 같다.

반응형
반응형

ANSI SQL의 특징

1. 표준 SQL문이기 때문에 DBMS의 종류에 제약을 받지 않는다. (MySQL, OracleDB..)

2. 테이블간의 Join 관계가 FROM 에서 명시되기 때문에 WHERE 문에서 조건만 확인하면 된다.

즉, 가독성이 일반 Query문보다 좋다.


 대표적인 예시로 ANSI SQL의 두번째 장점인 가독성에 대해서알아보자.


* ANSI SQL

일반 SQL Query는 다음과 같다.

-- 일반적인 SQL Query 

SELECT * 

FROM table1 as t1, table2 as t2 WHERE t1.a = t2.b

즉, WHERE문에서 Table을 JOIN하는 방식이다.

단순한 Query라면 가독성에 전혀 문제가 없지만, Query가 길어지게되면 가독성이 떨어질 수 밖에 없다.


이와 다르게 ANSI SQL Query 는 FROM 절에서 JOIN을 이용하여 묶고, WHERE에는 검색 조건만 넣어 가독성이 좋다.

-- ANSI SQL Query 

SELECT * 

FROM table1 as t1 LEFT OUTER JOIN table as t2 ON t1.a = t2.b

위의 ANSI SQL에서는 LEFT OUTER JOIN을 사용하여 FROM절에 Table JOIN 하였다.

ANSI SQL에서 사용하는 INNER/OUERT JOIN 의 개념을 명확히 아는 것 또한 중요하다.


* INNER JOIN

두 테이블간 ON 조건을 만족하는 ROW만 출력된다.

-- INNER JOIN 

SELECT * 

FROM table1 as t1 INNER JOIN table2 as t2 ON t1.a = t2.b;

Query가 위와 같을 때, ON 조건인 t1.a = t2.b 를 만족하는 Row 만 출력된다.


* OUTER JOIN

대표적으로 자주 사용하는 LEFT OUTER JOIN 에 대해서 알아보면,

OUTER 명령어는 생략이 가능하다. 즉, LEFT OUTER JOIN = LEFT JOIN과 같다.

LEFT TABLE 을 기준으로 오른쪽에 덧붙이는 느낌으로 생각하면 된다.

즉, LEFT TABLE의 결과값을 가져오고 ON 조건에 해당하는 경우 오른쪽에 매칭, 데이터가 없는 경우 NULL로 출력된다.

-- OUTER JOIN 

SELECT * 

FROM table1 as t1 LEFT OUTER JOIN table2 as t2 ON t1.a = t2.b;

t1.a = t2.b 인 경우, t1의 값이 10행 이라면, 해당 쿼리의 결과도 10행이 유지되고, ON 조건에 해당하는 Row가 있다면 오른쪽에 데이터가 매칭된다.

단, 1개의 t1 행에 ON 조건을 만족하는 t2의 값이 여러개라면, Row가 증가할 수도 있다.


* 결론

ANSI SQL 에 맞춰서 Query를 짜는 습관을 가지자.

즉, WHERE 문에서는 검색조건만 넣도록, Table JOIN 은 FROM절에 묶어서 처리하자.

반응형