MongoDB Back2Basic

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 

 

 

9월6일 user forum

 

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

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

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

inhealthy되다

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

Hot backup , cold backup

Oplog ?

Time series db?

Tps