Clustering
한 서버가 죽으면 어떻게 하지? 에 대한 해결법
active-active
DB 서버 두대를 묶고 두 DB 서버를 Active-Active 상태로 운영시, 하나의 DB가 죽더라도 나머지 DB 서버가 살아있기 때문에 정상적 서비스 가능
-> 또한 하나의 서버가 담당하던 부하를 두대의 DB 서버가 나눠서 담당하므로 CPU, Memory 관리 차원에서 효율적
-> 데이터를 어떤 서버에 질의하던 동일한 데이터를 얻음!
-> 단점으로는 병목이 발생할수 있고, 더 많은 비용이 듬
-> 병목을 해결하기 위해 두대 중 한대를 Stand-by로 둠
-> Active 상태의 DB에 문제 발생 시 Fail Over를 통해 두 서버가 상태를 상호 전환하여 장애에 대응
이 경우에는 Fail Over가 일어나는 동안 수초~수분 동안 손실 발생
-> DB 서버 2대를 구비하는 것은 Active-Active 방식과 같지만 효율은 떨어짐
Replication
저장된 데이터가 손실되면 어떻하지? 해결하기 위해 사용하는 방법
-> 클러스터링 방법 보완
유저가 마스터 DB 서버에 DML 작업 진행 시 마스터 DB는 그 데이터를 Slave에 복제
-> DB 스토리지가 한대여서 발생할 수 있는 데이터 손실 방지
Slave DB를 데이터 백업용으로만 쓰기엔 아까워서 select(리드 용도) 부하를 분산시키는 용도로 사용하기도 함
-> 이때 마스터 db는 insert,update,delete 작업 수행
이 경우 테이블 자체에 데이터가 엄청나서 Slave DB 서버를 N대 늘려도 원하는 데이터를 테이블로 부터 찾는데 많은 시간이 소요됨
Sharding
데이터가 너무 많아서 검색이 느린데 더 빠르게 어떻게 하지?를 해결하기 위해 사용하는 방법
데이터베이스에서의 샤딩(Sharding)은 한 테이블의 row들을 여러 개의 서로 다른 테이블, 즉 파티션으로 물리적으로 분리하는 것
샤딩은 보통 전체 데이터베이스 하나의 테이블에 전부 들어가기 힘든 데이터가 등장하고 DBMS가 테이블을 관리하기 힘들어짐에 따라 적용됨
데이터베이스를 샤딩하게 되면 기존에 하나로 구성될 스키마를 다수의 복제본으로 구성하고 각각의 샤드에 어떤 데이터가 저장될지를 샤드키를 기준으로 분리하게 됨
장점
Scale-Out이 가능
스캔 범위를 줄여서 쿼리 반응 속도를 빠르게 함
장애가 샤드 단위로 발생함
단점
프로그래밍 복잡도가 증가
데이터가 한 쪽 샤드로 몰릴 경우(Hotspot), 샤딩이 무의미 해짐
잘 못 사용할 경우 risk가 큼
한번 샤딩 사용시 샤딩 이전의 구조로 돌아가기 힘듬
종류
Hash Sharding
데이터베이스의 id를 hashing 샤딩하는 방식
-> 즉 간단히 하면 샤드키를 id%num을 하여 정하는 방식
-> 다만 한번 나눌 갯수를 정해놓으면 수정하지 못한다는 단점이 있고, 단순한 hashing 방식이기에 데이터가 저장되는 공간적 효율에 대한 고려는 따로 할 수가 없게 됨
Dynamic Sharding
Locator Service를 통하여 샤드 키를 정하는 방식
Locator Service를 한번 거쳐서 샤드키를 얻기 때문에 확장에 유연한 방식
-> 하지만 데이터의 재배치등에 있어서 Locator Service도 변환해야하기 때문에 Locator에 의존적인 단점
Entity Group
위의 key-value 방식인 Hash Sharding과 Dynaminc Sharding과는 다르게 동일한 파티션에 관련 엔티티를 저장하여 단일 파티션 안에서 추가 기능을 제공하는 방식
-> 즉, 관련된 데이터에 대해 하나의 샤드를 이용하는 방식
-> 하나의 물리적인 샤드를 사용하기에 쿼리진행시 효과적이며 응집도가 높아진다는 장점, 하지만 다른 샤드와 관련된 쿼리를 사용하게 된다면 샤드를 사용 안했을 때 보다 성능이 더 떨어질 수 도 있다는 단점이 존재
