들어가며
해당 강의를 보며 정리한 내용입니다.
RDBMS의 한계와 어려움
RDBMS 진영에서는 일반적으로 정규화를 통해 테이블을 설계합니다. 단일 서버 환경에서는 모든 데이터가 단일 위치에 저장되어 있어 join 연산 시에 다른 서버에서 데이터를 가져올 필요가 없습니다. 이는 join 작업이 효율적으로 이루어져 원하는 데이터를 손쉽게 얻을 수 있게 해줍니다.
그러나 데이터 양이 몇 테라바이트를 초과하면 문제가 발생할 수 있습니다. 디스크에서 읽을 수 있는 속도는 한정되어 있는데 비해 데이터 크기는 계속해서 증가하기 때문입니다. 이러한 문제를 해결하기 위해 데이터를 여러 서버에 분산하여 저장하는 샤딩을 도입할 수 있습니다. 이를 통해 읽기 속도를 향상시킬 수 있습니다.
그러나 이로 인해 새로운 어려움이 발생합니다.
샤딩을 하게 되면 RDB의 특징이 되는 기능에 제약이 생겨 그 전처럼 RDB를 사용하지 못함
- 물리적으로 다른 노드의 데이터베이스와
join연산을 수행할 수 없는 문제 - Auto increment가 샤드별로 달라지는 문제
- 하나의 트랜잭션이 두 개 이상의 샤드에 접근할 수 없는 문제
예시
User 테이블: [UserID, FirstName, LastName, City, Province, Country]
UserOrders 테이블: [UserOrderID, UserID, OrderDate, OrderAmount]
해당 데이터가 두 대의 서버에 저장된다면, UserOrders의 백만 건이 Server1에, 다른 백만 건이 Server2에 저장될 수 있습니다. User 테이블의 몇 십만 명의 사용자도 두 서버에 분산될 것입니다.
SELECT U.Country, SUM(UO.OrderAmount) AS TotalSales
FROM User AS U
INNER JOIN UserOrders UO ON U.UserID = UO.UserID
GROUP BY U.Country문제점
복잡성 증가: 샤딩된 데이터는 여러 서버에 분산되어 있기 때문에 쿼리 및 데이터 관리가 복잡해집니다. 특히, 조인 연산이나 트랜잭션 처리와 같은 복잡한 작업들이 관리의 어려움을 초래할 수 있습니다.
일관성 유지: 여러 서버에 데이터를 분산하면 일관성을 유지하는 것이 복잡해집니다. 특히, 분산된 서버 간의 트랜잭션 처리 및 데이터 동기화에 대한 관리가 필요합니다.
조인과 같은 복잡한 쿼리가 발생하는 경우 샤딩 이전 환경의 쿼리보다 느리고 에러 발생 빈도도 높아질 위험이 있다. 그리고 무엇보다도 샤딩은 유지보수, 확장 관점에서도 복잡도가 매우 높아진다. 샤딩을 도입하더라도 조인이 없는 단순한 경우에 적용할 것을 권하고 있다.
샤딩
Range Based Sharding
Modules (Key, Hash Based) Sharding
Case Study
