세상의 모든 Software 지식을 정리

* Arbiter 는 데이터셋을 복사할 수 없고 primary가 될 수 없다. 레플리카 셋들은 arbiters를 가질 수 있고 primary를 선정하기 위해 투표를 한다. Arbiters 항상 1개의 표를 행사한다. 결국 Primary가 죽어 새로운 Primary를 선정하기 위해서는 투표가 이뤄지게되고, Arbiter가 한표를 행사하게 되면서 홀수 표가 되어 새로운 레플리카셋을 생성하는 오버헤드가 없어지게 된다. 중요사항 :  Do not run an arbiter on systems that also host the primary or the secondary members of the replica set aribter를 가지고 있는 레플리카 셋에서, 프로토콜 버전1 (pv1) 은 프로토콜 버전 0 (pv 0)과 비교했을 때 rollback의 가능성을 증가시킨다. w:1  예) 예를들어 다음과 같은 replica set에서 arbiter가 있으므로 투표결과가 홀수가 되게 만든다. <Security> Authentication : aribiter는 데이터를 저장하지 않는다. 그래서 aribiter는 유저테이블 그리고 권한인증을 위한 맵핑정보가 없다. 그래서 local host Exception을 이용해 로그를 남긴다. Communication : arbiters와 다른 set 멤버들간의 유일한 커뮤니케이션은 투표, heartbeats 그리고 configuration data이다. 이것들은 암호화되지 않는다. 그러나 만약 몽고db 배치가 TLS/SSL이면 커뮤니케이션은 암호화된다. * Local host Exception ?

* Delayed memebers 는레플리카 복사본을 포함한다. Delayed memebers은 rolling backup 을 한다. 또는 "historical"이라는 데이터셋의 스냅샷을 작동한다. 그것은 다양한 실수를 대비해 복원시켜주는 기능이다.  <Consideration> Requirements priority 0이어야 한다.  hidden memeber이어야 한다. primary를 결정하기 위한 투표를 해야 한다.  Behavior Delayed memebers는 delay에 대한 오피로그를 복사하고 적용한다. dealy의 시간양을 선택했을 때,  딜레이 시간을 다음과 같이 고려한다. must be equal to or greater than your expected maintenance window durations. must be  smaller  than the capacity of the oplog. For more information on oplog size, see  Oplog Size . Sharding 샤드 클러스터에서는, delayed memebers 는 balancer가 enable되었을때 제한된 기능을 가지고 있다. 왜냐하면 delayed members 들은 딜레가 있을 때 대량의 마이그레이션이 발생하기 때문이다. 예) 5개의 replica set이 있고,  primary와 모든 secondaries가 데이터셋을 복제한다. 그때 한 멤버가 약 1시간동안 delay를 적용한다. 이러한 delayed member는 hidden 이고 priority 0 멤버이다. 설정 A delayed member는 members[n].priority 가 0가 되어야 한다. 그리고 members[n].hidden은 true로 설정되어야한다.

* Hiddent 멤버는 primary`s데이터 셋을 복사해놓지만 클라이언트 애플리케이션에 보이지 않는다. Hidden members는 항상 priority 0 멤버이며 primary가 될 수 없다. * db.isMaster() 를 치더라도 히든 멤버는 노출되지 않는다. 그러나 투표에는 참여한다. <Behavior> Read Operation 클라이언트는 읽기를 적절한 히든 멤버들에게 분배시키지 못한다. 결과적으로 이러한 멤버들은 트래픽을 받지 않는다. 그러므로 Hidden members는 reporting이나 backups와 같은 헌신적인 일들을 하는데 주로 쓰인다. Delayed member들은 히든이 된다. 샤드클러스터에서는 mongos는 히든 멤버들과 상호작용하지 않는다. Voting 히든 멤버들은 replica set 투표에 참여한다. MMAPv1 스토리지 엔진을 사용하는 경우, db.fsyncLock() 와 db.fsynUnlock()을 사용하여 히든멤버가 stop하는것을 막을 수 있다. 버전 3.2에서는 db.fsyncLock() 는 데이터 파일들이 변화하는 것을 막을 수 있다.그러므로 일관성을 제공하고 백업의 목적을 달성 할 수 있다. 이전 버전의 몽고디비에서는 db.fsyncLock()은 Wired Tiger에서의 로우 레벨의 백업을 보장하지 않았다.

priority 0로 설정된 멤버는 primary가 될 수 없다. 또한 투표의 계기(trigger)가 될 수 없다. 대신 A priority 0 멤버는 데이터의 복사본을 유지하고, read하고, election에 투표할 수 있다. priority 0로 설정된 멤버는 primary가 될 수 없다고 했는데, 이것은 multi-data center 개발에서 유용히 쓰인다. <Priority 0 Members as Standbys> priority 0 멤버는 standby 와 비슷한 기능을 사용할 수 있는데, 충분한 시간안에 새로운 멤버를 추가하는 것이 불가능하다. standby 멤버는 현재의 데이터 copy를 유지하고 이용가능하지 않은 멤버로 대체할 수 있다. 많은 케이스에 우리는 priorty 0 로 설정할 필요없다. 그러나 다양한 하드웨어, geographic distribution 같은 경우, priority 0 standby는 qualified member의 경우 primary가 되는 것을 보장한다. priority 0 standby는 아마 몇몇 멤버가 다양한 하드웨어, workload profiles의 종류라면 가치가 있다. 이러한 경우에도 priority 0 는 primary가 될수 없다. 이러한경우는 hidden member를 고려해보는것도 좋은 방버이다.

* 비록 클라이언트가 secondaries에 write 할 수 없을지라도 read는 가능하다. 만약 primary 가 이용 불가능해지면 남은녀석들이 투표를 진행하고 primary를 새로 선정한다.

* Primary는 write Operation을 적용한 후 그 operation을 primary`s oplog에 기록한다. Secondary members 는 이 로그를 replicate하고 그들의 데이터셋에 그 operation을 적용한다. 그렇다면 데이터를 복제하는 것이 아니라, 로그를 복제하고 그 해당 로그로 작업을 수행시켜 데이터를 만드는 것인가?  모든 멤버들( sencondary, primary)은 read operation을 허용한다. 그러나 default적으로 애플리케이션은 그것의 read 작업을 primary에 직접적으로 한다. 이러한 디폴트값은 변경가능하다. 레플리카셋에서 무조건1개의 primary는 필요하다. 위 그림은 3 member의 replica set을 보여준다. 만약 primary가 이용 불가능 해지면 남은 녀석들로 election을 선정한다. * 몇가지 상황에서는 replica set의 두 노드가 일시적으로 자신들이 primary라고 믿는 경우가 생긴다.   but at most, one of them will be able to complete writes with  {   w:   "majority"   }  write concern

*레플리카셋에는 3가지 멤버가있다. -> Primary -> Secondaries -> Arbiter *Arbiter ->Arbiter는 데이터의 복사본을 유지 하지 않는다, 그러나 Primary가 이용가능하지 않는다면 Primary를 유지하기 위한 투표에 참여한다, <Primary> Primary는 write 오퍼레이션을 사용하는 멤버이다,  MongoDB는 write오퍼레이션을 작동한다 그리고 Primary`s oplog에 저장한다, Secondary는 이 로그를 복제하고 데이터셋에 적용한다, Replica Set 멤버들은 read Operation을 사용한다. 그러나 default 조건으로 application은 primary member에서 read를 다이렉트로 한다. 레플리카셋에서 많아야 한 개의 Primary를 가진다. 만약 현재의 primary가 이용 불가능해지면 투표를 통해 primary를 선정한다.  <Secondaries> Secondary는 Primary`s data set의 복사본을 유지한다. 데이터를 복제하기 위해 secondary는 primary`s oplog로부터 비동기적 프로세스로 작업을 수행한다. 클라이언트는 secondaries로 부터 write를 할 수 없을 지라도, read는 가능하다. 다음은 특별한 목적에 따라 secondary를 설정할 수 있는 것들이다. Primary가 투표에 참여하는 것을 막는다.  읽기 작동을 방지한다. application이 작동하는 경우 seperation이 필요하다. historical snapshot을 계속 유지하는 것이 가능하다. 이것은 특별한 에러가 발생했을 때 회복시켜주는 것이다. 의도하지 않게 데이터베이스가 삭제된 경우 <Arbiter> Arbiter는 데이터셋을 복사 할 수 없고, primary가 될...

예를들어) profileImageUrl :  null getString("profileImageUrl")로 가져올 경우 return 값은 "null"로 String 형이 된다. 만약 null객체로 가져오고 싶다면 이 부분을 체크해 주어야 한다.

<데이터 발생량과 Accss Patterns은 분석되었는가 ? > Data양(초단위, 일단위)과 보관년도는 어떤가 ?  Read와 Write의 비율은 ? Update 빈도는? Map Reduce(빠른읽기와 통계분석)를 적용해야 하는가 ? <컬렉션과 인덱스에 대한 충분한 설계가 고려되었는가 ? > 적적한 Collection Type( Capped, Non-Capped )을 결정했나? 필드와 Data Type, Validator 는 결정되었나? 저장할 Document 크기는? Lin & Embedded Document를 적절히 설계했나 ? Secondary Indexs 의 사용 여부 적절한 Index Type을 선택했는가? <적절한 시스템 환경은 준비 되었나?> 데이터가 발생하는 비즈니스 환경에 맞는 적절한 Storage-Engine을 선택했나? 해당 Collection의 Sharding 여부는 결정되었나? 효율적인 처리를 위한 적절한 시스템 환경은 준비 되었나?(메모리, 디스크, CPU 수 등) * ACCESS PATTERN 해당 Collection 에 대해 얼마나 많은 데이터를 얼마나 자주 Read, Write 하는지에 대한 비율과 해당 데이터가 얼마나 오랫동안 보관 되어야 하는지에 대한 Life Cycle에 대한 이해에 따라 설계를 결정해야 한다. 하나의 컬렉션을 구성하는 필드 중에는 쓰기 작업 만 주로 수행되는 필드가 있는 반면, 쓰기/읽기 작업이 동시에 자주 발생하는 필드도 있다. 만약, 빅데이터에 대한 쓰기 작업이 빈번한 컬렉션을 여러 개의 컬렉션으로 분리 설계하게 되면 초당 몇 만건 의 데이터를 빠르게 저장하는데 한계가 존재한다. 또한, 빅데이터에 대한 읽기 작업이 빈번한 필드들을 여러 개의 컬렉션에 분리 설계한다면 읽기 성능은 저하 될 수 밖에없다.

<1:1 관계 with Embedded Documents> MongoDB는 flexible schema를 가진다.  <Pattern> 예) 후원자와 주소관의 관계 {  _id : "joe",  name : "Joe Bookreader" } {  patron_id : "joe",  street : " 123 Fake Street",  city : "Faketon",  state : "MA",  zip : "12345" } 만약 주소 데이터가 name정보에 의해 자주 참조된다면, 애플리케이션은 여러번의 쿼리를 날리게 된다. 그러므로 더 나은 데이터 모델은 patron 데이터 안에 address 데이터를 embed하는 것이다. {  _id : "joe",  name : "Joe Bookreader',  address : {               street : " 123 Fake Street",               city : "Faketon",               state : "MA",               zip : "12345"               } } 위는 1번의 쿼리로 불러오게 된다. <1 대 다 관계 with Embedded Documents> <Pattern> 다음 예는 후원자와 여러 주소들간의 관계를 나타낸 것이다. 다음 예는 참조에 의한 ...

* 샤딩의 목적 데이터의 분산저장 빠른 성능 데이터의 백업과 복구 전략의 일환 1. 초당 발생하는 빅데이터를 디스크에 저장할 때 발생하는 Write Scaling문제는 애플리케이션의 성능 저하문제를 유발시키며, 샤딩 시스템 전체의 성능 저하 현상을 유발 2.  분산처리는 여러개의 프로세스가 여러개의 CPU를 통해 동시 작업을 수행했을 때 가장 이상적이라 볼 수 있다. 3. 만약, 하나의 서버에 데이터를 저장, 관리했을 때 서버의 장애문제가 발생한다면 유실되어지는 데이터의 양은 상상 초월일 것이다.  이러한 위험 요소로부터 안전하게 데이터를 저장, 관리하기 위한 목적으로 샤딩 시스템을 활용한다면 보다 효과적인 시스템 운영이 가능할 것이다. 1) 샤딩 구축을 위한 적정 시스템 환경 데이터의 적절한 분산처리를 통한 효율성 향상이 가장 큰 목적이므로 3대 이상의 샤드 서버로 구축 권장 싱글 노드를 운영할 때 요구되는 메모리 영역보다 최소 20~30프로 이상의 추가 메모리 영역이 요구된다(MongoS와 OpLog그리고 Balancer 프로세스가 사용하게 될 추가 메모리에 대한 고려 등) 샤드 시스템 구축할 때 요구되는 Config 서버는 최소 3대 이상 활성화 할 것을 권장한다. Config서버는 샤드 시스템 구축과 관련된 메타데이터를 저장 관리하며 빅 데이터의 빠른 검색을 위한 인덱스 정보를 저장, 관리하고 있기 떄문에 샤드 서버와는 별도의 서버에 구축하는 것이 원칙 (최소 1대 이상의 Config 서버가 요구되며 장애 발생으로 인해 정상 작동되지 않는 경우를 위해 추가 Config서버가 필요하다. Config서버는 샤드서버보다 저 사양의 시스템으로 구축가능) <MongoS 프로세스> 주요특징 빅데이터를 샤드 서버로 분배해주는 프로세스 하나 이상의 프로세스가 활성화 된다. Application Server에서 실행 가능하다 CONFIG 서버로...

* Config Servers는 샤드 클러스트의 메타데이터를 저장하는 곳이다. 메타데이터란, 모든 샤드들의 chunks리스트와 chunks들의 range를 가지고 있다. * mongos 인스턴스는 이 데이터를 캐쉬하여 read, write 작업시 해당 샤드를 찾을 수 있도록 캐쉬할 수 있는 기능을 제공한다. * mongos는 클러스트의 메타 데이터가 바뀌었을 때, 업데이트 한다. 예를들어, Chunk Split 또는 샤드를 추가하는 경우가 해당되는 예이다. * Config Server는 또한 Authentication설정 정보를 저장한다. 예를들어,    Role-Based Access Control  or  internal authentication  settings for the cluster. * MongoDB는 또한 distributed locks를 관리하기 위해 config Servers를 사용한다. <MongoDB의 분산 락> MongoDB는 mongos들간의 config서버와의 데이터 통신 동기화를 위해 분산 락 개념을 도입하고 있다. Mongos가 독점하는 자원은 다음과 같다. 밸런서(balancer)의 연산 컬렉션(collection)의 분할(split) 컬렉션의 이관(migration) 위 내용을 보면 공유자원이기보다는 연산 쪽에 가깝다. Mongos는 mongos의 핵심 기능인 샤딩을 수행할 연산들에 대해 분산 락을 사용한다. 즉, 여러개의 mongos가 설치되어 있다면, 설치된 mongos중에 상기의 작업을 아무나 먼저 시작할 수 있고, 시작된 연산에 대해 독점하고 있음을 다른 mongos에 알려주어야 한다. mongos의 시작과 함께 분산 락을 모니터링하기 위한 LockPinger쓰레드가 생성된다. LockPinger 쓰레드는 30초 주기로 config서버와 통신하며, 주요 업무는 다음과 같다. 30...