[교육] MDB

• 0) MongoDB 웨비나 (2020/10/15 오후 2시)
  • 아젠다
    • MongoDB에 대해서 잘못 알려진 주요 8가지 항목
    • MongoDB를 올바르게 사용하기 위한 가이드
    • 효율성 / 생산성 향상을 위한 몇 가지 팁과 요령
    • Live Q&A
  • 8가지
    • 1. MongoDB is v4.4 : 버전이 오를수록~ 엄청난 발전을 하고 있다…
    • 2. The Json database : Json 효과적인 전송 , Bson 효율적인 저장.
    • 3. No transactions : 트랜잭션 제공한다.
    • 4. no relationships : $lookup 을 통해서, 쪼인도 가능하다.
    • 5. Mongobd is about sharding
      •  mdb는 멀티쓰레드라, 멀티코어 고사양 서버 한대가 더 유리할수있다.
      • 하드웨서 성능 퍼포먼스를 최대한 뽑는식으로…
      • 엄청난 대용량이 아니면, 굳이 샤드를 쪼겔 필요는 없다.
    • 6.MongoDB is Insecure : 안전하다…
    • 7. MongoDB Loses Data : 데이터 유실? 체크포인팅/저널링 과정에서… 극단적 경우만~
    • 8. MongoDB is really easy : 쉽다? 막쓰다보면~ 어렵지
• 1) Atlas Intro (2021)
  • ...
• 2) xxx (2022)
• 3) Introduce MongoDB (2023)
• 3) Storage and Retrieval 1&2
  • insertMany() : ordered , unordered 옵션
  • cursor : limit, skip = 일단 데이터를 다 가져온뒤~ 버리는 구조라... 안티패턴 조심해야!
  • Array specific query operators : $all, $size, $elemMatch
  • Expressive Queries :
    • 예) .find({ $expr: { $gt: ["$tomatoes.viewer.rating" ,"$imdb.rating"] } })
  • Update Document : $set, $unset, $inc +-, $mul *, $min, $max,
  • Array updates : $push, $pop, $pull, $pullAll, $addToSet,
    • 예) .updateOne({name:"n18"}, { $push : {track_arr : { artist: "SKY", title: "Love"} }})
  • Updateing_ Locking 및 Concurrency : 업데이트 시를... 충돌적인 상황을 피하기 위함.
    • 업데이트 직전의 시간or해시값 등의 변화유무를 조건으로 -> 덮어씌는지 판단하는식도 있음.
    • 직접 그런 로직을 개발해야하는 건가?
    • (트랜젝션 차원 write conflict 하는게 더 좋지않나?)
  • Overwriting documents replaceOne() : 그냥 어퍼치기 (성능적으로 문제?)
  • Updating Arrays : 특정, 매칭, 전체, ...
  • Update Array <- $each $push and $sort&$slice
    • Push&Sort 새로운 데이터가 계속 들어와도... 순서가 유지되는 배열을 만드는 로직을... 쿼리 한방으로 해결!
    • 즉! 해당 배열필드가, 항상 순서와 크기를 유지할수있도록~ 손쉽게 sort slice 옵션 제공.
    • 순서 크기만 바꾸고 싶다면, 빈 배열로 push update 해라는 식으로 안내됨.
    • 왜? push 에 이런 기능이 있지??? -> 그냥 업계에서 많이 필요로 해서... 제공 해주는거 같음ㅎ
    • 자료구조 차원이나, mdb 쿼리 문법철학적 차원의 이야기는 아닌것ㅋ
    • 예제)
      • > db.a.insertOne({ "name" : "Tom", "hrs" : [ 4, 1, 3 ] })
      • > db.a.updateOne({name: "Tom"}, {$push: {hrs: {$each : [2,9], $sort: -1, $slice: 4}}})
      • { "name" : "Tom", "hrs" : [ 9, 4, 3, 2 ] }
  • Expressive Updates : 특정 표현식? 을 처리하는 업데인트 ? $set ... $multiply ...
  • Upsert : ...
  • findOneAndUpdate() : ...
• 3) Indexes and Optimization
  • 인덱스란? 필드의 다규먼트에 해당하는 포인터를 정렬된 형태로 저장하고 있는 별도의 저장공간.
  • (쿼리시에... 인덱스는 무조건 하나만 쓸수있다... 새삼스럽게)
  • PlanCache : 쿼리에 사용할 인덱스 해줌. (데이터가 변함에 따라, 쿼리의 work량 등등으로 최적의 인덱스로 해줌)
  • .explain() : 매 쿼리에 확인 습관...
    • nReturned 와 "전체doc수" 및 "전체key수" 의 '비율' 로 판단하면 됨.
  • 종류 : single-field, compound, multikey, geospatial, wildcard (text는 Deprecated -> Atlas Search 으로!!!)
    • single-field : 다양한 타입
      • (Object 필드는 그 값이 통체로) (unique 중복방지) (partial 특정조건만) (sparse 비추) (hashed 비트리X) (TTL)
      • index prefix compression : 인텍스 크기를 줄이기 위한 노력.
    • multikey : 배열타입
      • 배열 요소마다 인덱스 하면서 어마하게 커짐) (...)
    • compound : 구성할 필드 순서가 매우 중요!
      • 예: 한국>부산>해운대
      • Equality - sorting - range 순의 조합이 젤 좋다고 함!
      • 음... BTree 이면 range 가 가능한 구조인데, 되긴되는거 아님?
      • 걍 탐색비용 줄이는 효과?
      • (걍 선빵 날리고, 정렬된 데이터의 특정 범위를 가져온다는 전략?)
    • geospatial : ...
    • wildcard : user.* 식으로... user.name, user.age, ... 등등 스키마 프리한 상황에 좋을수있음;;;
• 3) Replication  
  • ...
• 3) Sharding
  • 몽고도 샤드는 마찬가지다...
  • 몽구스가 Range 라우팅을 해주겠지만, 당연히 성능에 차이는 있다.
  • lookup 또한, 사실상 다른 샤드와 쪼인을 하는거라, V6 에서 지원은 하겠지만... 그렇게 쓰면 안된다.
• 3) Schema Design (+모델링)
  • BSON
    • Binary Serialized Object Notation (http://bsonspec.org/spec.html)
    • Type, Fieldname, <data-length>, Data 형식
    • Language Object<->Binary<->Object
  • Docs Vs Arrays : ...
  • Container types : Document + Array
  • RDBMS Vs Document model
    • Normal Form (Design based on the data, not the usage)
    • Many Patterns (Designed for a usage pattern)
  • Payload field Vs Processing field : ...
  • Design Patten
    • Attribute : array에? 고정된 형태의 필드 키 를 잡아서 활용???
    • Extended Ref : 참조할 doc 를 그시점에 복사해서 가져오기.
    • Subset : 필요할 doc 들 중에서 쓸꺼만 미리 셋팅해 잘쓰고, 그 doc 가 변화되면... 그걸 매번 또 반영해준다.
    • Bucket : time-seires 같은 대량의 데이터는, 대강 (시별 일별 ...) 단위로 한 doc 에 싸그리 몰아넣는 방식.
    • Computed : Write 때 -> 통계수치를 미리 계산하는 로직 -> aggr 파이프라인 태워, 미리 만듬 -> Read 때 바로씀
    • Schema Versioning : 데이터의 버젼에 따라 application 단에서 처리를 달리하고? 최신버전으로 지속적 마이그래이션?
• 3) Aggregation 
  • ...
• 3) Q&A
  • Q: aggrgate 파이프라인 lookup 5번 Vs 걍 find 로 5번 :
    • A: 기본적으로 find가 더 빠른데... aggr 는 한번 쿼리로 할수있는 장점.
  • Q: lookup 을 왠만하면 줄여라 :
    • A: 인덱스 기반으로 쿼리 된 뒤 -> 그 Doc Stream 이 -> 하나씩 lookup 인덱스로 병렬쪼인 되는식 이라함.
  • API 스펙과 딱맞게 모델링하는게 좋흡니다.
  • 임베드 시키는걸 두려워 하지 마세요. 그냥 application 단에서 잘 합치고, 씽크 잘 하세요.
  • Q: 리젼이 달라서 쿼리 속도가 느리다.
    • A: 리플리카 Read 빠르게 하는 옵션을 적극 활용.
  • Q: 문자열 like 검색 :
    • 정규식 쿼리는 느림... term 단위로 나누어 필드를 추가하고 인덱스를 걸어서 해결 해 볼수는 있음
    • 모든 데이터를 빠르게 찾는건... 어떠한 db 도 불가능.
    • 최대한 범위를 줄일수있는 필드를 인덱스로 강제 하는게 좋음. (제약을 많이 두어라)
  • Q: 유한한 쿠폰 findAndupdate() 쿼리
    • A: coupon < 100 인  조건으로 find 한것을 -> inc 업데이트 하는식은 -> 음... 말이 되는거 같습니다!
    • 조건부로 업데이트 하는 쿼리 전략 -> 충돌 오버플로우 방지 -> 쿠폰의 최대 발급량을 보장 해 줄수 있다.
    • MDB 는 씽글 쓰레드라 각각 쿼리들의 atmoic 이 보장됨
• Atlas
  • Atlas Search
    • 무료이니... 서치 인덱스 마음껏 테스트 해보라
    • 요구사항이 그냥 검색 인데... 그걸 디비쿼리를 하결하는건 미련한 짓.
  • Trigger
    • 이벤트를 확실히 만들어 준다!?
    • 이후 프로세싱은 알아서 잘 밀리지 않게...  mq buf 를 잘 활용 해 보던가...
• ...

-끝-