[사전과제] URL Shortener

프로젝트 조건

• 웹 페이지 입력폼에 URL 입력 시 단축된 결과 출력
• 브라우저의 주소창에 단축 URL 입력 시 기존 URL로 리다이렉트
• 같은 URL 입력 시 동일한 결과값 도출
• 결과값은 주소를 제외하고 8글자 이내로 생성

 

사용한 기술

Spring Boot, Thymeleaf, MySQL

 

시작하기에 앞서 고민

1) DB를 사용해야하는 이유

url shortener의 원리라고 하면, 원본 URL과 키값을 전단사함수를 통해 일대일 대응하는 것이다.

근데 문득 어짜피 같은 함수로 적용하는데 왜 굳이 키 값을 생성해서 대응...? 하는 생각이 문득 들어서 검색해보았다.

결론적으로 원본 URL보다 더 길어질수 있기 때문이다.

조금만 생각해보면 엄청나게 긴 문자열을 압축해야하는 것인데 단순한 일련번호를 인코딩하는 것이 매우 긴 문자열을 한번에 압축하는 것보다 효율적인 방식이라는 것을 알수있다.

https://stackoverflow.com/questions/4818429/url-shortener-with-no-database

 

2) 데이터베이스 설계

① id 타입: INT vs. BIGINT

trade-off 관계이다. 

INT를 사용하면 적은 양(21억)의 데이터를 저장하는 대신, 적은 범위를 탐색하므로 속도가 비교적 빠르다.

BIGINT를 사용하는 경우, 많은 양(922경)의 데이터를 저장할 수 있지만 데이터가 많아질수록 속도가 비교적 느리다.

현재의 경우에, 스키마가 단순하여(id를 참조하는 다른 테이블이 없음) 추후에 필요시 타입 변환이 어렵지 않다고 판단하였기 때문에 unsigned INT형을 선택하였다.

 

② origin_url 타입: varchar vs. text

파이어폭스, 사파리는 65,536 이상의 URL 길이를 지원한다.

사용하는 MySQL 버전에서 VARCHAR는 최대 65,535길이를 지원하므로 더 큰 데이터 타입인 MEDIUMTEXT(최대 16,777,215 문자 지원)을 선택하였다.

 

3) 인코딩 방식

프로젝트 요구사항을 만족하고(8글자 이내), "+", "/"와 같이 URL-Safe하지 않은 문자는 사용하지 않는 Base62방식을 사용하였다.

 

APIs

API	description
POST /api/shorten	원본 URL을 단축
GET  /	홈 화면 제공
GET  /{shorten}	{shorten}에 해당하는 원본 URL로 리다이렉트

 

소스코드

https://github.com/SuyeonChoi/url-shortener

 

참고자료)

• INT vs. BIGINT
  • MySQL id컬럼 데이터타입 INT? BIGINT? 
  • [stackoverflow] BIGINT mysql performance compared to INT
• VARCHAR vs. TEXT
  • [zetawiki] URL의 최대 길이
  • [MySQL 8.0 Reference Manual] The CHAR and VARCHAR Types
  • mysql text 형 어떤 걸 쓸까? - 쇠똥구리 DBA
• 짧게줄인 URL 알고리즘 고찰