게시글 요구사항
•
각 게시판 단위로 게시글 서비스 이용
◦
사용자는 게시판에 게시글을 작성하고 조회한다.
•
게시글 조회, 생성, 수정, 삭제 API
•
게시글 목록 조회 API
◦
게시판별 최신순
게시글 테이블 설계
•
분산 데이터베이스를 가정하기 때문에 게시글이 N개의 샤드로 분산되는 상황을 고려한다. 이러한 샤딩을 직접 구현하지 않지만, Shard Key = board_id(게시판 ID)로 가정한다.
•
Shard Key는 왜 게시판 ID일까? 게시글 서비스는 게시판 단위로 서비스를 이용한다. 게시판 단위로 게시글 목록이 조회되는 것이다.
•
만약 Shard Key가 article_id 라면? 동일한 게시판에 속한 게시글이 별도의 샤드에 저장될 수 있다.
•
1번 게시판의 (1번 게시글 → 좌측 샤드), (2번 게시글 → 우측 샤드)
•
2번 게시판의 (3번 게시글 → 좌측 샤드), (4번 게시글 → 우측 샤드)
•
각 게시판의 게시글 목록을 조회하려면 게시글이 속한 모든 샤드에 조회를 요청해야 한다.
•
N개의 샤드라면, 게시글은 N개의 샤드로 분산되어 있으므로, 게시글 목록 조회를 위해 N개의 쿼리를 해서 목록을 만들어내는 복잡한 처리가 필요하다.
•
이러한 서비스 이용 특성에 따라서 board_id를 Shard Key로 선정한다. 각 게시판의 게시글 목록 조회를 하려면, 단일한 샤드에서 요청할 수 있다.
◦
1번 게시판의 (1, 2번 게시글 → 좌측 샤드)
◦
2번 게시판의 (3, 4번 게시글 → 우측 샤드)
•
쿼리를 위한 위 조건을 만족할 수 있다면, 샤딩 기법은 상황에 맞게 적절히 선택해볼 수 있다. 샤딩을 직접 구현하지는 않지만, 이해의 편의를 위해 Hash-based Sharding이라고 가정한다.
게시판 테이블 설계
create table article (
article_id bigint not null primary key,
title varchar(100) not null,
content varchar(3000) not null,
board_id bigint not null,
writer_id bigint not null,
created_at datetime not null,
modified_at datetime not null
);
SQL
복사
•
mysql 컨테이너 접속 → article 데이터베이스 생성, article 데이터베이스 접속
Primary Key 선택
•
오름차순 유니크 숫자를 애플리케이션에서 직접 생성한다.
◦
AUTO_INCREMENT or UUID를 사용하지 않는다.
◦
오름차순 유니크 숫자를 만들기 위한 알고리즘으로 Snowflake를 사용한다.
•
Snowflake
◦
분산 시스템에서 고유한 64비트 ID를 생성하는 알고리즘
▪
[1비트][41비트: 타임스탬프][10비트: 노드 ID][12비트: 시퀀스 번호]
▪
분산 환경에서도 중복 없이 순차적 ID 생성하기 위한 규칙
•
타임스탬프 : 순차성
•
노드ID + 시퀀스 번호 : 고유성
◦
유니크, 시간 기반 순차성, 분산 환경에서의 높은 성능
◦
미리 준비된 코드를 사용