RDBMS/DB Basics
DB 이중화 / 클러스터링
DB 이중화 / 클러스터링
2020.09.23DB 클러스터링 DB 장애 시 가용성을 유지하기 위한 클러스터링 방안 Oracle 기준이긴 하지만, 다른 DB에서도 비슷한 옵션이 있는 경우 있음. HA ( High Availability ) 같은 장비를 Active 1대 , Standby 1대로 구성해서 Active에 문제 생기면 Standby로 서비스 하는 방식. Active, Standby 각자가 별도 storage를 가지고 있음. => Active와 Standby의 데이터 동기화 문제 및 성능 저하 => Active 가 죽고 Standby로 전환되기 전 그 사이에 발생하는 트랜잭션은 유실됨 - 데이터 불일치. 정합성 bad *** 오라클에서는 데이터 가드 라는 이름으로 제공하고 있다. *** 위와 같은 문제점 때문에 OPS 방식이 8i 버전까지 ..
[DB] 분산 DB, 파티셔닝 (partitioning ), 샤딩 (sharding)
[DB] 분산 DB, 파티셔닝 (partitioning ), 샤딩 (sharding)
2019.08.25파티셔닝(단편화) 란? 저장해야 하는 정보가 많은 대규모 시스템의 경우 하나의 DB에 모든 정보를 저장해서는 제대로 된 응답성을 기대할 수 없다. read가 많이 발생하든, write가 많이 발생하든 DB 저장하는 정보가 많을 수록 스캔 속도도 느려지고, 요청이 많은 경우 큐에 작업이 쌓이면서 응답도 느려진다. 그래서 DB를 여러대 운용해서 응답을 좀 분산해보자, 라는 생각을 하게 되는데, 가장 쉽게 생각해 볼만한건 Master DB의 데이터를 복제한 Slave DB를 두고, read를 분산하는 것이다. 스캔 속도는 그대로겠지만 요청을 분산할 수 있다. 그러나 이 방법은 write는 분산되지 않는다. Master에 write가 발생하면 이를 Slave에 복제 해줘야 하므로, 복제하면서 같은 내용의 wri..
7장. 릴레이션 정규화
7장. 릴레이션 정규화
2018.04.12ER 스키마 >> 릴레이션 사상 간단한 요소에서 복잡한 요소 순으로 사상한다. 단계 1: 정규 엔티티 타입 단계 2: 약한 엔티티 타입 단계 3: 2진 1:1 관계 타입 단계 4: 정규 2진 1:N 관계 타입 단계 5: 2진 M:N 관계 타입 단계 6: 3진 관계 타입 단계 7: 다치 애트리뷰트 정규화 Normalization 정규화란 무엇이고 왜 하나? 정규화란? 릴레이션 스키마를 함수적 종속성과 기본키를 기반으로 분리하는 것. 왜 하나? 1. 데이터 중복 최소화 2. [수정, 삽입, 삭제] 이상 최소화 (보통 데이터 중복 -> 갱신 이상으로 이어지는 경우가 많음.) 세 가지 갱신 이상 수정 이상 : 데이터가 중복되어 모든 항목을 일괄 수정하지 않으면 데이터 불일치가 발생 삽입 이상 : 불필요한 정보를..
6장. 물리적 데이터베이스 설계 : 인덱스 기본 원리
6장. 물리적 데이터베이스 설계 : 인덱스 기본 원리
2018.04.06디스크 상에서 화일의 레코드 배치 결국 DB에 저장되어 있는 레코드들도 최종적으로는 파일 안에 들어있다. [원하는 레코드가 위치한 블록을 어떻게 빨리 찾을 것인가?, 블록을 얼마나 적게 읽을 것인가?]가 핵심. Disk IO는 block 단위로 이루어지기 때문에 block을 몇 개 읽어야 하는지가 중요하다. (page 단위로 메모리에 올리게 되니까) DBMS의 버퍼 관리 어차피 DB에 있는 레코드들도 다 디스크에 저장되어 있다가 메모리에 올라가야 서빙이 가능함. DBMS는 메모리에서 버퍼 영역을 따로 잡고 관리함. 다단계 인덱스 대부분의 다단계 인덱스는 B+ 트리를 사용 06장. 인덱스 구조 / 07장. 인덱스된 순차 화일 : B트리 클러스터링 인덱스 vs 비 클러스터링 인덱스 클러스터링 인덱스 (기본 ..
5장. 데이터베이스 설계와 ER 모델
5장. 데이터베이스 설계와 ER 모델
2018.01.07ERD (Entity-Relationship Diagram) 중요성 개체-관계 모델 설명 wiki ERD가 없으면 기존 구조를 파악하기 어려워, 새로운 컬럼이나 테이블을 추가하면서 역정규화 되거나, 같은 내용의 컬럼이 서로 다른 테이블 2개에 각각 생성되는 경우가 빈번하다. 이는 갱신이상 등 데이터 불일치를 유발한다. 이런 식으로 같은 용도의 테이블을 여러개 추가하다 보면 돌이킬 수 없어진다. 나중에 정규화 하려고 했는데 기존 레코드를 싹 다 복사해서 2개로 나눠주어야만 한다거나, migration이 운영 환경에 영향을 주는 등 불상사가 발생할 수 있다. 따로 손으로 관리하기 보단 DB tool, IDE 등에서 현재 table 구조 바탕으로 ERD 자동 생성해주는 기능 사용하는게 편한데, FK를 사용하지..