여러 고객사 페이지를 제공하는 통합 서비스 DB 설계관련 질문

Question

안녕하세요 선배님들,다름이 아니라 DB 설계에 대한 궁금증이 있어서 글을 남기게 되었습니다.[목적] 한 개의 통합 사이트에서 고객사별로 도메인 또는 코드를 사용해서 고유한 ID를 지정하고, 통합된 서비스지만 고객사별로 독립된 계정관리/게시글 관리 등을 사용하고자 함, 통합 사이트의 관리자 페이지에서 각 사이트에 대한 정보를 조회/관리/삭제 하고자 함[질문] 현재는 각 테이블에 고유 id 컬럼을 추가해서 crud과정에 사용하고 있습니다. 하지만 각 고객사별 데이터가 많아지는 것을 고려해야 합니다. DB 자체를 각 사이트 별로 분리하는 것이 어떨까 생각하고 있습니다. 이 경우 독립성은 보장되지만 유지보수와 업데이트에 따른 관리의 어려움이 있다고 생각합니다.(멀티 테넌시, 샤딩 등의 키워드로 자료를 찾아보았습니다.)테이블 자체에 고유id를 덧붙여 샤딩과 유사한 방식으로 구현해보는 것은 어떨까 생각하고 있습니다. 이 경우 과도하게 많아지는 테이블로 인해 유지보수가 어렵지 않을까 생각합니다.통상적인 서비스(예를 들면 메일플러그, 협업 툴)에서는 어떠한 방법론을 주로 사용하고 있을까요? 1,2 번 혹은 현행 방식(테이블에 컬럼 사용) 중 적합한 방법이 있는지 궁금합니다.작은 사이트 단위로 설계하고 공부하는 과정이라 위에 대한 자료를 찾기에 어려움이 있습니다. 내용을 설명하는 것이 올바르지 못했을 수도 있습니다..ㅠㅠ 요약하자면 한 개의 통합된 사이트에서 고객사별로 사이트를 open 해주고 각 고객사들이 사이트를 독립된 서비스를 사용하는 사이트의 DB 설계 방법론에 대한 내용입니다.감사합니다..

장독깨기 · Accepted Answer

고객사 각각에 별도의 서비스를 제공한다 하더라도 데이터베이스를 분리하지 않습니다.무슨 서비스를 해서 트래픽이 얼마나 될지 모르겠지만, 웬만한건 데이터베이스 하나로 다 처리 가능합니다.그리고, 혹 데이터가 많아져 성능에 문제가 생긴다면 일차적으로 고객사별로 파티셔닝을 하면 될 것 입니다.너무 걱정마시고 데이터베이스 하나로 처리 해보세요. :)

캐티 · Answer

스키마 사용. mysql에 존재하지 않는 기능입니다. 데이터베이스를 분리할 수 있을 것입니다. 그러나 일괄 조회가 필요한 상황에 별로 유리하지 않습니다. 이런 기능이 없어도 임대형 솔루션 개발이 가능하여요.파티셔닝 사용. 데이터를 분리하면 처리 효율이 좋아집니다. 직관적이지 않으면 개발이 쉽지 않는 문제가 있습니다.고유키 외래키를 기준으로 나눈다. 일반적으로 이렇게 구현합니다. 이렇게 하면 고유키 기준으로 파티셔닝을 할 수도 있을 것이고 일괄 조회도 가능할 것입니다.그러므로 고객사 테이블의 기본키를 외래키로 연결하여 사용하는 것이 가장 좋을 것입니다.

더미 · Answer

비용문제지 성능문제인 경우는 별로 없습니다

여러 고객사 페이지를 제공하는 통합 서비스 DB 설계관련 질문

3개의 답변

기술 목록