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

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

1 최우영 http://blog.wychoe.net

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

3 Scalability

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

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

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

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

8 NoSQL 도입 사례 FaceBook, Twitter, Digg.com Cassandra Google Big Table Yahoo Hadoop Amazon Dynamo

9 RDBMS vs NoSQL RDBMS ACID 보장 Scalability 에 대해 느린 성능 Scalability 에 대해 고비용 NoSQL Scalability 우선 순위 Not Only SQL

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

11 CAP 이론 (2)

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

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

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

15 실험 대상과 범위 RDBMS MySQL NoSQL MongoDB

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

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

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

19 환경 구축 (1) VMWare 를 이용해 DBMS 설치 머신 Windows XP SP3 Intel Core2 Dual 2.5Ghz 2GB Ram 가상 머신 Windows XP SP3 512 MB Ram Single Core 12 GB HDD

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

21 환경 구축 (3)

22 환경 구축 (4)

23 환경 구축 (5)

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

25 데이터 가공 (2)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

69 감사합니다 Q&A http://www.mongodb.org/