CSV Driver SELECT 요청 개선기

★이 글은 강승훈 님의 의견을 반영해 수정되었습니다.★

단어수 : 391개 읽는 시간: 2분

미리 보기
- CSV 파일로 DB를 구현했다.
- 마지막에 있는 데이터를 찾으려면 모든 데이터를 탐색해야한다.
- 탐색 시간을 최적화 해 1900배 감소시켰다.

개요

WAS 미션 마지막에 CSV 파일을 활용하여 DB 를 만드는 미션이 있었습니다. 당시에 구현할 시간이 별로 없어서 단순하게 파일의 끝에 새로운 데이터를 추가하고 모든 라인을 탐색하면서 파일을 찾도록 구현했습니다. 
 
그러다가 데모하면서 마스터님이 1GB 파일이 있을 때는 어떻게 탐색할 거냐고 물어보셨습니다. 그때 저는 별로 생각을 안하고 있었는데 너무 느릴 거 같다고 생각이 들었습니다.
 

데이터가 많으면 얼마나 성능이 안좋을까?

한 번 제가 구현한 코드로 1억개의 데이터(약 4GB)를 넣고 마지막 레코드를 찾아보았습니다.

개선 전 소요 시간

결과는 약 19초가 걸렸습니다.
이 문제를 조금은 해결해보겠습니다.
 
현대 데이터베이스는 인덱스를 활용해서 문제를 해결하지만 저는 데이터를 id 기반으로 범위를 나눠서 저장하고 불러오는 방식으로 접근해보았습니다. 이러한 방식을 샤딩수평 파티셔닝, 범위 기반의 샤딩이라고 부르는데요. 이렇게 하면 아무리 큰 id 값을 찾는다고해도 모두 비슷한 탐색 시간이 소요됩니다. 
 
샤딩 수평 파티셔닝 크기를 정해서 그 이상의 데이터가 들어오면 다른 csv 파일에 저장하도록 만들었습니다.

각 테이블 별 샤딩의 정보를 가지고 있는 ShardingInfo 객체를 만들어 이를 관리하도록 합니다.
 
CREATE 나 INSERT 연산 시 마지막 id 값을 기록합니다.
이러한 값들을 sharding_info.csv 에 기록하고 메모리 위에도 Map 구조로 가지고 있습니다.
서버 실행 시 sharding_info.csv 에서 값을 읽어와 초기화 해줍니다.
 
저는 1000 개를 기준으로 데이터를 관리하도록 수정했습니다.

 
변경 코드 링크 보기

개선 후 결과

개선 후 1억번째 데이터를 찾는 시간은 10.44 ms 입니다  🥳
이전 방식보다는 확연히 빨라진 모습입니다.

개선 후 소요 시간

그럼에도 단점...

샤딩의 범위에 따라서 성능이 차이가 날 수 밖에 없기 때문에 여러 조건을 맞춰서 설정하는 것이 중요합니다.
그리고 여러 csv 파일을 만들면서 문제가 발생했는데 멀티 스레딩 환경에서 파일을 동시에 접근하는 문제가 발생했습니다.
또한, id 값을 제외한 조건문을 걸면 연산 속도가 이전과 똑같습니다.
 
여러 문제가 남아있지만 다음에 천천히 해결해보겠습니다.. 😰