Write Once의 데이터베이스
- 트랜젝션에 대한 데이터베이스 아키텍처는 커밋 시에 REDO 로그 파일에 기록하고 그 후에 데이터 파일(데이터 영역과 인덱스 영역)에 기록하는 구조로 되어 있음. 두 번 기록하는 구성
- 두 번 기록을 하는 큰 이유는 HDD와 같은 디스크에서는 시퀀셜 라이트가 랜덤 액세스보다 압도적으로 빠르기 때문
- REDO 로그 파일로의 쓰기는 시퀀셜 라이트, 데이터 파일로의 읽기는 랜덤 액세스.
- 한편, SSD의 급부상으로 인해 랜덤 액세스의 성능 차이가 그렇게까지 극단적으로 벌어지는 일이 없게 됨. 반대로 2회 쓰기의 오버헤드도 무시하지 못하게 되어 그것이 역으로 성능을 떨어뜨리는 경우도 있음 ⇒ 1회 쓰기로 완료하는 아키텍처를 채용한 데이터베이스의 구현 (PBXT, RethinkDB — SSD에 특화된 스토리지 엔진)
Write Scaling
- 참조 처리의 성능 향상은 슬레이브 서버를 추가하거나 캐시 서버의 추가로 쉽게 구현할 수 있지만, 쓰기 성능을 높이는 것은 쉽지 않음. 이 때문에 간단히 쓰기 성능을 올릴 수 있는 데이터베이스가 중요한 역할을 하게 될 것
다중 마스터 구성
- 지역별 최적화가 쉬워짐
- 다중 마스터 구성의 과제는 갱신 충돌을 어떻게 감지할 것인가임
- 동일한 기본 키에서 동시에 다른 마스터에서 업데이트되는 현상이 발생했을 때 어느 쪽을 통일하면 좋을 지
자동 Shard 편성
- 한 대의 서버에서 애플리케이션의 모든 갱신 처리를 해야 하면 트래픽 증가로 조만간 파탄에 이르게 됨
- 따라서 데이터 마다 복수의 서버로 분산하여 한 대당 데이터 양을 줄이고 갱신 처리도 분산시키는
수평 분할이라고 하는 접근 방법이 웹 서비스에서는 잘 사용됨
- Sharding 구성을 취하기 위해서는 기본적으로 애플리케이션에서 어떤 ID가 어느 Shard로 가는가 라는 매핑 정보 관리가 필요함
- 이러한 Shard 의 추가 및 재배치를 완전히 자동화하는 유형의 데이터베이스
- MySQL Cluster
- MongoDB