DB - Unique Key preprocessing

---

문제점:

• 문제점
• 동일한 ShortId가 있는지 Write 요청이 올 때마다 확인하는 것과 생성하는 것은 비효율적이다.

---

해결책

• DB에 사용된 shortId , 사용되지 않은 shortId 테이블 두개를 생성해놓고, 발급하는 방식으로 구현하면 빠른 속도로 처리할 수 있다.
• 사용되지 않은 shortId 를 사용되지 않은 shortId 테이블에서 바로 가져와서 사용하면 된다.
• 사용된 shortId 는 사용되지 않은 shortId 테이블에서 빼서 shortId에 넣어준다.

create table unused_short_id
(
    id_short_id bigint auto_increment
        primary key,
    short_id      varchar(255) not null
);

create table used_short_id
(
    id_short_id bigint auto_increment
        primary key,
    short_id      varchar(255) not null
);

• 위처럼 테이블을 만들어놓고, 미리 unused_short_id 테이블에 short_id를 생성한다.
• String randomShortId = createRandomShortId(); 코드 호출 시, unused_short_id 에서 랜덤으로 하나 가져온 뒤,
• return shortLinkRepository.save(newShortLinkEntity); 될 때 used_short_id에 같이 Insert 하는 트랜잭션 처리 로직으로 만들면 된다.

장점

• shortId 를 생성할 때, 조회하지 않아도 된다.

단점

• DB 용량을 많이 차지할 수 있다. 3~13글자를 사용한다고 하면 너무 용량을 많이 차지함.
  - 62^3 + 62^4 + 62^5 + 62^6 + 62^7 + 62^8 + 62^9 + 62^10 + 62^11 + 62^12 + 62^13 = 조단위

• 좀 더 줄여서 3~7글자만 사용한다고 하면 980GB를 미리 만들어 놓을 수 있음.
  - 62^3 + 62^4 + 62^5 + 62^6 + 62^7 = 140B
  - 7 140B 1bytes = 980GB
  

ShortId 모니터링

• 위 방식을 사용하면 잔여 ShortId를 모니터링 할 수 있다.

  • unused_short_id counts 쿼리도 괜찮은 방법이 될 수 있다.

• 하지만 counts 쿼리를 사용하지 않는다고 해보자. 이 때는 어떻게 해야할까?

  • 아래와 같이 unused_short_id 테이블 데이터의 개수에 대한 테이블을 생성하여 관리한다.(테이블명,변수명은 임의로 막 지었다.)
  • 아래 테이블만 모니터링하면 ShortId 생성에 대한 모니터링을 DB에 큰 부하없이 할 수 있다.
  • 트랜잭션은 return shortLinkRepository.save(newShortLinkEntity); 될 때 unused_short_id에서 used_short_id로 하나가 옮겨지고, unused_short_id_count 테이블의 remaining은 -1이 될 것이다.

create table unused_short_id_count
(
    unused_short_id_count bigint auto_increment
        primary key,
    remaining      bigint not null
);

장점

• 위 테이블만 모니터링하면 ShortId 생성에 대한 모니터링을 DB에 큰 부하없이 할 수 있다.

단점

• write 요청이 빈번해질수록 병목 구간이 unused_short_id_count 이 테이블에서 발생할 수 있다.