-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
1 changed file
with
129 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,129 @@ | ||
| ## **개요** | ||
|
|
||
| 스터디 허브 프로젝트의 성능 개선을 위해 DB 인덱스에 관해 학습하던 중 문득 성능 차이를 눈으로 보고싶다는 생각이 들어 직접 구현하게 되었습니다. | ||
|
|
||
| --- | ||
|
|
||
| ## **프로젝트 설계** | ||
|
|
||
| DB 인덱스 성능 테스트가 목적이기 때문에 설계를 간단하게 구성했습니다. | ||
| <br></br> | ||
|
|
||
|  | ||
| <br></br> | ||
|
|
||
|  | ||
| <br></br> | ||
|
|
||
|  | ||
| <br></br> | ||
|
|
||
|  | ||
| <br></br> | ||
|
|
||
| 데이터 입력은 아래와 같은 로직으로 진행됩니다. | ||
|
|
||
|
|
||
| ~~~ | ||
| 1. 클라이언트가 Post 요청을 보낸다. | ||
| 2. 서버측에서는 이를 받아 랜덤한 문자열을 가지는 UserEntity를 100만개를 생성한다. | ||
| 3. DB에 UserEntity 100만개를 saveAll 메소드를 이용해 저장한다. | ||
| ~~~ | ||
|
|
||
| <br></br> | ||
|
|
||
| --- | ||
|
|
||
| ## **조회 성능 테스트** | ||
|
|
||
|  | ||
|
|
||
| <br></br> | ||
|
|
||
|  | ||
|
|
||
|
|
||
|
|
||
| 성능 테스트는 다음과 같은 방식으로 진행됩니다. | ||
|
|
||
| ~~~ | ||
| 1. 인덱싱하지 않은 상태로 DB에서 name을 조회해 동일한 name이 있을 경우 반환한 뒤 수행 시간을 측정한다. | ||
| 2. 인덱싱한 상태로 DB에서 name을 조회해 동일한 name이 있을 경우 반환한 뒤 수행 시간을 측정한다. | ||
| ~~~ | ||
|
|
||
|
|
||
| ### **인덱스 하기 전** | ||
|
|
||
|  | ||
| <br></br> | ||
|
|
||
|  | ||
|
|
||
| **데이터 100만개를 삽입하기 위한 요청을 보내고 데이터베이스에서 100만개가 삽입된 것을 확인했습니다.** | ||
|
|
||
|  | ||
|
|
||
| **DB 내 삽입된 문자열 중 네개를 선택해 조회해 보겠습니다.** | ||
|
|
||
|  | ||
|  | ||
|  | ||
|  | ||
|
|
||
| <br></br> | ||
|
|
||
| **네개의 응답 속도의 평균을 내보면 94ms로 추산됩니다.** | ||
|
|
||
| ### **인덱스 한 이후** | ||
|
|
||
| **이번엔 DB 인덱싱을 한 뒤 조회해 보겠습니다.** | ||
|  | ||
|  | ||
|
|
||
| 기본으로 생성된 primary_key 에 대한 인덱스 이외에 하나의 인덱스가 더 생성된 것을 확인할 수 있습니다. | ||
|
|
||
| 인덱스 생성이 완료됐으므로 DB 내 삽입된 문자열 중 네개를 선택해 조회해 보겠습니다. | ||
|
|
||
|
|
||
|  | ||
|  | ||
|  | ||
|  | ||
|
|
||
| **WOW! 평균 10ms 로 줄어든 것을 볼 수 있습니다!** | ||
|
|
||
| --- | ||
|
|
||
|
|
||
| ## **삽입 성능 테스트** | ||
|
|
||
| 인덱스는 조회 성능은 개선하지만 인덱스 유지비용 때문에 삽입, 수정, 삭제 성능이 떨어진다는 단점이 있습니다. | ||
| <br></br> | ||
| 조회 성능 테스트에서 했던 방식과 같은 방식으로 데이터 100만개를 삽입한 뒤, 데이터를 1000개만 삽입하는 API를 따로 만들어 인덱스 하기 전과후의 성능을 비교하겠습니다. | ||
|
|
||
| <br></br> | ||
|
|
||
|  | ||
|  | ||
|
|
||
|
|
||
| ## **인덱스 하기 전** | ||
|  | ||
|  | ||
|  | ||
|
|
||
|
|
||
| ## **인덱스 한 이후** | ||
| 1000개의 데이터를 삽입했을 때 인덱스 하기 전에는 평균적으로 300ms 초반, 인덱스 한 이후에는 400ms 초반대로 추산되는 것을 볼 수 있습니다. | ||
|  | ||
|  | ||
|  | ||
|
|
||
|
|
||
|
|
||
|
|
||
| --- | ||
| ## **결론** | ||
| 처음 테스트할 때 데이터를 10만개만 넣고 테스트하니 성능 차이가 미비해 100만개로 늘려 테스트하니 성능 차이가 확실하게 보였습니다. | ||
|
|
||
| 만약 스터디허브에 적용하게 된다면 삽입, 수정, 삭제가 자주 일어나는 StudyPost 보다는 UserEntity에 적용하는 것이 더 좋지 않을까 생각됩니다. (100만명의 유저가 있을까...??) |