안녕하세요 Mysql로 현재 운영중인 database 구조 관련해서 조언을 구해보고자 이렇게 문의글 남깁니다.

서비스에 대한 설명을 드리자면 회원에 SNS(인X타) 계정을 연동하여 해당 계정의 여러 데이터정보들을 API 수집하여 수집테이블에 쌓고, 그 수집테이블에 데이터를 시간별로 집계하여 화면에 집계데이터를 통계로 보여줍니다.

현재 DB구조는 서버1대에 데이터베이스 : A, B, C 가있고 각 데이터베이스 안에 여러 table이 존재 합니다

A데이터베이스 : 웹에서 회원가입하고 계정을 연동하는 등의 CRUD가 이뤄지는 테이블들 (ex 회원정보 테이블과 연동된 인스타계정의 정보, 맵핑테이블 등)
B데이터베이스 : 연동된 SNS 계정의 데이터들을 API 수집하여 매시간 insert 되는 테이블들
C데이터베이스 : B데이터베이스에 적재된 시간단위 수집데이터를 집계하여 insert 되는 테이블들

간단히 설명드리자면 위와같은 디비구조를 갖고있는 통계성 웹서비스입니다.
다만 요즘 하고자하는것이 위 데이터베이스를 아래와같은 구조로 물리적으로 나눌 계획을 갖고 있습니다.

DB1서버 : 웹서비스에 필요한 프론트DB (A데이터베이스 + C데이터베이스)
DB2서버 : 수집을 담당하는 단일DB (B데이터베이스)

이유로는 크게2가지가 있습니다

첫번째 속도이슈인데 한 물리서버의 자원을 수집,집계,화면프론트 에서 다 잡아먹다보니 리소스를 많이 잡아먹는 특정 수집,집계시간대의경우 화면서비스 쿼리가 느려질수있음

두번째는 서비스의 성격에맞게 디비서버도 분리하기 위함입니다 (특히 수집) 예를들어 DB서버가 장애가 생겼습니다 그렇게됐을경우 수집이 정상적으로 진행이 안되겠죠 (집계야 수집데이터만 정상적으로 적재가되면 언제든 돌릴수있습니다.) 때문에 수집DB서버를 별개로 두고 좀더 수집서버에서 바라보는 데이터베이스를 특정지어 분리하기 위함입니다, 또 디비서버 이슈로 장기간동안의 디비를 내려놓고 점검을 할경우 수집은 별개로 돌릴수 있을것입니다

물론 물리적으로 디비가 나뉘면서 쿼리부분에서 수정되어야할 부분이 많을것으로 예상됩니다 예를들어 수집프로세스에서 나뉘어질 디비간에 존재하는 join관계, 집계시 사용되고있는 join관계 등 관계를 끊고 이러한 join역할을 했던 테이블을 자체DB에서 만들어 관리를 해야할것입니다.

설명을 드리다보니 정리도 잘 안되고 애매하게 설명된 부분도 있을것같습니다.
현재 운영중인 디비구조와 바꾸길 계획중인 디비구조중 어느구조가 더 서비스에 맞는 구조일지 그러한 조언을 좀 부탁드리겠습니다.

감사합니다