4차스터디 파티셔닝 및 샤딩
fail over 관점에서의 MongoDB vs MySQL
실제 사례에서
MongoDB는 클러스터 구조로 3중화.
MySQL은 Primary - Replica구조로 2중화할 수 있음. (물론 더할수도있지만)
만약 하나의 노드가 죽어버리면? 남은 노드(들)은 죽은 노드의 트래픽을 모두 감당할 수 있을 정도의 capacity가 존재해야함. 그러한 capacity를 측정해서 하나의 노드 장애가 전체노드에 영향을 가지 않게끔 하는것도 중요하다. (replica를 단순 복제용으로 쓴다면 큰 문제는 없겠지만)
write 부하 관점에서의 MongoDB vs MySQL
mongo:
- 모아서 한번에 write (appendish)
- LSM + Btree 혼용
mysql:
- in-place update
- B+tree
그래서 mongo가 좀더 좋음 ㅇㅇ 일단 append하고 나중에 압축하자란 마인드
왜 몽고 DB에는 트랜잭션 개념이 없다고들 하나?
MySQL은 데이터가 가지고있는 주체가 노드 하나임.
반면 MongoDB는? 분산클러스터를 위해 설계된 노드이다. (물론, 단일노드나 replica 복제용도로 사용하는 클러스터의경우 분산클러스터라고 말하기 조금 애매하지만..)
쨌든간에 그렇기 때문에, 분산되어 저장된 데이터들을 다룰때, 그러니까 multi-document를 다룰때에는, 비즈니스로직상 트랜잭션이 필요하다면 데이터 정합성 보장을 위해 2PC 프로토콜로 가능은함. 근데 오버헤드가 클뿐.
그래서 보통 이러한 multi-document를 다룰때, 하나의 one document로 합쳐서 저장하면 되겠지? 왜냐하면 단일 document의 트랜잭션 즉 atomicity를 보장하니까.
잠깐 카산드라 얘기
카산드라를 쓸때 클라이언트에서 처음부터 병렬로 multi node에게 write요청을 보내는 것은 아니고, 실제로는 coordinator node로 보내는데, 이 노드가 다수의 multi node에게 write요청을 건네주는 역할이다.
- client에서 쓰기 요청을 보낼때 coordinator 노드가 죽으면? client에서 retry를 함.
- 또, 개별 노드들에 write 요청 relay중에 죽어도 retry할 수 있게는 함 (coordinator노드가) (quorum 도 여기에 개입되나?)
- 복제노드가 죽은 경우에도.. hinted handoff통해서 다른 노드가 대신받고, 해당 노드가 살아났을때 data write함
잠깐 레디스 얘기
레디스는 cluster구조를 사용한다면, 전체 key-value 저장소를 16384개의 slot 내에서 관리함.
(단일은 하나의 node에 다 저장하는거겠지)
이렇게되면 수평으로 확장할때 hash-key값을 토대로 확장된 노드들에 slot이 할당되는 것
redis를 사용하는 입장에서는 이러한 전략에 맞게끔 key값을 조절하는게 맞다 ㅇㅇ
진짜진짜번외지만..
단일노드로 sentinel 사용하는 경우에, sentinel도 홀수개 이상으로 해야함 (과반수)
!!! 근데 mongodb는 노드들끼리 quorum에 의해 선출되므로 sentinel개념없다!
