관계형 데이터베이스와 NoSQL — 무엇을 고르고, 무엇을 기준으로 고르는가
저장소를 고르기 전에 정리해야 할 것들을 다룬다. 관계형 모델이 「관계」를 물리적으로 어디에 저장하는지, NoSQL 네 유형이 각각 무엇을 잘하고 못하는지, 그리고 제품 선택을 성능이 아니라 문제 해결·비용·유지·보수로 판정하는 이유다.
태그
9편
저장소를 고르기 전에 정리해야 할 것들을 다룬다. 관계형 모델이 「관계」를 물리적으로 어디에 저장하는지, NoSQL 네 유형이 각각 무엇을 잘하고 못하는지, 그리고 제품 선택을 성능이 아니라 문제 해결·비용·유지·보수로 판정하는 이유다.
선택지 열여섯 개가 각각 무엇을 얻고 무엇을 내주는지, 실패 모드 열한 가지가 어떤 증상으로 드러나고 무엇으로 되받는지를 표로 모았다. 파티셔닝과 샤딩, 복제, 분산 시스템, 합의에 걸친 서른두 개 문답은 먼저 답을 내고 근거를 뒤에 붙인다.
한 대의 서버 안에 있던 애플리케이션을 클러스터 위로 옮기는 구간을 다룬다. 소스가 이미지로 굳어 레지스트리를 거쳐 배포에 닿는 경로, 살아 있는지와 받을 준비가 되었는지를 갈라 보는 두 점검, 복제본을 늘리기 위해 치러야 하는 조건이 차례로 나온다. 마지막은 조직이 바뀌었을 때 코드를 건드리지 않고 데이터만 고쳐 대응하는 자리다.
여러 머신에 걸친 순간, 예산이나 기술로 밀어낼 수 없는 제약이 붙는다. 이 글은 분산 시스템이 어떤 장애를 상정하고 출발하는지, 완벽한 합의가 왜 불가능한지, 네트워크가 끊어졌을 때와 멀쩡할 때 각각 무엇을 내주게 되는지, 그리고 그 한계 위에서 장애 감지와 리더 선출과 결함 격리를 어떻게 배치하는지를 다룬다.
서버를 두 대로 늘리는 순간 세 가지가 동시에 깨진다. 트래픽 분배, 로그인 세션, 그리고 서버 간 메시지 전파다. 이 글은 앞의 둘이 왜 일반적인 문제이고 마지막 하나만이 WebSocket 고유의 난점인지, 그리고 브로커를 넣어도 남는 것이 무엇인지를 다룬다.
실시간 채팅 시리즈가 내린 판단을 세 벌로 다시 짠다. 아직 방식을 고르는 중이라면 선택지 표를, 이미 돌아가는 서비스에서 메시지가 안 오거나 연결이 끊긴다면 증상에서 출발하는 진단 표를, 근거를 설명해야 한다면 25문답을 쓴다.
알림센터 다섯 편의 지도다. 좋아요 한 번이 알림 한 줄이 되기까지 어떤 서버와 어떤 저장소를 지나는지, 그 경로를 왜 조회와 생성으로 쪼개고 사이에 브로커를 끼우는지, 그리고 「파티션」·「모듈」·「이벤트」처럼 편마다 다른 것을 가리키는 낱말을 이 시리즈에서 어떤 뜻으로 쓸지를 먼저 정한다.
수평으로 자르기로 정한 다음의 질문은 무엇을 기준으로 자를 것인가다. Range·Hash·List·Composite 네 전략이 각각 무엇을 사고 무엇을 내주는지, 인덱스를 로컬로 둘지 글로벌로 둘지, 조각이 머신 경계를 넘는 순간 무엇이 되돌릴 수 없게 되는지를 다룬다.
데이터가 커졌을 때 손댈 수 있는 축은 나누는 것과 복사하는 것 둘뿐이다. 이 글은 그 지도를 먼저 그리고, 파티셔닝의 값어치가 조회 성능보다 운영 작업 쪽에서 나온다는 것, 그리고 수직과 수평이 각각 무엇을 노리는 분할인지를 다룬다.