-
질문 & 답변
카테고리
-
세부 분야
백엔드
-
해결 여부
미해결
몽고디비와 mysql을 연결할 수 있을까요?
21.07.31 16:52 작성 조회수 2k
1
운동관련 서비스를 만들면서 사용자가 작성한 운동종목만 따로 가져와서 포스팅하려고 하는데
이를 위해서 mysql과 몽고디비를 연결해서 사용하고자 합니다. mysql에서 사용자가 작성한 운동종목 데이터만 몽고디비로 가져올 수 있을까요? sequelize와 mongoose를 사용하여, 또는 두 개의 디비를 connection하는 방법이 궁금합니다.
답변을 작성해보세요.
1
김시훈
지식공유자2021.08.02
젊음의돌님 안녕하세요 :)
재밌는 프로젝트 하고 계시네요. 여러 데이터베이스를 사용하는 것 자체는 전혀 문제가 되지 않아요. 그냥 특별한 작업 없이 각각 연결해서 사용하시면 되요. 데이터를 옮기는건 간단하게는 그냥 노드 서버에서 간단한 스크립트를 짜서 옮겨주는 방법이 있을 것 같아요. 실시간성이 아니라면 배치를 돌려도 될 것 같고요. 좀 많이 복잡하지만 고급스러운 방법으로는 Apache Kafka 같은 도구를 활용한 Event Driven Architecture를 구축하는 방법이 있어요. 쉽게 말하면 MySQL에 쓰기/수정을 할 때마다 이벤트를 발생시키고 다른쪽에서는 해당 이벤트들을 구독해서 MongoDB에 복제하는 방법이에요.
근데 무엇보다 굳이 두개의 데이터베이스를 이렇게 사용하시려는 이유를 알 수 있을까요? 그러면 좀 더 좋은 답변을 해드릴 수 있을것 같아요 :)
젊음의돌
질문자2021.08.02
답변 감사드립니다. 강의 마지막 부분에 관계형 데이터 베이스와 몽고디비에 대해서 잘 설명해주셨는데요, 현재 사용자 운동 기록(ex>팔굽혀펴기 3세트 10회.)를 저장하는데 있어서 자유로운 수정 삭제로 기록이 가능합니다. 이 부분은 SQL로 사용하고자합니다. 다른 부분은 사용자가 자신이 작성한 운동기록을 공유할 수 있는 블로그 게시판을 만드는데 이 블로그 게시판은 삭제만 가능하고 수정은 되지 않도록해서 문서처럼 쌓아놓고 빠르게 READ하는게 중요할 것 같아서 몽고디비로 구축하고자했습니다. 1. 데이터의 성격에 맞게 SQL과 몽고디비로 구분이 된게 맞을까요? 2. 언급하신 것처럼 두 개로 구축하기보다 하나로 구축하는게 맞을까요? 강의 내용에서보면 애매한 경우 관계로 먼저 만들라고 하셔서 관계형으로 구축하고 몽고디비로 확장하는게 맞을 것 같은데, 아니면 이러한 경우엔 몽고디비 하나로 데이터 베이스를 구축하는게 나을까요?
김시훈
지식공유자2021.08.02
아하 이해했습니다. 애매한 경우 관계형으로 하라고 권했던건 "몽고디비에서 관계형 디비처럼 정규화해서 데이터를 관리하자"를 말한겁니다! 강의 초중반즘에 설명드렸던 populate를 이용한 방법이요. populate가 성능이 안좋은 것처럼 말했지만 문서로 내장하는거에 비해 안좋은거지 populate도 충분히 좋고 프러덕션에서 자주 사용되요. 관계형 데이터베이스처럼 초반에는 여러개의 컬랙션으로 쪼개고 나중에 느려지거나 자주 사용되는 쿼리들이 있으면 점진적으로 내장을 해주시면 되요. 특수한 경우가 아닌 이상 메인 디비는 하나만 사용하시는걸 권장해요. 관리가 매우 어려워지거든요.
추가로 디비를 사용하는 경우는 제일 흔하게는 레디스 같은 메모리 디비가 있을 것 같아요. 데이터 손실이 있어도 되지만 대신에 더 빨리 불러오고 싶은 특수 케이스요. 요청마다 확인해야하는 유저 세션 정보를 빨리 불러오고 싶을 수 있기 때문에 레디스 같은 메모리 디비에 저장하는 경우가 있어요. 혹여 메모리 상의 세션 정보가 손실 되었다고 해도 서비스상의 큰 장애가 발생하지는 않겠죠. 그냥 로그아웃 처리만 될거니깐요.
젊음의돌
질문자2021.08.02
네 빠른 답변 감사드립니다. 제대로 이해한 것인지 모르겠지만 우선 컬렉션으로 쪼개고 populate로 관계를 맺어서 업데이트 명령어를 넣어 수정 삭제도 해결하면 되겠네요. 한가지 더 추가 질문 드리면 몽고디비에서 도큐먼트 내부에 서브도큐멘트 같은 경우 도큐먼트와 연결된 테이블을 만드는 개념으로 이해하고 있는데요, 서브도큐먼트를 사용하면 도큐먼트 내부 서뷰도큐먼트도 읽어와야되니까 불어오는 시간이 늘어날까요? 아니면 서브도큐먼트는 어떤 경우에 써야할까요?
김시훈
지식공유자2021.08.02
네 맞아요 내장하는건 연결된(관계된) 테이블을 만드는것과 유사해요.
다만 하나의 문서로 (JOIN된 상태를 통째로) 저장을 하기 때문에 읽기가 매우 빨라지죠. 문서 크기가 메가바이트 단위가 아닌 이상 단순 파일 읽기이기 문서가 커져도 속도의 변화는 없다고 볼 수 있어요. 내장된 문서들이 메가바이트 단위로 엄청 많아지면 물론 느려질 수 있어요.
그래서 그렇게까지 커지도록 두지 않죠. 강의에서 blog에 comments를 내장했었는데 최종버전에서는 모든 comments를 내장하지 않았어요. 최신 10개? 정도만 내장을 하고 나머지는 pagination처리를 했어요. 따라서 문서가 제약 없이 커지지 않아요.
하지만 일반적인 수준에서는 관계형 디비에서 JOIN을 하는데 소요되는 시간이 큰 문서를 읽는 것보다 크다고 볼 수 있어요. 데이터가 많아짐에 따라 어느 정도 비례해서 JOIN 비용이 상승하기 때문이죠. 문서 크기는 우리가 제한할 수 있지만 JOIN 과정에서 탐색해야할 데이터양은 저희가 제한 할 수가 없으니깐요.
내장(subdocument)을 하는 경우는 JOIN을 자주 할 데이터들이에요. 한 운동 기록에 여러가지 운동, 각 운동의 횟수 그리고 운동한 사람의 기본적인 사용자 정보 같은걸 같이 저장해주면 좋겠죠.
그리고 내장 vs 개별저장이 아니에요. 상황에 따라 하나만 해도 되고 둘다 해도 되요. 강의에서 comments, user를 blog에 내장하기도 하고 따로 저장하기도 했었던것처럼요.
그리고 내장을 했다고 해서 수정을 못하는건 더더욱 아니고요! MongoDB의 장점 중 하나가 복잡하게 내장된 문서들도 쉽게 Update할 수 있다는거니까요.
답변 1