Shine A Light

1. Connection Test

2. SELECT/DELETE/UPDATE/WRITE Performance Test

3. Replica/Shading 구조에서 Master장애 발생시 MongoDB의 동작 방식 및 대응방법

일단 가장 단순하면서도 쉽게 해볼 수 있는 SELECT/DELETE/UPDATE/WRITE Performance Test를 해보려고 했다. 테스트 환경은 RHEL4 32bit의 서버에서 수행하였으며, 실험과정은 아주 단순하게 1,000,000건을 Insert한 후, 차례차례 findOne()메소드를 이용하여 각 Document의 Unique Key를 Query에 추가하여 모두 한건씩 Select한 후, Insert했던 모든 Data를 삭제하는 과정으로 이루어졌다. 실험과정에서 각각 insert, select, delete에 시간이 얼마나 소요되는지 측정하였으며, 이러한 연산과정을 총 10번씩 반복하였다. 먼저 INSERT성능 테스트 코드는 아래와 같다.

위와 같이 INSERT를 수행하면서 mongodb에서 제공하는 모니터링 툴인 mongostat을 이용하여 모니터링한 결과는 아래 그림과 같다.

INSERT의 결과는 비교적 나쁘지 않았다. 초당 평균 5000~6000정도의 qps를 보임으로 인해 실서비스에서도 어느정도 많은 데이터 유입을 감당해 낼 수 있을 것 같았다.

다음은 SELECT연산인데 SELECT 성능 테스트 코드는 아래의 형태와 같다.

이렇게 SELECT하는 동안의 mongostat의 모니터링 결과는 아래와 같다.

이러한 문제를 해결해보고자 다시 데이터를 다 삭제한 후, 데이터를 INSERT하기 전에 먼저 id컬럼에 Index를 생성한 뒤 다시 INSERT와 SELECT를 위와 동일한 코드로 실험을 실행해 보았고 그 결과는 아래와 같다.

Insert with Index

실험결과를 보았을때 Index를 걸어줬을때가 그렇지 않은 경우보다 더 높은 qps를 보여주는 것을 알 수 있었다. 아주 비약적인 속도의 성장세를 보여준 것은 아니지만 약 5000~6000대에서 7000~75000정도로 상승된 qps를 보여주는 것만으로도 충분히 만족스러웠다.

Select with Index

역시 Index를 걸어주기 전보다 더 나은 성능을 보여주고 있는 것을 알 수 있었다. 하지만 역시나 원체 느린 qps를 보여주고 있었기에 더 나은 성능을 보인다 하더라도 너무 느린 결과를 보여주고 있었다. File Base의 특징상 Disk의 I/O 속도에도 굉장히 영향을 많이 받을 것이고, 또한 이러한 실험이 애초에 접근방식이 잘못된 것일 수도 있기때문에 뭐라 단정짓긴 힘들지만, (실제로 회사내 다른 팀에서 고성능 서버에서 테스트한 64비트 mongodb에서는 1,000,000건을 SELECT하는데 약 12초가 안걸리는 실험 결과를 얻기도 했다) 어쨌던 SELECT 연산은 NoSQL의 명성에 안맞게 생각보다 너무 조악했다.

마지막으로 Index가 걸린 상태에서 DELETE연산을 수행하였으며 그 코드는 아래와 같다.

DELETE하는 동안의 mongostat을 이용한 모니터링 결과는 아래와 같다.

DELETE하는 동안 qps는 오히려 INSERT보다 더 나은 수치를 보였으며 거의 INSERT와 비슷한 만족스런 성능을 보여주고 있었다. 아마 index를 걸지 않고 DELETE를 했었어도 INSERT때와 마찬가지로 큰 성능의 저하는 없었을 것 같다.

이러한 실험이 10번 반복되는 동안 각각의 연산 수행시간 기록은 아래와 같다.

이러한 실험결과는 처음에도 말했던 것과 같이 매우 rough한 실험이었으며 그 실험과정이나 조건들이 100% 정확한 상태에서 혹은 적합한 상태인지 모르는 상황에서 수행한 것으로 100%신뢰하기에는 어려움이 있을 것 같다. 하지만 전반적인 추정은 가능할 것으로 보이며, 특히 SELECT의 경우에는 좀 더 다양한 조건에서 여러번 실험을 더욱 수행해볼 필요는 있을 것 같다. 테스트에 사용한 코드를 첨부하니 직접 테스트하길 원하시는 분들은 받아서 해보시길..

test.java