[27일차] | 대규모 시스템 설계 기초2 | 책너두

3단계: 상세 설계

개선된 데이터 모델

• 앞서, room_id의 존재에 문제가 있었다.

• 이를 해결하기 위해 room_type_id를 사용하여 예약 요청을 수정한다.

  # POST /v1/reservations
  {
    "startDate": "2024-01-01",
    "endDate": "2024-01-03",
    "hotelID": "123",
  -  "roomID": "U1234567890",
  +  "roomTypeID": "U1234567890",
    "reservationID": "1234567890"
  }

• 이에따라 예약의 스키마는 아래와 같이 변경된다.

  컬럼	설명
  reservation_id	PK
  hotel_id	-
  room_type_id	-
  start_date	-
  end_date	-
  status	-
  guest_id	-

• 또한, 이렇게되면 객실을 직접 예약하는것이 아니므로, 이를 매핑하는 테이블을 추가해야 한다.

  • 이를 위해 room_type_inventory 테이블을 추가한다.

  컬럼	설명
  hotel_id	PK
  room_type_id	PK
  date	PK
  total_inventory	현재 가용한 객실 수. 예약 및 정비 등으로 인해 변동 가능
  total_reserved	현재 예약된 객실 수

• 이렇게 수정한 테이블을 사용하는 경우, 데이터의 추정 소요는 아래와 같다.

  • 5000개의 호텔, 각 20개 유형의 객실, 약 2년 간의 데이터 저장
  • 5000 x 20 x 365 x 2 = 7300만개 레코드

• 이정도 규모의 데이터는 단일 DB로도 충분히 처리할 수 있다.

  • 다만, 데이터가 더 많아진다고 가정하면 샤딩하거나, 오래된 데이터는 아카이빙 하는 선택지도 있다.

❗ 집계 테이블

집계 테이블은 원본 데이터를 미리 요약하거나 계산하여 저장하는 테이블로, 잦은 조회가 필요한 데이터 등에 대해 실시간 계산 없이도 빠르게 분석 및 보고를 가능하게 합니다.
예를 들어, 매일 혹은 주기적으로 주요 지표를 계산해 두고, 대용량 데이터에서 원하는 정보를 신속하게 조회할 수 있습니다.
하지만 저장 비용이 증가하고, 데이터를 관리하기가 까다로워집니다.
특히 이러한 호텔 예약의 경우, 동시 예약 건수가 증가하면 업데이트가 하나의 행에 대해 빈번하게 발생하게 되어 동시성 처리와 데이터 무결성을 보장하기 어려워 보이는데...