mongoDB의 참조무결성 제약

alpharegulus님 안녕하세요

좋은 질문입니다.

Mongo 같은 NoSQL 디비에서는 엄격한 스키마가 지원되지 않을뿐더러 참조무결성 또한 지원하지 않아요. 관계형처럼 엄격하진 않지만 백엔드에서 잡아주죠.

Mongoose로 생성한 스키마로도 사실 완전한 데이터 일관성을 보장할 수 없지요. MongoDB Compass 혹은 다른 클라이언트로 들어와서 다른 형태로 데이터를 수정할 수 있겠죠. 그리고 같은 백엔드에서 Schema를 업데이트하고 배포하면 새로운 데이터는 변경되는 스키마에 맞게 수정되겠지만 과거 데이터는 기존 스키마로 그대로 유지되어서 일관성이 깨지게 되죠.

NoSQL에서의 디비란 복잡한 데이터 구조를 저장, 수정, 탐색을 빠르게 할 수 있도록 해주는 역할이에요. 데이터 일관성(스키마), 참조무결성 등 이런 부분들은 백엔드의 역할로 넘어가고요.

그래서 개발자 본인들이 책임지고 일관성을 유지해줘야 합니다. 스키마를 업데이트 했다면 스크립트를 돌려서 과거 데이터들도 업데이트 해줘야할거고요. 다른 외부 클라이언트가 데이터 수정을 못하도록 해야할거고요. 느슨한 일관성이라고 할 수도 있겠네요

그에 반면 관계형 디비에서는 참조무결성, 데이터 일관성까지 모두 디비가 담당을 하게 되버리죠. (프러덕션에서 데이터가 많이 축적된 테이블 구조를 수정한다면? 엄격한 일관성을 보장하는만큼 몇분에서 몇시간까지 디비 서버가 중단될 수도 있어요.)

그래서 사실 관계형 디비가 처음에 시작은 어렵지만(테이블 생성, foreign key 연결, cascade 설정, M:N관계를 위한 추가 테이블 등) 개발자한테는 훨씬 편한 데이터베이스에요. 다만 고객들이 불편함을 느낄 수 있겠죠.(스키마 변경 시 서버가 먹통이 되는 현상, 데이터가 많아지면 느려지는 현상들, 빠르게 스키마 개선을 못해서 개발 속도가 느려지는 현상)

몽고 같은 디비들은 초반에는 더 쉬워보이지만 프러덕션에서 신경써야할 부분들이 더 많아지죠. 그럼에도 불구하고 몽고 같은 디비가 많이 사용되는 이유는? 개발자가 조금 고생하더라도 유저경험을 살릴 수 있기 때문이에요.

만약 데이터 일관성, 참조무결성을 디비단에서 필수적으로 지원을 해야한다면 관계형 디비를 사용해야겠죠. 하지만 제 경험상 설계의 문제라고 봐요. 이커머스를 어떻게 몽고로 개발하냐라는 소리를 예전에 많이 들었는데 찾아보면 해외에서는 이커머스뿐만 아니라 다양한 대규모 서비스들을 몽고로 개발하고 있었어요. 저 또한 성공적으로 개발했었고요. 

그리고 몽고디비의 느슨한 혹은 점진적 일관성을 쉽게 관리할 수 있는 좋은 아키텍처가 있습니다. Event Driven Architecture(EDA)라고 보통 MSA개발할 때 많이 사용되요. 마이크로 서비스 간에 request/response형식으로 통신하는게 아니고 이벤트 생성/구독으로  비동기 통신을하게 됩니다. MSA로 전환을하게 되면 서비스마다 각자 독립된 디비를 사용하기 때문에 관계형 디비라고 하더라도 전체 서비스 관점에서 보면 엄격한 일관성, 참조 무결성이 불가능해져요. 그래서 eventual consistency 개념이 들어옵니다. EDA는 모놀리스에서도 충분이 사용 가능해요! 프론트엔드에서는 사실 EDA가 이미 대중화되어 있죠. global state management(mobx, redux, context, recoil)를 사용하는 아키텍처가 EDA와 매우 흡사합니다. EDA 사용 경험이 너무 좋아서 대중화를 원하는 사람 중 한명인데요. 보일러플레이트와 EDA를 정말 쉽게 빠르게 시작할 수 있도록 해주는 라이브러리를 하나 준비하고 있는데 궁금하시면 참고만 해보세요. 아직 업데이트 안된 부분들이 많아서 프러덕션에서 사용하기에는 무리가 있을거에요.(보일러플레이트와 특히 전반적으로 문서가 부족)

ref 관련해서는 워낙 유명한 기능이라 강의에서 소개했지만 전 GraphQL을 사용하고 있어서 ref를 사용하진 않아요. GraphQL에서 관계된 데이터는 어짜피 populate로 불러오지 않고 dataloader로 불러오고 있어서요.(사실상 populate랑 같은 기능).