현재 1개의 관리자 사이트와 약 150명의 고객이 사용될 CRM 홈페이지를 제작중입니다.
현재 CRM 홈페이지는 관리자 사이트에서 계정을 만든 후 로그인으로 분리처리하여 DB에서
테이블명_{users 테이블 primary key} 로 테이블을 나누어 설계를 했는데,
이렇게 하다보니 게시판이나 sms 내역 관리, CRM 내의 필요한 기능이 추가가 될때마다 테이블이 *150개로 늘어나는겁니다..ㅜㅜ
여기저기 찾다가 그냥 하나의 테이블로 데이터를 넣고 파티셔닝을 하라는 글을 보았는데,
만약 이 경우로 하게 됐을 때
관리자 페이지에서 생성했을 때 들어간 primary key로 파티션 by list를 해서 나누면
파티션이 150정도가 됩니다.
한 파티션 당 레코드가 1년에 최대 43000개 정도가 들어갈 수 있는데..
이렇게 되면 1년에 테이블에 레코드가 총 43000 * 150 개가 됩니다.
이 DB가 있는 서버의 용량은 300GB 정도가 여유가 있는데..
이렇게 파티셔닝 했을 때 성능면에서 문제가 없을까요?
현재 mysql / myisam 엔진을 쓰고 있습니다.
insert / update/ delete / selete 모두 골고루 사용하게 되는데 일단 대용량의 데이터를 다루어야해서
해당 테이블은 innoDB를 쓰려고 합니다.
(현재 mysql 5.7버전 사용중, 나머지 테이블은 모두 myisam 엔진 사용중입니다.)
혹시 더 나은 설계가 있을까요..?
웹개발만 해서 DB쪽으로 심도있게 공부하는게 처음이라 어떻게 설계해야할 지 막막하네요..ㅠㅠ
긴 글 읽어주셔서 감사합니다.
1년에 고객당 한 테이블에 최대 43000개의 레코드가 생성될 수 있습니다.
기능으로는 SMS를 이정도를 보내고 내역을 쌓아두는 테이블이라고 생각하면 될 것 같습니다.
기능이 추가가되면 다른 테이블도 최대 43000개 까지는 안되더라도 하루에 많은 데이터가 들어갈 것 같아서요..ㅠㅠ
계산해보니까 1년에 최대 150 * 43000 개의 레코드가 들어가게 되는데,
파티션으로 나누어 insert/update/delete/select 하게되면 성능 상 느려진다던가.. 서버에 부하가 걸린다거나 하는 문제가 있을까요?
답변 주셔서 감사합니다.
답변 감사합니다.
PK = 현재쓰는 PK + 고객분류(150건) > 이 말이 무슨말인지 이해가 안됩니다.. ㅠ
users 테이블에서 auto_increament 로 사용하는 id로 고객을 분류하고,
CRM에서 필요한 테이블에서도 auto_increament로된 id 와 users 테이블의 id를 user_id 필드로 같이 PK로 해서 파티셔닝을 하려고 하는데, 파티션을 나누는게 아니라 그냥 통 테이블 한개로 쓰고 where을 통해 user_id로 가지고 오라는 말씀이신지요?
파티션을 나눠야할 게 아니라고 하셔서 질문드립니다..
안그래도 데이터가 많은 테이블인데 파티션을 나누지 않으면 CRUD 기능에 문제가 있을까 해서요..