3단계: 상세 설계
메타데이터 데이터베이스
이메일 메타데이터의 특성
- 이메일의 헤더는 일반적으로 매우 작으며, 빈번하게 사용된다.
- 이메일의 본문은 크기가 클 수 있고, 사용 빈도는 낮다
- 이메일의 특성상, 사용자별 격리가 필수적이다.
- 다른 사용자의 메일을 볼 수 없고, 보여서도 안된다.
- 데이터의 신선도가 사용 빈도에 영향을 끼친다.
올바른 데이터베이스의 선정
관계형 데이터베이스
- 주로 관계형 데이터베이스를 사용하는 이유는 효율적인 검색방식 때문이다.
- 하지만 반대로, 데이터 하나하나의 크기가 큰 경우에는 관계형 데이터베이스의 성능이 떨어질 수 있다.
- 특히 이메일의 경우, 본문의 크기가 매우 클 수 있으며, 이는 관계형 데이터베이스에서 사용하기 적합하지 않다.
분산 객체 저장소
- 아마존 S3등의 객체 저장소에 직접 저장하는 방안이다.
- 데이터를 단순히 보관하는데에는 좋지만, 데이터의 확인여부 표시, 메일 본문에 대한 키워드 검색 등에는 적당하지 않다.
NoSQL 데이터베이스
- 구글의 Gmail이 구글의 빅테이블(Bigtable)을 기반으로 구현되었다고 알려져있다.
- 하지만 빅테이블은 공개되어있지 않다.
- 대안으로 카산드라가 있지만, 실제로 메일 서비스에 카산드라를 사용한 사례는 없다.
결론
- 결과적으로, 시중의 일반적인 DB는 이메일 서비스에 적합하지 않다. 따라서 대부분의 기업들은 독자 DB를 구현하여 사용하고있다.
- 이러한 서비스가 갖추어야 할 조건은 아래와 같다.
- 단일 칼럼의 크기는 꽤나 클 수 있으며, 한 자릿수 MB일 수 있다
- 데이터 일관성이 보장되어야 한다.
- 디스크 IO는 최소화되어야 한다.
- 가용성이 아주 높아야한다.
- 증분 백업이 쉬워야 한다.
Q. 증분 백업(incremental backup)이란?
증분 백업은 이전 백업 이후 변경된 데이터만을 백업하는 방식이다.
즉, 이전 백업 이후 변경된 데이터만을 백업하므로, 백업 시간이 줄어든다.
데이터 모델
- 위에서 언급한 이메일의 특성상, 사용자간 격리가 필수적이다.
- 따라서
user_id를 파티션 키로 하여 샤딩을 할 수 있다.
❗ 파티션 키와 클러스터 키
파티션 키: 데이터를 분산하는 기준이 되는 키
클러스터 키: 파티션 내에서 데이터를 정렬하는 기준이 되는 키
일관성 문제
- 이메일의 경우 정확성이 매우 중요하다.
- 따라서 모든 메일은 주(primary) 사본을 통해 서빙되어야 한다.
- 즉, 이메일은 대체로 일관성을 위해 가용성을 포기해야 한다.
❗ CAP이론(Consistency, Availability, Partition tolerance)
분산 시스템에서는 아래 세 가지 특성을 모두 만족할 수 없다는 이론:
- 일관성(Consistency): 모든 노드가 같은 시점에 같은 데이터를 보여줘야 함
- 가용성(Availability): 장애가 발생하더라도 서비스는 계속 동작해야 함
- 분할 내성(Partition Tolerance): 네트워크 장애가 발생하더라도 시스템은 동작해야 함
안녕하세요!