실시 간 동기 화 MongoDB Oplog 개발 안내

옮 겨 싣 기 Joymufeng, PlayScala 커 뮤 니 티 에 오신 것 을 환영 합 니 다 (http://www.playscala.cn/)
Capped Collections
MongoDB 는 Capped collections 라 는 특수 한 Collection 이 있 습 니 다. 삽입 속도 가 매우 빠 르 고 기본 과 디스크 의 기록 속도 가 많 지 않 으 며 삽입 순서에 따라 효율 적 인 조회 작업 을 지원 합 니 다.Capped collections 의 크기 는 고정 되 어 있 습 니 다. 작업 방식 은 링 버퍼 (circular buffers) 와 같 습 니 다. 남 은 공간 이 부족 할 때 가장 먼저 삽 입 된 데 이 터 를 덮어 씁 니 다.Capped collections 의 특징 은 효율 적 인 삽입 과 검색 이 므 로 Capped collections 에 추가 색인 을 추가 하지 않 는 것 이 좋 습 니 다. 그렇지 않 으 면 삽입 속도 에 영향 을 줄 수 있 습 니 다.Capped collections 는 다음 필드 에 사용 할 수 있 습 니 다:

저장 로그: Capped collections 의 first - in - first - out 특성 이 로그 이벤트 의 저장 순 서 를 만족 시 킵 니 다.

캐 시 소량의 데이터: 캐 시 는 읽 기, 쓰기 가 적은 것 이 특징 이기 때문에 색인 을 적 절 히 사용 하여 읽 기 속 도 를 높 일 수 있 습 니 다.

Capped collections 사용 제한:

데 이 터 를 업데이트 하려 면 collection scan 을 방지 하기 위해 색인 을 만들어 야 합 니 다.

데 이 터 를 업데이트 할 때 문서 의 크기 를 바 꿀 수 없습니다.예 를 들 어 name 속성 이 'abc' 이면 3 글자 의 문자열 로 만 수정 할 수 있 습 니 다. 그렇지 않 으 면 작업 이 실 패 됩 니 다.

데 이 터 는 삭제 할 수 없고 삭제 하지 않 으 면 drop collection

만 가능 합 니 다.

sharding 지원 하지 않 음

기본 값 은 자연 순서 (즉 삽입 순서) 로 결 과 를 되 돌려 주 는 것 만 지원 합 니 다

Capped collections 는 $natural 연산 자 를 사용 하여 삽입 순서의 정렬 이나 정렬 에 따라 결 과 를 되 돌려 줍 니 다.

db['oplog.rs'].find({}).sort({$natural: -1})

Oplog
Oplog 는 특수 한 Capped collections 로 특수 한 점 은 시스템 급 Collection 으로 데이터 뱅 크 의 모든 조작 을 기록 하고 클 러 스 터 간 에 Oplog 에 의 해 데이터 동기 화 를 하 는 것 이다.Oplog 의 전체 이름 은 local. oplog. rs 로 local 데이터 에 있 습 니 다.local 데이터 가 사용 자 를 만 들 수 없 기 때문에 Oplog 에 접근 하려 면 다른 데이터 베 이 스 를 이용 한 사용자 가 필요 하고 이 사용자 에 게 local 데이터 베 이 스 를 방문 할 수 있 는 권한 을 부여 해 야 합 니 다. 예 를 들 어:

db.createUser({
   user: "play-community",
   pwd: "******",
   "roles" : [
    {
      "role" : "readWrite", 
      "db" : "play-community"
    }, 
    {
      "role" : "read", 
      "db" : "local"
    }
  ]
})

Oplog 기록 의 조작 기록 은 멱 등 (idempotent) 입 니 다. 이 는 데이터 가 손실 되 거나 일치 하지 않 고 여러 번 실행 할 수 있 음 을 의미 합 니 다.예 를 들 어 $inc 작업 에 대해 Oplog 는 자동 으로 $set 작업 으로 변환 합 니 다. 예 를 들 어 원본 데 이 터 는 다음 과 같 습 니 다.

{   "_id" : "0",   "count" : 1.0}

다음 $inc 작업 을 수행 합 니 다:

db.test.update({_id: "0"}, {$inc: {count: 1}})

Oplog 에 기 록 된 로 그 는 다음 과 같 습 니 다.

{ 
  "ts" : Timestamp(1503110518, 1), 
  "t" : NumberLong(8), 
  "h" : NumberLong(-3967772133090765679), 
  "v" : NumberInt(2), 
  "op" : "u", 
  "ns" : "play-community.test", 
  "o2" : {
    "_id" : "0"
  }, 
  "o" : {
    "$set" : {
      "count" : 2.0
    }
  }
}

이런 전환 은 Oplog 의 멱 등 성 을 보장 할 수 있다.또한 Oplog 는 삽입 성능 을 보장 하기 위해 추가 로 색인 을 만 들 수 없습니다.
Timestamps 형식
MongoDB 는 내부 에서 만 사용 할 수 있 는 특별한 시간 형식 인 Timestamps 가 있 습 니 다. 예 를 들 어 위의 Oplog 기록:

Timestamp(1503110518, 1)

Timestamps 길이 64 비트:

상위 32 위 는 timet 값 은 epoch 시간 부터 지금까지 의 초 수

를 나타 낸다.

후 32 위 는 ordinal 값 이 고 이 값 은 순서대로 증가 하 는 서수 로 특정한 초 동안 의 몇 번 째 조작

을 나타 낸다.
동기 화 시작
동기 화 Oplog 를 시작 하기 전에 다음 과 같은 몇 가 지 를 주의해 야 합 니 다.

Oplog 는 색인 을 사용 하지 않 기 때문에 초기 조회 대가 가 클 수 있 습 니 다

Oplog 데이터 양 이 많 을 때 ts 를 저장 할 수 있 고 시스템 재 부팅 시 이 ts 를 이용 하면 첫 조회 비용 을 줄 일 수 있다

oplog Replay 표 지 는 ts 조건 을 포함 한 여과 조 회 를 현저히 가속 화 할 수 있 으 나 oplog 조회 에 만 유효 합 니 다

val tailingCursor =
 oplogCol
  .find(Json.obj("ns" -> Json.obj("$in" -> Set(s"${db}.common-doc", s"${db}.common-article")), "ts" -> Json.obj("$gte" -> lastTS)))
  .options(QueryOpts().tailable.oplogReplay.awaitData.noCursorTimeout)
  .cursor[BSONDocument]()

tailingCursor.fold(()){ (_, doc) =>
 try {
  val jsObj = doc.as[JsObject]
  jsObj("op").as[String] match {
   case "i" => //   
   case "u" => //   
   case "d" => //   
  }

  //   ts ，    
  if (tailCount.get() % 10 == 0) { }
 } catch {
  case t: Throwable =>
   Logger.error("Tail oplog Error: " + t.getMessage, t)
 }
}

또한, ReactiveMongo - streaming 의 Akka Stream 은 bug 가 구현 되 었 으 며, 첫 번 째 조회 에 데이터 가 되 돌아 오지 않 으 면 조회 요청 을 지속 적 으로 보 내 1 초 에 수 십 번 에서 수백 번 정도 요청 을 보 내 는데, Oplog 의 조회 비용 이 많이 들 기 때문에 결국 MongoDB 메모리 가 넘 칠 수 있 음 을 알려 드 립 니 다.자세 한 내용 은 쿼 리 를 보 내 는 동안 꼬리 에 맞 는 커서 의 초기 쿼 리 결 과 는 비어 있 습 니 다.
레 퍼 런 스

MongoDB Doc - Replica Set Oplog

MongoDB Doc - Capped Collections

MongoDB Doc - Tailable Cursors