mongodb와 mysql의 CRUD 연산의 성능 비교

MongoDB와 MySQL의 CRUD 연산의 성능 비교최우영http://blog.wychoe.net

기초 자료 수집데이터가 증가함에 따라 서비스는 필연적으로 저장소의 확장을 요구한다.클라우드 서비스Facebook – 5억명 이상의 가입자Google – 500 PB/MonthFlicker – 500만개 이상의 Geotag/Month

Scale Up의 한계MySQL 연결과 CPU Scale up 벤치마킹연결 16개 이상부터 성능의 향상이 거의 없음CPU Core 16개 이상부터 성능 향상 거의 없음

RDBMS의 확장(1)여러 개의 인스턴스를 생성인스턴스 별로 데이터를 관리하는 파티션 모듈 개발

RDBMS의 확장(2)Replication복제에 의한 확장Master-Slave 구조Write(n), Read(1)Partitioning(Sharding)분할에 의한 확장Join 불가능

NoSQLLightweight RDBMS, `98, Carlo StrozziSQL 인터페이스를 가지지 않는 DBMS 설계Eric Evans에 의해 `09년에 다시 소개ACID를 보장하지 않는 비 관계형, 분산 저장소에 대한 논의비싼 분산 RDBMS와 Join 연산에 대한 제약을 극복하기 위한 대안으로 제시

NoSQL도입 사례FaceBook, Twitter, Digg.comCassandraGoogleBig TableYahooHadoopAmazonDynamo

RDBMS vsNoSQLRDBMSACID 보장Scalability에 대해 느린 성능Scalability에 대해 고비용NoSQLScalability 우선 순위Not Only SQL

CAP 이론(1)Consistency모든 노드가 동일한 데이터를 가진다.Availability노드가 멈춰도 사용할 수 있다.Partition Tolerance물리적 분산 환경에서 동작 가능하다.모든 DBMS는 두 가지특성만을 가진다.Consistency:ACIDTransactionAvailabilityPartition Tolerance:Scale out

MongoDBC-P 조건 만족Document-Oriented storage인덱스 지원복제 & 고 가용성Auto-Sharding쿼리Map/Reduce

주제 선정 이유클라우드 서비스의 등장서비스의 확장성에 대한 고민들SNS, SNG에서의 NoSQL도입 사례 증가DBMS의 확장하기 위한 방법은 무엇이 있을까?기존의 RDBMS를 대체해서 NoSQL을 도입하려면 어떠한 점을 미리 알아야 하는가?

실험 목표RDBMS 제품군과NoSQL제품군간의CRUD 성능 비교RDBMS와 NoSQL의 강점과 약점에 대해서 알아본다.CRUD 연산분산 처리

실험 대상과 범위RDBMSMySQLNoSQLMongoDB

실험 방법동일한 데이터에 대해 CRUD 연산2개 이상의 클라이언트를 연결하여 연산 시도MongoDB는 싱글노드, 멀티 노드를 구분하여 작업

추진 일정~5/18계획 수립~5/25환경 구축, 데이터 가공~6/1MySQL CRUD 실험~6/8MongoDB CRUD 실험보고서 작성

~5/25 일정환경 구축데이터 가공

환경 구축(1)VMWare를 이용해 DBMS 설치머신Windows XP SP3Intel Core2 Dual 2.5Ghz2GB Ram가상 머신Windows XP SP3512 MB RamSingle Core12 GB HDD

환경 구축(2)가상 머신 별 소프트웨어VM-MySQLMySQL 5.5.12 x 1VM-MongoDB Single NodeMongoDB 1.8.1 x 1VM-MongoDB Multi NodeMongoDB 1.8.1 x 3Config Server x 1Router x 1

데이터 가공(1)데이터 원본항공사의 정시 운행률과 지연 원인에 대한 데이터http://www.data.gov/tools/123레코드 수 : 494,401개필드 수 : 93 개데이터 타입 : INT, DATE, TEXT

데이터 가공(3)가공 후 데이터 레코드 수 : 494,401개필드 수 : 93 개 -> 50개각 레코드에 Unique 한 RecordNum필드 삽입

차주 작업MySQL, CRUD 작업소요 시간 체크인덱스, 비인덱스 성능 체크

~6/1 일정MySQL CRUD 성능 측정

데이터 준비42만라인의 데이터각 데이터마다 순차적으로 부여한 번호를 가짐RecordNum필드1 ~ 42만인덱스가 없는 RecordNum에 쿼리를 보내고 측정RecordNum에 인덱스를 걸고 측정

Insert – 예상 소모 시간No Index데이터 수에 선형적으로 증가할 것 이다.Index데이터 수에 비례해 n^2 함수형으로 증가할 것이다.

Insert 결과(no index)1000개 당 로그평균 0.009초 소모(최소 0.001초 최대 0.267초)소요시간

Insert 결과(index)1000개 당 로그평균 0.007초 소모(최소 0.002초 최대 0.302초)소요시간

Insert 결론No index가 Index에 비해 근소하게 빠르다(0.001초)평균적으로는 Index가 빨랐다.No Index 는 소모 시간이 들쭉날쭉 했다.데이터 량이 늘어도 크게 문제가 생길 정도로 성능에 영향을 미치지 않는다.

Select – 예상 소모 시간No Index일정한 속도를 가질 것이다.IndexNo Index보다 빠를 것이다.

Select 결과(no index)100개 검색평균 15.232초 소모(최소 14.798초 최대 15.992초)소요시간

Select 결과(index)100개 검색평균 0.058초 소모(최소 0.029초 최대 0.095초)소요시간

Select 결론Index가 No Index에 비해 월등히 빠르다(14초)

Update – 예상 소모 시간전체적으로 Select와 비슷한 속도를 가질 것이다.No Index일정한 속도를 가질 것이다.IndexNo Index보다 빠를 것이다.

Update 결과(no index)100개 검색평균 46.336초 소모(최소 38.873초 최대 60.660초)트랜잭션 Failed 발생(timeout)소요시간

Update 결과(index)100개 검색평균 0.017초 소모(최소 0.002초 최대 0.072초)소요시간

Update 결론Index가 No Index에 비해 월등히 빠르다(60초)Select 보다 빠르다데이터를 전송하는 시간이 없어서 결과값이 더 빠르게 나타난 것이라 예상트랜잭션 Failed 는 데이터를 기록하며 Lock이 걸린 것으로 예상

Delete – 예상 소모 시간No Index선형적으로 빨라질 것이다IndexNo Index보다 빠를 것이다.

Delete 결과(no index)20개 삭제 시도5개의 클라이언트 모두 트랜잭션 Failed 발생Console에서 수행평균 시간 23.631초, 최소 12.86초 최대 52.83초소요시간

Delete 결과(index)20개 삭제평균 0.058초 소모(최소 0.012초 최대 0.028초)소요시간

Delete 결론Index가 No Index에 비해 월등히 빠르다(22초)동시 접속 시 문제가 발생각자가 Lock을 요구하여 문제가 발생 된 것으로 봄.

차주 작업MongoDB, CRUD 작업소요 시간 체크분산 처리 성능 확인보고서 작성

Insert – 예상 소모 시간Single Node데이터 수에 선형적으로 증가할 것이다.MySQL보다 느릴 것이다.Multi Node데이터 수에 선형적으로 증가할 것이다.Single Node보다 빠를 것이다

Insert 결과(Single Node)1000개 당 로그평균 0.002초 소모(최소 0.0002초 최대 0.087초)MySQL보다 평균 0.005초 빠름소요시간

Insert 결과(Multi Node)1000개 당 로그평균 0.001초 소모(최소 0.0002초 최대 0.099초)Shard Key는 각 레코드마다 고유하게 주어진 필드를 이용했다.Insert에 실패 한 경우가 있었다.소요시간

Insert 결론MongoDB에서의 Insert 연산이 MySQL에 비해 빨랐다.Single Node에 비해 Multi Node가 근소하게 빠름(평균 0.001초)MySQL보다 조금 더 빠른 이유는 ACID를 보장하지 않기 때문인 것으로 추정된다.Multi Node로 사용할 때 가장 빠른 속도를 보이거나 가장 느린 속도를 보인다. 이는 데이터가 분산되어 저장되면서 일어난 현상으로 추정된다.

Select – 예상 소모 시간Single Node일정한 속도를 가질 것이다.MySQL보다 느릴 것이다.Multi NodeSingle Node에 비해 근소하게 느릴 것이다.

Select 결과(Single Node)100개 검색평균 0.0002초 소모(최소 0.0000초 최대 0.004초)소요시간

Select 결과(Multi Node)100개 검색평균 0.0001초 소모(최소 0.0000초 최대 0.004초)소요시간

Select 결론MongoDB가 MySQL에 비해 월등히 빠르다(평균 0.057초)Document로 저장되어서 검색할 때 느릴 것이라 생각했지만 그렇지 않았다.Single, Multi가 크게 차이 나지 않았다.

Update – 예상 소모 시간전체적으로 Select와 비슷한 속도를 가질 것이다.Single Node일정한 속도를 가질 것이다.Multi NodeSingle Node 보다 빠를 것이다.

Update 결과(Single Node)100개 검색평균 0.004초 소모(최소 0.0000초 최대 0.084초)소요시간

Update 결과(Multi Node)100개 검색평균 0.003초 소모(최소 0.0000초 최대 0.068초)소요시간

Update 결론MongoDB가 MySQL에 비해 근소하게 빠르다(0.014초)Multi가 Single에 비해 근소하게 빠르다(0.001초)

Delete – 예상 소모 시간Single Node선형적으로 빨라질 것이다Multi NodeSingle Node 보다 빠를 것이다.

Delete 결과(Single Node)20개 삭제 시도평균 시간 0.00008초, 최소 0.000초 최대 0.00009초

Delete 결과(index)20개 삭제평균 0.0002초 소모(최소 0.000초 최대 0.0002초)

Delete 결론MongoDB가 MySQL에 비해 근소하게 빠르다(0.057초)Single Node가 Multi Node에 비해 빨랐다.

최종 결론(1)MongoDB가 MySQL에 비해 Insert 연산이 근소하게 빠르다.

최종 결론(2)MongoDB가 MySQL에 비해 Select 연산의 속도가 빠르다.

최종 결론(3)최초로 Update 쿼리를 요청할 때 시간이 오래 걸렸다.그 이후 모든 결과가 MongoDB가 빨랐다.

최종 결론(4)Delete 연산은 MongoDB Single이 가장 빨랐고, MySQL이 가장 느렸다.

최종 결론(5)대부분의 성능이 MySQL에 비해 MongoDB가 빨랐다.ACID 보장을 위해 MySQL이 많은 시간을 소모하는 것으로 예상된다.Single Node와 Multi Node 간에 성능 차이는 거의 나지 않지만, Delete 연산을 제외하고는 Multi Node가 조금 더 빨랐다.MySQL은 ODBC를, MongoDB는 C# Driver를 사용하였다. 드라이버의 구현상에서 성능 차이가 발생할 수 있다.

최종 결론(6)MongoDB Multi Node의 Insert 연산 중에 연산 실패가 일어나는 경우가 있었으므로 사용상 주의가 필요하다.MongoDB는 저장 프로시저를 사용할 수 없고 트랜잭션 처리에 경험을 필요로 한다.또, ODBC를 사용할 수 없고 전용 드라이버를 사용해야 하므로 기존의 레거시 프로그램들은 MongoDB로 교체하는데 추가 비용이 청구될 것이다.그러나 분산을 목적으로 한 DBMS를 선택한다면, 기존의 RDBMS에 비해 낮은 비용과 빠른 성능을 제공하는 MongoDB를 선택해도 충분할 것이라 생각된다.

감사합니다Q&Ahttp://www.mongodb.org/

mongodb와 mysql의 CRUD 연산의 성능 비교

Recommended

More Related Content

What's hot (20)

Similar to mongodb와 mysql의 CRUD 연산의 성능 비교 (20)

mongodb와 mysql의 CRUD 연산의 성능 비교