2014 SAP 솔루션 업데이트 · 2014-04-23 · 나아진 Open SQL과 새로운 ABAP의 계산로직뷰 제공. SAP HANA의 표준기능으로 내장된 서치기능, 향상된
MongoDB DB 설계 패턴 및 성능 튜닝 솔루션 주 종 면
58
MongoDB DB 설계 패턴 및 성능 튜닝 솔루션 주 종 면 www.pitmongo.co.kr 010-3864-1858
Transcript of MongoDB DB 설계 패턴 및 성능 튜닝 솔루션 주 종 면
MongoDB
DB 설계 패턴 및 성능 튜닝 솔루션
주 종 면 www.pitmongo.co.kr
010-3864-1858
. MongoDB 공식 한국 사용자 그룹 운영자 - www.mongodb-korea.org - 현재 회원 수 약 1,530 명 - 초/중급 스터디 그룹 및 심화 스터디 그룹 운영 중 - 10gen co. 엔지니어 초빙 기술 컨퍼런스 개최
. ㈜ PLAN 정보기술 / 대표 컨설턴트 - 한국 데이터베이스 진흥원 기술 위원 및 겸임 교수 - 한국 SW 기술협회 겸임 강사 - MongoDB Master 공인 전문가 - Oracle ACE 공인 전문가 - DB 설계/튜닝/컨설팅
. 미국 10gen co. 한국 공식 파트너(Training ) - MongoDB 개발자 과정 및 DBA 과정 운영 - MongoDB 개발 및 모니터링 국산 툴 개발 중(올챙이 툴)
발표자 : 주 종 면
1장. NoSQL 개념
2장. Data Modeling & 설계 Pattern
3장. MongoDB 성능 튜닝 솔루션
- 목 차 -
NoSQL 개념
1
IT 분야 10대 키워드
2011년 10대 키워드
커머셜 클라우드
컨슈머 클라우드& N 스크인 UX
비즈니스 플랫폼 NS
스마트 워크
상황인식 컴퓨팅
보안/프라이버시 360
마켓플레이스 에코시스템
비즈니스 분석기술
멀티플랫폼으로의 웹표준
응용 프로그램 수명 주기관리
2013년 10대 키워드
빅 데이터 도입&활용
신종 보안 위협
스마트 홈&가전 서비스
특허&지재권 중요도
클라우드 컴퓨팅 확산
HTML5 도입
소셜 미디어&엔터프라이즈
차세대 반도체&디스플레이
콘텐츠 서비스
신정부의 IT 정책
*출처:한국 정보화 진흥원 동향분석시리즈 참조
2012년 10대 키워드
정보 보호 및 보안
클라우드 서비스
소셜 네트워크 서비스
모바일 애플리케이션
위치기반 서비스
스마트 워크
소셜 비지니스
오픈 플랫폼
빅 데이터
스마트 디바이스
*출처:한국 정보화 진흥원 동향분석시리즈 참조
NoSQL MongoDB Casandra Hbase
Hadoop Storm Spark Kafka
R SAS SPSS
Big Data 솔루션
…
…
…
빅 데이터의 수집과 저장 기술
빅 데이터의 추출과 분산 기술 빅 데이터의 분석 및 통계기술
DBMS for NoSQL
NoSQL 제품군
1. Key-Value Database 1) Amazon’s Dynamo Paper 2) Data Model : Collection of K-V pairs 3) 제품유형 : Riak, Voldemort, Tokyo*
3. Document Database 1) Lotus Notes 2) Data Model : Collection of K-V collection 3) 제품유형 : Mongo DB, Cough DB
2. BigTable Database 1) Google’s BigTable paper 2) Data Model : Column Families 3) 제품유형 : Hbase, Casandra, Hypertable
4. Graph Database 1) Euler & Graph Theory 2) Data Model : nodes, rels, K-V on both 3) 제품유형 : AllegroGraph, Sones
* Availablity(유용성), Consistency(일관성), Partitioning(파티션닝)에 따른 제품군 구분
NoSQL 관련 직무 동향
참조자료 : indeed.com
MongoDB Job 동향
* 2012년 6월 indeed.com 통계
NoSQL 제품별 평가 결과 평가 기준 Tokyo*Cabinet *
Tokyo Tyrant Berkerly DB
Memcache DB Voldemort
BDB JE REDIS MongoDB
Write (Small Data Set)
Write (Large Data Set)
Random Read (Small Data Set)
Random Read (Large Data Set)
Speed 일관성
Storage 효율성
Horizontal 확장성
Manageability (관리성)
Stability (안정성)
Community Support
* 2011년 PerfectMarket 자료 참조
Data Modeling & 설계 Pattern 2
MongoDB 주요 특징
1) Humongos라는 회사의 제품 명이었으며 현재 10gen으로 회사명이 변경되었다.
2) JSON Type의 데이터 저장 구조를 제공한다. { ename : “주종면” }
3) CRUD(Create, Read, Update, Delete) 위주의 다중 트랜잭션 처리도 가능하며 인덱스를 빠른 데이터 검색이 가능하다.
4) MapReduce(분산/병렬처리) 기능을 제공한다.
5) Sharding(분산)/Replica(복제) 기능을 제공한다.
6) Memory Mapping 기술을 기반으로 Big Data 처리에 탁월한 성능 을 제공한다.
Collection 생성 > db.createCollection (“emp”, { capped : false, size:8192 }); { "ok" : 1 } capped : 해당 공간이 모두 사용되면 다시 처음부터 재 사용할 수 있는 데이터 구조를 생성할 때 size : 해당 Collection의 최초 생성 크기 지정 가능 > db.emp.validate() Collection의 현재 상태 및 정보 분석 { "ns" : "test.emp", "firstExtent" : "0:61000 ns:test.emp", "lastExtent" : "0:61000 ns:test.emp", "extentCount" : 1, "datasize" : 0, "nrecords" : 0, "lastExtentSize" : 8192,
논리적 구조
Emp Collection
Database
(Ex) db.createCollection
(“emp", {capped:false, size:100000});
Data Record
Length
xNext
xPrev
Document { _id:“1”, …. }
Data Record
Length
xNext
xPrev
Document { _id:“2”, …. }
Data Record
Length
xNext
xPrev
Document { _id:”3”, …. }
Data Record
Length
xNext
xPrev
Document { _id:“4”, …. }
Data Record
Length
xNext
xPrev
Document { _id:“5”, …. }
Data Record
Length
xNext
xPrev
Document { _id:“6”, …. }
Extent Extent Collection
Data Record
MongoDB 설계 주요 특징
1) MongoDB는 데이터의 중복을 허용하며 비정형화된
설계를 지향한다.
2) MongoDB는 중첩 데이터 구조를 설계 할 수 있기 때문에
불필요한 JOIN을 최소화 시킬 수 있다.
3) MongoDB는 N:M 관계 구조를 설계할 수 있고 구축할 수
있다.
4) MongoDB는 Schema 중심으로 설계하지 않는다.
OODBMS & RDBMS
주 문 주문 항목 ♦
강한 관계 (Strong Association)
부 서 사 원 ◇
약한 관계 (Weak Association)
주 문 주문 항목
부 서 사 원
관계 (Relationship)
Object Oriented Database Relationship Database
주 문 전 표
주문번호
고객명 Womansport ㈜
주문날짜 2012-09-20 선적날짜 2012-09-20
2012-09-012345 Magee 담당사원
주문 총금액 601,100 지불방법 현금 30일 이내
항목번호 제 품 명 단 가 주문수량 금 액
1 Bunny Boot 135 500 67,500 2 Pro Ski Boot 380 400 152,000 3 Bunny Ski Pole 14 500 7,000
4 Pro Ski Pole 36 400 14,400
5 Himalaya Bicycle 582 600 349,200
6 New Air Pump 20 450 9,000
SUMMIT2 ㈜
7 Prostar 10Pd.Weight 8 250 2,000
선적여부 Y
Insert into s_ord ( ord_id, customer_no, emp_name, total, payment_type, order_filled) Values ( “2012-09-012345”, "Wonman & Sports", "Magee", 601100, “Credit”, “Y”); Insert into s_ord_item ( ord_id, item_id, product_name, price) Values ( “2012-09-012345”,“1”, “Bunny Boots“, 135, 500, 67000 ); Insert into s_ord_item ( ord_id, item_id, product_name, price) Values ( “2012-09-012345”,“2”, “Pro Ski Boots“, 380, 400, 152000 );
주문 테이블 정보
주문 상세 테이블 정보
RDBMS SQL
2012-09-012345, Wonman & Sports, Magee,601100, Credit,Y ……………. ……………..
주문
2012-09-012346, Man & Sports, Magee,34200, Credit,N ……………. ……………..
2012-09-012347, Adidas, Magee,23100, Credit,Y ……………. ……………..
2012-09-012348, Soleman, Magee,43100, Credit,N ……………. ……………..
2012-09-012345, 1,Bunny Boots, 135 , 500, 67000
주문상세
2012-09-012345, 2,Pro Ski Boots, 380 ,400, 152000
RDBMS 논리적 구조 Extent Block(Page) Table
201209012345 …….
주문 테이블
1, “Bunny Boots”, 135, 500,67000
2, “Pro Ski Boots”, 380,400,152000
3, ……………………….
4, ……………………….
201209012346 ……. 1, …………………………………
2, …………………………………
3, …………………………………
4, …………………………………
5, …………………………………
Create table order (order_no char(12), ename varchar2(10), ………………………………. order_content order_detail) Nested Table order_content;
Create type product_detail as object (item_no number(2), p_name varchar(50), s_price number(8), qty number(5), amount number(10)); Create type order_detail As Table of product_detail;
1
2
3
ORDBMS (Nested Table)
ORDBMS (Varray)
201209012345 …….
주문 테이블
1, “Bunny Boots”, 135, 500,67000
2, “Pro Ski Boots”, 380,400,152000
3, ……………………….
4, ……………………….
201209012346 ……. 1, …………………………………
2, …………………………………
3, …………………………………
4, …………………………………
5, …………………………………
Create table order (order_no char(12), ename varchar2(10), ………………………………. order_content order_detail) VARRAY order_content;
Create type product_detail as object (item_no number(2), p_name varchar(50), s_price number(8), qty number(5), amount number(10)); Create type order_detail As varray(90) of product_detail;
1
2
3
db.ord.insert( { ord_id : "2012-09-012345", customer_name : "Wonman & Sports", emp_name : "Magee", total : "601100", payment_type : "Credit", order_filled : "Y", item_id : [ { item_id : "1", product_name : "Bunny Boots", item_price : "135", qty : "500", price : "67000“ }, { item_id : "2", product_name : "Pro Ski Boots", item_price : "380", qty : "400", price : "152000“ } ] } )
주문 상세 정보
Embedded Document
주문 공통 정보
db.ord.insert( { ord_id : "2012-09-012345", customer_name : "Wonman & Sports", emp_name : "Magee", total : "601100", payment_type : "Credit", order_filled : "Y" }); db.ord.update( { ord_id : "2012-09-012345"}, { $set : { item_id : [ { item_no : "1", product_name : "Bunny Boots", item_price : "135", qty : "500", price : "67000" }, { item_no : "2", product_name : "Pro Ski Boots", item_price : "380", qty : "400", price : "152000" } ] } } );
Extend Document
주문 상세 정보
주문 공통 정보
Data Record
Length
xNext
xPrev
Document {({ ord_id :“2012-09-012345", customer_name : "Wonman & Sports", emp_name : "Magee", total :“601100”, payment_type :“Credit”, order_filled :“Y”, item_id : [ { item_id :“1”, product_name :“Bunny Boots”, item_price :“135” qty :“500”, price :“67000”}, { item_id :“2”, product_name :“Pro Ski Boots”, item_price :“380”, qty :“400”, price :“152000” } ] }}
주문/주문상세 Collection
MongoDB 데이터 저장 구조 (Embedded)
* 장점 1) Query가 단순해지고 JOIN문을 실행할 필요가 없기 때문에 Document 단위의 데이터 저장에 효과적이며 빠른 성능이 보장된다.
2) 데이터 보안에 효과적이다.
* 단점 1) Embedded 되는 Document의 크기는 최대 16MB 범위에서 가능하다.
2) Embedded 되는 Document가 존재하지 않는 Collection에는 적합하지 않다.
> db.ord.insert( { ord_id : "2012-09-012345", customer_name : "Wonman & Sports", emp_name : "Magee", total : "601100", payment_type : "Credit", order_filled : “Y“ } ) > o = db.ord.findone( { "ord_id" : "2012-09-012345" } ) { "_id" : ObjectId("4fc21223e6cd4d2aadb38622"), ………………………………. > db.ord_detail.insert( { ord_id : "2012-09-012345", item_id : [ { item_id : "1", product_name : "Bunny Boots", item_price : "135", qty : "500", price : “67000“ }, { item_id : "2", product_name : "Pro Ski Boots", item_price : "380", qty : "400", price : "152000“ } ], ordid_id : ObjectId("4fc21223e6cd4d2aadb38622“) } ) > db.ord_detail.findOne({ordid_id : o._id})
주문 공통 정보
주문 상세 정보
Manual Linking
> x = { ord_id : "2012-09-012345", customer_name : "Wonman & Sports", emp_name : "Magee", total : "601100", payment_type : "Credit", order_filled : "Y" } db.ord.save(x)
> db.ord.find({"ord_id" : "2012-09-012345"}) { "_id" : ObjectId("4fc30d0efab534f9e9253477"), ………………………………………… > db.ord_detail.save({ ord_id : "2012-09-012345", item_id : [ { item_id : "1", product_name : "Bunny Boots", item_price : "135", qty : "500", price : "67000" }, { item_id : "2", product_name : "Pro Ski Boots", item_price : "380", qty : "400", price : "152000" } ], ordid_id : [ new DBRef ("ord", x._id) ] } )
주문 공통 정보
주문 상세 정보
DBRef 함수
Data Record
Length
xNext
xPrev
Document {( ObjectId("4fc21223e6cd4d2aadb38622") ord_id : “2012-09-012345”, customer_name : "Wonman & Sports", emp_name : "Magee", total : “601100”, payment_type : “Credit”, order_filled : “Y” }}
주문 Collection Data Record
Length
xNext
xPrev
Document {({ ObjectId("4fc21417e6cd4d2aadb38624") ord_id : “2012-09-012345”, item_id : [ { tem_id : “1”, product_name : “Bunny Boots”, item_price : “135”, qty : “500”, price : “67000” }, { item_id : “2”, product_name : “Pro Ski Boots”, item_price : “380” qty : “400”, price : “152000” }, ObjectId("4fc21223e6cd4d2aadb38622") }}
주문 상세 Collection
MongoDB 데이터 저장 구조 (Linking)
* 장점 1) 별도의 논리적 구조로 저장되기 때문에 Docum ent 크기에 제한 받지 않는다. 2) 비니지스 룰 상 별도로 처리되는 데이터 구조에 적합하다.
* 단점 1) 매번 논리적 구조 간에 Linking 해야 하기 때문에 Embedded 보다 성능이 늦다. 2) Collection 개수가 증가하며 관리 비용이 많이 든다.
계층형 데이터 구조
KING
CLARK JONES BLAKE
MILLER SCOTT FORD ALLEN WARD MARTIN TURNER JAMES
ADAMS SMITH
Empno=7839
Empno=7782
Empno=7934
Empno ename mgr
------------------------------------------------- 7839 KING
7698 BLAKE 7839 7782 CLARK 7839 7566 JONES 7839 7654 MARTIN 7698 …………………………………………. 7902 FORD 7566 …………………………………………. 7876 ADAMS 7788 7934 MILLER 7782
SELECT a.empno, a.ename, a.mgr, b.ename FROM emp a, emp b WHERE a.mgr = b.empno
Self Reference Join (RDBMS)
b.Ename ---------------- KING KING KING BLAKE ………. JONES ………. JIMMY CLARK
> db.emp.insert({ "_id" : "7839", "name" : "KING", "job" : "PRESIDENT" }) > db.emp.insert({ "_id" : "7782", "name" : "CLARK", "job" : "ANALYSIST", "PARENT" : "7839" } ) > db.emp.insert({ "_id" : "7934", "name" : "MILLER", "job" : "CLERK", "ANCESTORS" : “7839” , "PARENT" : "7782" } ) > db.emp.find({"ANCESTORS" : "7839"}) { "_id" : "7934", "name" : "MILLER", "job" : "CLERK", "ANCESTORS" : [ "7939", "7782" ], "PARENT" : "7782" } > db.emp.find({"PARENT" : “7839"}) { "_id" : "7782", "name" : "CLARK", "job" : "ANALYSIST", "PARENT" : "7839" }
Ancestor Reference (MongoDB)
Inheritence (OODBMS)
상속(Inheritance)
CAR
BUS TAXI
Engine Frame Tire
Engine Frame Tire Auto-Door
Engine Frame Tire Lamp Gas_Tank
CREATE TYPE car AS OBJECT (engine NUMBER(9) Primary Key, frame VARCHAR(30), tire VARCHAR(30)) NOT FINAL; CREATE TYPE bus UNDER car_typ (auto_door VARCHAR(30) FINAL; CREATE TYPE taxi UNDER car_typ (lamp VARCHAR(30), gas_tank VARCHAR(30) FINAL;
Inheritence (RDBMS) CAR Engine Frame Tire Car_Type
CREATE TABLE car (engine INTEGER(9) NOT NULL, frame CHAR VARYING(30) NOT NULL, tire CHAR VARYING(30) NOT NULL, car_type CHAR VARYING(4) CHECK IN(’BUS’,‘TAXI’), auto_door INTEGER(2), lamp CHAR VARYING(30), gas_tank CHAR VARYING(30) Constraint bus_pk PRIMARY KEY (engine, frame, tire);
BUS Auto_door
TAXI Lamp Gas_tank
Engine Frame Tire Car_Type Auto_Door Lamp Gas_Tank
A AX_1 R16 TAXI 1 1
B AK_3 R18 BUS 2
A AX_2 R18 TAXI 2 2
Inheritence (MongoDB) > db.createCollection (“car”); > db.car.insert({ engine : “A”, frame : “AX_1“, tire : “R16”, car_type : “TAXI”, lamp : 1, gas_tank : 1 }); > db.car.insert({ engine : “B”, frame : “AK_3“, tire : “R18”, car_type : “BUS”, auto_door: 2 }); > db.car.insert({ engine : “A”, frame : “AX_2“, tire : “R18”, car_type : “TAXI”, lamp : 2, gas_tank : 2 }); > db.employees.find(); {"_id" : ObjectId("4f00574f81a153d6857897d2"), “engine" : “A”, "ename" : “AX_1“, “tire” : “R16”, “car_type” : “TAXI”, “lamp” : 1, “gas_tank” : 1 }); }
Engine: A
Frame: AX_1
Tire: R16
Car_type: TAXI
Lamp: 1
Gas_tank: 1
Engine: B
Frame: AK_3
Tire: R18
Car_type:BUS
Auto_door: 1
Engine: A
Frame: AX_1
Tire: R18
Car_type: TAXI
Lamp: 2
Gas_tank:2
제 품
N:M 관계(RDBMS)
카테고리
ASUS EP121
Samsung eSlate 7
iPad 3
Note Book
Slate PC
Tablet
db.category.insert({"cname" : "Note Book", "pname1" : "Asus EP121 M50" } ); db.category.insert({"cname" : "Tablet", "pname1" : "Asus EP121 M50", "pname2" : "iPad3"} ); db.category.insert({"cname" : "SlatePC", "pname1" : "Asus EP121 M50", "pname2" : "Samsung Slate 7" }); db.product.insert({ "pname" : "Asus EP121 M50", "cname1" : "Note Book", "cname2" : "Tablet", "cname3" : "SlatePC" } ); db.product.insert({ "pname" : "Samsung Slate 7", "cname1" : "SlatePC" } ); db.product.insert({ "pname" : "iPad3", "cname1" : "Tablet" } );
N:M 관계 (MongoDB)
MongoDB 성능 튜닝 솔루션 3
성능 튜닝 솔루션
2) 빅 데이터의 빠른 검색을 위해 인덱스를 적절히 활용하라.
( Hint 함수와 Explain 함수를 이용한 실행계획 적용)
1) 적절한 분석을 통해 최적의 컬렉션 구조를 설계하라.
(Rich Document, Linking, Extent 크기 등)
5) MongoDB는 메모리 매핑을 이용한 데이터 처리 기술을 사용
하기 때문에 충분한 메모리 영역을 확보하라.
4) MongoDB의 대표적 분산 처리 솔루션인 Sharding 시스템의
적용을 충분히 고려하라
3) MongoDB의 Map/Reduce 또는 Aggregation 기능을 적절히
활용하고 Hadoop과 연동을 통한 Map/Reduce도 고려하라.
Non-Unique/Unique Index
Background Index
Sparse Index
Covered Index
DropDups Index
TTL Index
GeoSpatial Index
INDEX 종류
Database Profiler 1) Profiler 환경 설정 > db.setProfilingLevel(2); {"was" : 0 , "slowms" : 100, "ok" : 1} "was" 는 이전 설정 정보 > db.getProfilingLevel() 현재 설정되어 있는 정보 2 0 : Off, 1 : default > 100 ms 2 : System에서 발생한 모든 정보
> db.system.profile.find( { millis : { $gt : 5 } } ) 실행 시간이 5초 이상 소요된 문장 검색
2) Profiler 환경 분석 결과 및 상태 확인
3) Hint절과 실행 계획 > db.emp.find({eno : 1101}).hint({eno:1}).explain(); { "cursor" : "BtreeCursor eno_1", Index Scan "nscanned" : 1, 검색 조건을 만족하는 항목 수 "nscannedObjects" : 1, 검색 대상이 된 Collection 수 "n" : 1, 조건을 만족하는 Document 수 "millis" : 0, 조건을 검색하는데 소요된 시간 "nYields" : 0, Read Lock이 발생했던 횟수 "nChunkSkips" : 0, Shard에서 Chunk Migration된 Doc. 수 "isMultiKey" : false, 다중 key 인덱스가 사용되면 True "indexOnly" : false, Index 만 사용하여 Query했으면 True "indexBounds" : { "eno" : [ [ 1101, 1101 ] ] } }
> db.emp.find().hint({$natural:1}).explain(); { "cursor" : "BasicCursor", Full Collection Scan "nscanned" : 3, "nscannedObjects" : 3, "millis" : 0, …………… "indexOnly" : false, "indexBounds" : { } }
> db.employees.find ({ deptno : 10, ename : "CLARK" }).explain() { "cursor" : "BtreeCursor deptno_1_ename_1", "nscanned" : 1, "nscannedObjects" : 1, "n" : 1, "millis" : 0, "nYields" : 0, "nChunkSkips" : 0, "isMultiKey" : false, "indexOnly" : true, Covered 인덱스 만으로 조건 검색 "indexBounds" : { "deptno" : [ [ 10, 10 ] ], "ename" : [ [ "CLARK", "CLARK" ] ] } }
> db.employees.ensureIndex({ comm : 1 }, { sparse : true }) > db.employees.find().sort({comm : -1}) { "_id" : ObjectId("5019dd5b2bffb7e0a9073be7"), "empno" : 7654, "deptno" : 30 } { "_id" : ObjectId("5019dd5b2bffb7e0a9073be5"), "empno" : 7521, “deptno" : 30 } { "_id" : ObjectId("5019dd5b2bffb7e0a9073be4"), "empno" : 7499, "deptno" : 30 } > db.employees.dropIndex({ comm : 1 }) > db.employees.find().sort({comm : -1}) SPARSE 인덱스 삭제 후 전체 검색을 수행하면 모든 Document들이 출력된다. {"_id":ObjectId("5019dd5b2bffb7e0a9073be7"),"empno" : 7654, , "deptno" : 30 } {"_id":ObjectId("5019dd5b2bffb7e0a9073be5"), "empno" : 7521, "deptno" : 30 } ………………………………………………………………………………………………….. {"_id":ObjectId("5019dd5c2bffb7e0a9073bef"), "empno" : 7902, , "deptno" : 10 }
빅데이터 추출 및 분석
1) MongoDB의 Map/Reduce 기능을 이용한
빅 데이터의 추출
3) MongoDB와 Hadoop의 Map-Reduce를 연동
한 빅 데이터의 추출
2) MongoDB의 Aggregation Framework을 이용
한 빅 데이터의 추출
1) MongoDB Map/Reduce 기능을 이용
MongoDB
Map()
emit()
Group()
sort()
Reduce(k, v) Finalize()
db.result1.find( { "value.mmin”: { $gt:0}}).sort({ "value.recs”: 1});
Oracle & Mongo Query 비교 SELECT deptno, job, SUM(sal) AS msum, <- 부서별 급여합계 COUNT(*) AS recs, <- 부서별 인원수
AVG(sal) AS mavg, <- 평균급여금액
MIN(sal) AS mmin, <- 최소급여액
MAX(CASE <- 최대급여액
WHEN sal > 1000 THEN sal END) AS mmax FROM emp WHERE (hiredate > ‘01-01-1981' AND hiredate < ‘31-12-1983') AND sal > 800 GROUP BY deptno, job HAVING min(sal) > 0 ORDER BY recs DESC
db.runCommand ({ mapreduce: "emp", query: { hiredate : { $gt : '01-01-1981', $lt : '31-12-1983' }, sal : { $gt : 800 } }, map: function() { emit( { d1 : this.deptno, d2 : this.job }, { msum: this.sal, recs: 1, mmin: this.sal, mmax: this.sal > 1000 } ); }, reduce: function(key, vals) { var ret = { msum:0, recs:0, mmin:0, mmax:0 }; for (var i=0 ; i < vals.length; i++) { ret.msum += vals[i].msum; ret.recs += vals[i].recs; if (vals[i].mmin < ret.mmin) ret.mmin=vals[i].mmin; if (vals[i].mmax > 1000) ret.mmax=vals[i].mmax; } return ret; }, finalize: function(key, val) { val.mavg=val.msum/val.recs; return val; }, out: "result1", verbose: true });
대상 Table과 Collection 검색 조건 검색 Column 또는 Field Aggregate 또는 Procedure Logic Aggregate 또는 Procedure Logic Aggregate Filter 또는 Sorting
2) Aggregation Framework을 이용한 데이터 처리
- Aggregation을 위해 MongoDB의 Map/Reduce를
반드시 사용해야 한다.
- Aggregation Framework는 데이터 추출에 최적화
되어 만들어진 기능이다.
- 실시간 Aggregation은 SQL의 Group By절과 유사하다.
- MongoDB Map/Reduce는 JavaScript로 생성되어 있다.
- JavaScript는 외부 데이터 처리에 제한적이다.
(1) Aggregation Framework
3) MongoDB와 Hadoop을 연동한 데이터 처리
MongoDB
Map(k,v,ctx)
Partitioner(k) sort(keys)
Reduce(k, v) MongoDB
combine(k,v) Split Data
Split Data
Split Data
Input Split Data
(1) Map Function in Python
(2) Reduce Function in Python
(3) Run in Hadoop Map/Reduce
(4) Map/Reduce 결과
Sharding System
Mongo.exe Mongo.exe
Route Server (MongoS)
Mongod Mongod Mongod
Mongod
Shard Server
Config Server
MongoDB Architecture
Mapped Cache Area Journal Area Resident Area
(Working Set) Virtual Area
SALES. NS (16MB)
SALES.0 (64MB)
Prealloc.0 (1GB)
Prealloc.1 (1GB)
Journal file Mapped(Data) file
38 MB (최초22MB)
160MB 80 MB 160 MB
Prealloc.2 (1GB)
* 최초 약 440 MB Virtual Memory Area
100 ms 마다 100 mb 저장
60 s 마다 동기화 Client Process
(Mongo.exe)
Server Process (Mongod.exe)
MongoDB 관련 OX 퀴즈
MongoDB는 기존의 관계형 데이터베이스를 완전히 대체할 수 있다.
질 문 정 답
X MongoDB는 사용자에 의해 COMMIT과 ROLLBACK 할 수 있다 O MongoDB는 비정형 DB이기 때문에 설계가 요구되지 않는다. X MongoDB는 CPU보다 고 사양의 메모리가 요구된다. O MongoDB의 Map/Reduce를 통해 충분한 성능이 보장된다. X MongoDB의 Read 성능은 Write 성능보다 훨씬 빠르다. X MongoDB는 라이센스가 없다. X
2013년 관련 정보 정부 교육 www.dbguide.net 관련 서적
www.pitmongo.co.kr
커뮤니티 교육 www.mongodb-korea.org
