세미나들

MongoDB Back2Basic

k9e4h 2019. 7. 11. 19:58

MongoDB Korea Back2Basic 2019.07.11 / 삼성역 무역센터13:00-18:00

 

참여자 level - 반은 이미 사용 , 반은 사용

사용한 사람들에게 맞춰서, 기존에 

 

Mongodb 작년 7월에 한국 지사 생김

몽고디비는 2009년에 만들어짐

 

 

 

Session 1. Json

같은 json rdb nosql 저장했을때

rdb json 안에 값에다가 Index 걸기 어렵다. 

다른 nosql 비교했을 때는, 효율적인 manufacturing 지원하기 위한 api(aggregate ..) 지원이 mongodb에는 많다.

 

주제

Mongodb document model 사용한 이유

다른 document model 지원하는 것들과 다른 것은 무엇인지

 

 

시작은 mongodb와 사용자 간의 miss concept 대해 얘기해보자

 

강사Q) 우리는 realation 사용하게 되었을까

결론- 비용때문에, realation 좋아서 쓴게 아니라 비용 효율적으로 하기 위해 정규화를 했음

예전에는 하드웨어 비용이 너무 비싸서 인건비보다 하드웨어를 어떻게 효율적으로 사용할까가 주된 연구 과제였어.

요즘에는 하드웨어 비용보다 개발자 비용이 비싸

 

최초 mongodb 사상 3가지

Best way to work with data

Intelligently put data where you need it

Freedom to rum anywhere

 

Access pattern 너무 다양해져서 rdb에서 index 걸기가 어려워

rdb에서는 최대 64?개의 index 생성할 있어

 

데이터를 다루기 편하다는 것은 db 자체에서 index 생성, 관리등을 편하게 해줄수있다는 (개발자, dba 관리하지 않아도)

 

Document model : rdb raw 얘기함

collection : rdb table

embedding linking $llokup : rdb join / mongodb에서 최초에 지원하지는 않았음, 3인가 4버전에서부터 지원함

Data model 바꿈으로 인해서 join, transaction 대한 생산성이 30,40프로 좋아짐 ( rdb 쓰면 데이터를 쪼개서 저장하고 실제로 때는 다시 합치고, 이런것들 떄문에 transaction 필요해지는 거니까)

그러나 쇼핑몰 같은데에서ㅡㄴ transaction 필수로 필요한 경우도 이씀 -> 그래서 기존에는 application 단에서 데이터를 조합해서 mongodb 저장했음

View : merterise view? (MView) 4.2부터 지원

그냥 view 뷰에 대한 정의만 있어, 근데 엠뷰는 정의와 오페이션이 모두있음

 

mysql 8에서 부터는 json 형식 지원함

어떻게 하면 access type 다양하게 지원할 이쓸까가 nosql에서 가장 고민하는 (full, key, range 드드드등) secondary index?

mongodb 다른 nosql db 비해서 좋은 -> 빠르다, 왜냐면 다양한 index pattern 사용할 있으니까

Rdb-집합, data scala value이다. 

rdb에서는 json type 써도 parsing memory에서 해야하고 index 걸기가 쉽지 않다.

 

Document db - base 오로라db, 그래서 샤딩을 없고 어쩌구저쩌구 문제가 이씀

 

nosql 어떤 language 지원해줌..!? 모든 driver failover, load balancing 다됨 - driver mongodb사이에 elb 있으면 best practice 아님, elb 껴있으면 failover 후에 restart 라던지 api 다시 날려줘야함??

 

데이터레이크에서 하둡 -> 레이턴시 보장이 안되에에에에

하둡, 레디스, 카산드라 , 맵리듀스 어라어마ㅣ;;ㅣㅏㅁㅇ 이렇게 구성을 -> 용도별로 나눠서 좋겠지만 관리가 어려움

몽고디비만 올려놓으면 그냥 해놓구 있음 -> 데이터 분석 퍼포먼스가 안나온다던지 특정 업무에 따라 퍼포먼스가 다를 있지만 그거는 솔루션에서 이게 좋다라고 말하는 것이 아니라 각자가 선택해야할 문제이다.

openAPI 관점에서 다양한 솔루션을 사용하면 관리하기가 어려움,

 


session 2. Atlaas

 

mongodb infra was, gcp, azure에서 인프라 지원받아서

Recommended region -> az 3개인것 : 

  1. Electable nodes -> primary 있는 node
    Leaf node 과반수 이상 살아있어야지 있음 / multi region 이더라도 node 과반수이상 있지 않으면 안됨
  2. Read only nodes -> 국내에서 커가서 해외로 진출하는 기업에서는 1번은 국내에 두고 read only 싱가폴 도쿄 인도 쪽에 많이둠 (kpop하는 컨텐츠 회사들)
  3. Alnalyticcs node -> …. 모르게따….

 

shape up/down 무중단으로 이루어짐

 

Zone sharing.. !? -> global 서비스 할때 goal read 하면 있엉, 나라마다 레이턴시를 어쩌구저쩌구우우우우? -> aws 에서는 az 간의 구성은 쉽지만 multi region db 구성은 어려움

Multi write

Zone sharing -> 미국데이터는 미국에만, 서울데이터는 서울데이터센터에만 있음,, 미국 데이터를 읽는 서울의 리드를 놓음,

샤딩은 데이터가 밖으로 나가지 못하는

 

 

atlas에서 sandbox collection 오른쪽 위젯 누르면 local dataset 제공함(지역관련, 센서, 상품 드응 산업군따라 데이터셋 있는 )

atlas에서 chart 제공함ㅋㅋㅋㅋ 그래서 api 이거 가져다쓰면됨 별도로 만들 필요없엉

 

모니터링할때 metric 보면 monitoring 가능함 -> performance advisor에서 어떤 쿼리가 느린지 나옴 와우! -> 심지어 가이드까지 ! Excute plan, 

Excuse plan : 중에서 비율(score) 100 좋은거 이걸 기준으로 튜닝 포인트를 잡아가는게 좋음

Esr : 결합인덱스를 만들때 ESr 만들어야지 효과가 극대화된다

Scan and order : sorting 비효율 적으로 하면 많이 발생함,

 

Security > advanced 메뉴에서 audit 가능함

 

Serverstaus.py -> 서버상태 (mongo_url 커넥션)

insertUser.py -> _id 자동으로 생기지만 사용자가 def 있다.

 

 

latency sync 없는 이유 ?

Cap 이론 - ca, ability, performance 이론

 

oplog gap,

oplog 응답하는 시간, TImestamp 데이터가 변경된 시간 -> 얘네를 사용하면 빠르게 데이터를 COPY 있음

 

Secondary read 많이하는 업무라면 무조건 4.0 쓰는게 좋아!!!!!

 


Session 3. Json Schema

아직 시장에서 json 바라보는 관점은 성숙되지 않음

Json 생각해야할 것이 많은 것임.

 

Mongoldb is schemaless   아님!!!!!

json schema free 한게 아님, flexable하지만 스키마가 없는 것은 아니야, 원하는대로 머지해서 쓰면안돼 ㅋㅋㅋㅋ…..

Mongoldb is flexible data

 

Schema design in mongoldb differs from relational

Schema design in mongoldb is important

almost all performance issues are related

.

.

 

게시물에 코멘트를 관리할 테이블 별도로 두는게 아니라 게시물 OBJECT 안에 코멘트를 넣을 수도 있지(embeded)->이럴때 update 어렵지만 READ에서는 쉽게 가능하지 -> number of reads vs updates -> ㄱ꼭 1:다의 관계가 아니여도됨, 예를 들면 게시물안에 코멘트 작성자 생성일은 넣어두고, 코멘트 테이블에서 상세 코멘트 내용 수정일만 관리해도 되니까

 

Document 사이즈가 16메가-> 모든 파라미터를 하나의 Document 넣기는 힘들지

 

join 하면 다른 테이블을 읽기 때문에 latency 다름, 그래서 join 없이 embeded…!

document 쓰면 테이블보다 직관적임

Rdb m:m 관계가 안되지만 mongodb에서는 가능해

 

Data modelding - time series

Pattern 1. Bucketing

object size 커지잖아!

Pattern 2. Bucketing time & transactions

star dt, end dt object 나눔, 평균 등의 계산을 위해서는 parsing 필요해지네..?

Pattern 3. + pre-aggregation

===> 이런식으로 json 디자인이 필요해!!

 

rdb에서는 센서값을 array blob으로 넣어버림

Data model, query model, api model ?

 

data modeling - Single view (여러 시스템에서 데이터가 같은 의미인데 컬럼명이 달라지고 이런거 패턴이 다른거)

공통부분은 하나로 두고 다른 부분은 하나의 패턴안에 값을 넣어줌 (폴리매티 디자인패턴?알고리즘?) -> 기술 블로그에 pattern 대해서 설명해놓음(12가지 정도 있음)

 

Data modeling - attribute pattern

얘는 attribute 별로 모은거, 버켓팅은 시간별로 짜른 느낌!

 

스키마 패턴, polymorphic, outlet 

 

단일 다큐면트에 1000개에 대한 api 하면 단일 다큐먼트에 대해서는 lock 걸릴 있지, 이때는 1000개의 api 날리는 bucketing 기준을 나눠주면 locking 분산시킬 있음

 

**** 9 이후 design pattern 관련해서 계속 대상 만듬

 

——————————————————————————————————————————————————————————————————————————————————————————

 

index type 

Single field

Compound field

Multikey

Geospatial

Text

Hashed

 

몽고db에서는 _id 붙어있으면 index 잡힘

 

Index 관리방법

rule base or cost base 관점의 index 생성 (cost base optimizer)

Rule base

-> 장점 : parsing 빠름

-> 단점 : 항상 rule 따라감( 좋은 plan 있더라도)

Cost base

->

-> 단점 : cost 계산해야하기 때문에 parsing 오래걸림,

 

Mongodb optimizer rule base 가까움

항상 테스트를 해보고 좋은게 있으면 cache 올려놓음-> 단일 플랜일 때는 cache 올리지 않음, 근데 multi plan 가능할때는 cache 올려놓고 그때마다 쓰라고함(explain했을때 winning plan, reject plan 둘다 있음), index탄다고 plan 올라가는게 아니야-> cache 올라가는걸 확인하는게 아니라 reject plan 있고, 없는지를 고민해봐야함

 

index 종류

Multi key index - scala 배열의 index 적음, subv document range where절에 있을때 inspection 수가 메모리에서 이뤄지기 때문에 오래 걸리지 않음

Sparse, partial -> sparse deprecated, sparse하면 null index 안함, partial 특정 기간에는 인덱싱 안하고 어떤 기간에 대해서는 인덱싱하구, null indexing (rdb, nosql 모두)

INdex build : foreground, background, rolling

 

 

 

Aggregation pipeline

Shard 상에서 aggregation 고려가 필요해,

카카오의 추천 서비스가 몽고디비고 샤드가 80개인걸로 알고있음

Aggregation 없으면 mongodb 약점이 많아 ㅋㅋ(aggregation 굉장히 잘되어있음)

Two part of aggregation on shard cluster

-> 특정 shard에서만 operation하는가? Targeting query or broadcasting query

Broadcast query shard part merger part 나뉨

(primaryShard에서 join 일어나는 ?)

Mongos 같은 경우 streaming stage 하지 않음

primaryshard에서는 lookup, out? 같은거 많이

 

Q) 대소문자 구분 쿼리 index 어떻게 하는게 좋을까 (이름 검색이라던지.. )

 

——————————————————————————————————————————————————————————————————————————————————————————

 

Scalability through replication and sharding

 

Replica set 종류

Masteer-slave

Primary-secondary(pss ,primary slave slave ,홀수개) - write 무조건 primary에서만 가능하고 read 모두 달라진다

Heart beat - 서로 체크하는

가용성 때문에 consistency(가용성)

mongodb 고가용성을 위해 client driver!!

분산형태의 아키텍처일때, primary 죽으면 다른 node와의 consistency 어떻게 맞출 것인가. -> cap 따라 설정을 있음, Read 컨선? Write 컨선에 따라 달라짐

 

node 50개까지 있지만 일렉션에 참여할 있는 node 7개만 가능함

 

짝수의 node 되면 어쩌다가 짝짝별로 나눠져서 primary 선출할 없게됨

 

Mongos 자체는 여러개 냅두면 알아서 load balancing

 

 

Sharding - scalability

사양을 높이기보다는 여러개 하는게 성능에 좋음, 이걸 쉽게할 있는게 sharding

replica 해도 bootlenecks(병목) 생길 수가 있어.

sharding route server 역할을 하기 위한 -> mongos

Config server -> sharding 대한 정의

샤딩할때 중요한

Sharding key -> sharding 동일하게 되어야하니까, range, zone, location, hashed sharding key 방법 , 데이터의 분포도등을 고려해서 샤딩키를 만들어야해

 

대량의 데이터는 미리 chunk split해서 shard하고 옵션을 끄고난 다음에 업무를 돌리면서 중간중간 들어오는거는 Range 하면 좋지

shard drop 오래걸림

host(was, gap, azure) 따라 기능 차이가 조금씩 있음, 기본적으로 aws 기반으로 설명해줌

Sharding balancing -> shard 청크 갯수에 따라 balancing 정책이 다름

 

3.x 버전에는 transaction 지원이 그랬는데 4.x 부터는 cluster단에서 fully transaction (acid) 가능함 -> isolation

 

Read 4가지 종류 -  uncommitted , committed 

 

 

96 user forum

 

——————————————————————————————————————————————————————————————————————————————————————————

상품 single view ?? : 쇼핑몰에서 옷과 가전제품을 하나의 single view 만들 있는가

다이나모디비 래디스(레이턴시때문에 메모리에 올려서 ) -> nosql 제공하는 db 회사..!? Nosql ms

inhealthy되다

dr훈련? -> 장애가났을때 다른 backup 본으로 switch하는 과정

Hot backup , cold backup

Oplog ?

Time series db?

Tps

반응형

'세미나들' 카테고리의 다른 글

Agile Conference 2019.10.18  (0) 2019.11.30
AWS Summit Seoul 2019  (0) 2019.04.19
AWS re:invent  (0) 2016.12.05
트렌드 X AI WEEKS  (0) 2016.12.02
SparkLabs Demoday 8  (0) 2016.12.01