허니몬(Honeymon)의 자바guru

* 발표자 : 주종면

* MongoDB 공식 한국 사용자 그룹 운영자

- 사이트 : http://mongodb-korea.org

* NoSQL 개념

* IT 기술전망 : 클라우드, 빅데이터에서 많은 이야기가 거론됨

* Bic Data 솔루션

- 빅데이터의 수집과 저장기술 오늘의 소개 주제

- NoSQL, MongoDB, Casandra, Hbase

- 빅데이터의 추출과 분산기술

- Hadoop, Storm, Spark, Kafka

- 빅데이터의 분석 및 통계기술

- R, SAS, SPSS

* DBMS for NoSQL : 150여개

- NoSQL 제품군 : 유용성Availability, 일관성Consistency, 파티셔닝Partioning

- Key-Value Database

- Big Table Database

- Document Database

- Graph Database

* NoSQL 제품별 평가결과

- MongoDB : 평가기준에서 전체적으로 좋은 성능의 제품이 나타남

- Community Support 지원

* Data Modeling & 설계 패턴

* MongoDB주요 특징

- Humongos라는 회사의 제품명 

- JSON 타입의 데이터 저장구조를 제공

- CRUD 위주의 다중 트랜잭션 처리가 가능하고 인덱스를 통한 빠른 데이터 검색이 가능

- 분산/병렬처리MapReduce 기능을 제공

- 분산Sharding/복제Replica 기능을 제공

- RDBMS 에서는 대용량의 데이터 처리가 어려워질 수 있다

- Memory Mapping 기술을 기반으로 Big Data 처리에 탁월한 성능 제공

* Collection 생성 : 데이터 저장 가능공간 생성

- 비정형화된 데이터

- db.createCollection("emp", {capped:false, size:8192}); 8k -> 이 공간을 넘어서면 새로운 확장을 하기 위해서 대기상태가 자주 발생하게 된다. 

- db.emp.validate(); Collection의 현재 상태 및 정보분석

* 성능을 개선하기 위해서는 구조에 대한 이해가 필요하다.

* 논리적 구조

- 입력과정에서 생기는 extent의 사이즈에 대한 고려가 필요하군.

* MongoDB 설계 주요 특징

1. MongoDB는 데이터의 중복을 허용하며 비정형화된 설계를 지향한다.

2. MongoDB는 중첩 데이터 구조를 설계할 수 있기 때문에 불필요한 JOIN을 최소화시킬 수 있다.

3. MongoDB는 N:M 관계 구조를 설계할 수 있고 구축할 수 있다.

4. MongoDB는 Schema 중심으로 설계하지 않는다.

* OODBMS vs RDBMS

- Embedded Document

- Extend Document : 먼저 Root Document를 넣고, Root Document에다가 Document 추가

- Linking Document

* 설계패턴

* MongoDB 데이터 저장 구조(Embedded)

- 장점

1. Query가 단순해지고 Join 문을 실행할 필요가 없기 때문에 Document 단위의 데이터 저장에 효과적이며 빠른 성능이 보장된다.

2. 데이터 보안에 효과적이다.

- 단점

1. Embedded 되는 Document의 크기는 최대 10MB  내외

* Manual Linking

- RDBMS : relationship을 통해 제한

- OODBMS : 

- 장점

1. 별도의 논리적 구조로 저장되기 때문에 Document 크기에 제한받지 않는다.

2. 비즈니스룰 상 별도로 처리되는 데이터 구조에 적합하다.

- 단점

1. 매번 논리적 구조간에 Linking해야 하기 때문에 Embedded보다 성능이 늦다.

2. Collection 갯수가 증가하며 관리비용이 많이 든다.

* 만들고자 하는 데이터의 패턴을 고려하여 적합한 설계패턴을 고려해야한다.

- 설계에는 답이 없다.

* Self reference join

* 계층형 데이터 구조

- ANCESTOR, PARENT 를 이용하여 계층혀 데이터 구조 설계 가능

* Inheritence(OODBMS) : 상속 

- 데이터가 저장되는 시점에서 필드와 크기가 저장되기 때문에, 별도로 표현할 필요가 없다.

* MongoDB 성능 튜닝 솔루션

* 적절한 분석을 통해 최적의 컬렉션 구조를 설계하라.

* 빅 데이터의 빠른 검색을 위해 인덱스를 적절히 활용하라.

- 다양한 인덱스 종류

- TTL index : 2.0 에서 추가됨 

- GeoSpatial Index : 좌표정보(위도, 경도, 온도)

* MongoDB의 분산Sharding/복제Replica를 적절히 활용

* Database profiler

- 성능 저하 요소를 찾아 튜닝

* Hint 절과 실행계획

- DB에서 말하는 Hint는 뭐지? +_+)?

* 빅데이터 추출 및 분석

- MongoDB의 Map/Reduce 기능을 이용한 빅데이터 추출

- Javascript function으로 구현

- Aggregation Framework 를 이용해서 기본적인 추출 가능

- MongoDB 와 Hadoop을 연동한 데이터 처리

- Map/Reduce in Python

* Sharding

* MongoDB Architecture

- 좋은 시스템보다는 충분한 메모리 용량이 있을 때 성능만족!

* 정리

이전다음

01234567

    딱, 'DB 전문가'의 느낌이 나는 발표였다. ^^; 몽고DB를 사용할 때 주의해야할 요소요소들을 콕콕 찝어주었다. NoSQL 관련 DB 중에서 가장 높은 선호도와 기술안정성을 가지고 있는 것이 MongoDB기에 많은 사람들이 NoSQL 관련 DB를 고려할 때 우선적으로 떠올리는 DB이기도 하다. 몽고DB 도입시 고려사항들에 대해서 상세히 잘 이야기해주셨다.

    내가 'MongoDB'를 사용하고 경험할 수 있을 때가 언제 오려나~?

• 발표자 : 채수원

테스트주도개발TDD실천법과도구 카테고리 미분류 지은이 채수원 (한빛미디어, 2010년) 상세보기

• Live Coding(발표자가 발표현장에서 직접 소스코드를 작성하면서, 청중의 몰입을 유도하는 효과를 가져온다. 실수를 하면 웃을 수 있는 여유가 필요하다.)

• No pain, No Gains!
• 생산성에 대환 포커스(Ruby on Rails)
• 토비의 스프링3 : 흉기로도 쓸 수 있는 자바 스프링 프레임워크 참고서적!!

토비의스프링3 카테고리 컴퓨터/IT > 프로그래밍/언어 > 프로그래밍일반 지은이 이일민 (에이콘출판, 2010년) 상세보기

• Java Web Frmeworks를 만든 사람들은 Java 개발자가 만들었지, Web Developer가 만든 것이 아니다.
• Productivity focus by Java : Play Framework
• GWT, Rails, Grails, Play!
• Play Framework 가 인기를 끄는 이유?

Scap Folding 기능?

- 우리가 종종 우리에게 적합한 기술이 아니라, 우리가 쓰고 싶은 기술을 사용하기 위해 욕심(Desire)을 부린다. '욕심' 자체는 '악'이 아니지만, 타인을 희생하면서까지 그 욕심을 채우려 할 때 우리는 그것을 '탐욕' 이라고 부른다. 탐욕보다는 배려.

---

  많은 것을 보여주려는 욕심 때문에 시간을 조금 초과하시면서도 많이 아쉬워하셨던 발표였다.
  발표하시는 걸 들을 때마다 느끼는 거지만, 적절하게 던지는 농담과 돌발상황에 유연하게 대처하는 모습에서 연륜(!?)을 느끼게 하는 개발자다.
  지난 KSUG 발표회에서 강연을 듣고 난 이후부터 종종 뵙고 있는데, 그 때마다 새로운 무엇인가를 시도하는 '도전정신'으로 무장한 '여유로움'을 풍기는 개발자다.
  이 강연을 들은 주변의 개발자들이, Play Framework에 대한 관심을 가지기 시작했다. 거기에 나도 포함?