MongoDB Index Performance

최근 회사 일로 스토리지를 하나 선정 할 일이 있어서… MongoDB를 해 보기로 했다. MongoDB의 스키마를 설계 하는 방법은 몇가지 있겠지만, 그 중에 대표적으로 2개의 결과만을 정리한다.

HW 스펙은 그냥 흔한 4Core VM 이라고 보면 된다. 그리 고스펙으로 테스트 하지는 않았다. 그리고 MongoDB는 이 글이 쓰인 시점의 최신 버전이다. 모든 Request 는 1000 Thread 로 분산하여 요청하였다.

첫번째로 Schema Less RDB 처럼 쓰는 방법이다. 일단 랜덤으로 생성된 천만개의 데이터를 넣었는데, Insert는 충분히 빨라서 궂이 언급할 필요는 없겠다. 필요한 하나의 Field 에만 Index를 걸고 최신 10만개의 데이터를 가져오도록 해 보았다.

… 경악할만큼 느린 퍼포먼스를 보여준다 10만개를 가져오는데 2.5분, 1만개를 가져오는데 8초라는 어처구니 없는 속도를 보여준다. 혹시 내가 생성한 인덱스에 문제가 있나 해서 기본으로 생성되는 _id 값을 기준으로 가져와 보았지만 정확히 같은 퍼포먼스를 보여준다 일단 Index를 기준으로 정렬하여 상위 몇개를 가져오는(Ex: SELECT * FROM Table ORDER BY ID DESC) RDB 에서 흔히 쓰이는 방식의 스토리지에 MongoDB는 전혀 맞지 않다고 볼 수 있다.

두번째로 Unique Index 를 가지고 Upsert 기능을 활용하여 Schema 내부의 Array에 계속 Push 를 하는 형태의 구성을 해 보았다. 이 경우 Index로 단 하나의 값에 즉시 접근이 되기 때문에, RDB에서 생각하던 성능의 Index와 같은 느낌으로 쓸 수 있다. 값을 가져오는건 거의 즉시에 가까워서 별로 얘기할 거리가 없고, Insert 속도는 초당 400개 정도를 처리할 수 있었다. 이정도면 대부분의 서비스에서 유용하게 쓰일 수 있을 것 같다. Insert 속도가 모자라다면 Node를 늘리는 것으로 해결 할 수 있을테니 저스펙의 VM에서 Write가 초당 400이면 충분해 보인다.

나중에 시간이 나면 같은 스펙으로 MongoDB와 mysql, mssql 의 Json Query의 성능을 비교 해 보고 싶다.

그리고 이건 명확하게 테스트 해 본건 아니지만… Schema Less 와 Auto Shading 을 제외하면 RDB보다 (고오급 DB랑 비교하는건 좀 미안하니 mysql 이랑 비교해도) 전반적인 퍼포먼스가 많이 떨어진다. 간단히 쓸 수 있는 가벼운 DB라고 쓰기엔 생각보다 느리다.