mysql 빅데이터 설계 관련 질문입니다. 0 15 1,857

by lololala [DB 모델링/설계] mysql 설계 빅데이터 파티셔닝 [2018.11.28 13:29:24]


현재 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쪽으로 심도있게 공부하는게 처음이라 어떻게 설계해야할 지 막막하네요..ㅠㅠ

긴 글 읽어주셔서 감사합니다.

by 마농 [2018.11.28 13:47:08]

테이블 자체를 분리하는 것은 좋지 않습니다.
테이블 하나에 고객ID를 키로 지정하면 되는 문제입니다.
고객당 연간 43000 개의 레코드가 생성된다고 하셨는데?
이게 테이블이 하나인가요? 여러개 테이블 다 합친 것 아닌가요?
여러 테이블 중 건수가 많은 것만 파티션 하시면 될 것 같습니다.
예를 들면 고객정보 테이블은 건수가 150건인데 이걸 150개 파티션으로 나눌 이유가 없죠.


by lololala [2018.11.28 13:54:54]

1년에 고객당 한 테이블에 최대 43000개의 레코드가 생성될 수 있습니다.

기능으로는 SMS를 이정도를 보내고 내역을 쌓아두는 테이블이라고 생각하면 될 것 같습니다.

기능이 추가가되면 다른 테이블도 최대 43000개 까지는 안되더라도 하루에 많은 데이터가 들어갈 것 같아서요..ㅠㅠ

계산해보니까 1년에 최대 150 * 43000 개의 레코드가 들어가게 되는데,

파티션으로 나누어 insert/update/delete/select 하게되면 성능 상 느려진다던가.. 서버에 부하가 걸린다거나 하는 문제가 있을까요?

답변 주셔서 감사합니다.


by 우리집아찌 [2018.11.28 14:08:44]

파티션을 나눠야할게 아니라

PK =  현재쓰는 PK + 고객분류(150건) 으로 가져가셔야죠

모든 테이블을 파티션 150개로 가져가면 관리가 힘들어집니다.

 

 


by 우리집아찌 [2018.11.28 14:12:01]

추가로 파티션닝은 일반적으로 날짜위주로 합니다.

마리아DB는 복합파티셔닝이 RANGE + HASH  또는 LIST + HASH 되므로 잘 선택하셔야합니다.

또 SQL에 파티셔닝키가 필수로 들어가지 않으면 성능에 큰 영향을 미칩니다.

 


by lololala [2018.11.28 14:30:35]

답변 감사합니다.

PK =  현재쓰는 PK + 고객분류(150건)  > 이 말이 무슨말인지 이해가 안됩니다.. ㅠ

users 테이블에서 auto_increament 로 사용하는 id로 고객을 분류하고,

CRM에서 필요한 테이블에서도 auto_increament로된 id 와 users 테이블의 id를 user_id 필드로 같이 PK로 해서 파티셔닝을 하려고 하는데, 파티션을 나누는게 아니라 그냥 통 테이블 한개로 쓰고 where을 통해 user_id로 가지고 오라는 말씀이신지요?

파티션을 나눠야할 게 아니라고 하셔서 질문드립니다..

안그래도 데이터가 많은 테이블인데 파티션을 나누지 않으면 CRUD 기능에 문제가 있을까 해서요..


by 우리집아찌 [2018.11.28 15:48:00]

파티션 테이블 쓰는 가장 큰 이유가 조회시 속도 저하 문제입니다.

현재 문제가 있으신가요?


by lololala [2018.11.28 15:51:53]

현재 설계중이라 작업을 시작하지 않았습니다.

차후 문제가 생길 수 있어서 미리 파티션을 만들어 예방하고자 합니다.

where조건으로 user_id를 줘서 조회하는 것과 파티션을 생성해서 파티션에서 조회하는거랑 성능상 다를게 없다면 우리집아찌님말씀처럼 파티션을 굳이 나누지 않아도 된다고 생각합니다.

근데 제가 DB에 대한 식견이 없어서 판단을 할 수 없는 상황입니다..ㅠㅠ


by 우리집아찌 [2018.11.28 16:04:41]

조회시 문제가 없는데 파티션 테이블을 사용하면 의미가 없습니다.

오히려 관리만 힘들어집니다.

앞에 적어두었지만 일반적으로 날짜(년/월/달/일 : 요건에 맞추어서)기준 으로 관리하고 

법적기준으로 관리해야할 데이터만 관리하고 삭제 또는 백업이나 이동하여

테이블 데이터를 일정하게 가져가는게 좋습니다.

 

 

 


by lololala [2018.11.28 16:10:42]

그럼 파티션 테이블은 조회시 문제가 있을 때 생성해서 대응하는 것인가요?

통 테이블 하나로 관리하려면 고객당 날짜로 나누려고 합니다.

감사합니다.


by 우리집아찌 [2018.11.28 16:28:04]

파티션 테이블을 가정해서 날짜로 나누워서 관리하라는 말이고요.

조회시 문제 없으면 상관없습니다. 굳이 파티션할 이유가 없어보입니다.

테이블 하나당 2000만건이 넘어갈것 같다고 하면 파티션 분리를 고려하세요.

 


by lololala [2018.11.28 16:39:13]

5년정도면 2000만건이 넘을 것 같은데.. 그냥 이 뒤에 생각해봐야겠네요..

답변 감사합니다.


by 마농 [2018.11.28 15:51:05]

단순히 데이터를 쌓기만 할 것인지?
조회도 필요한 건지?
조회 패턴이 어떻게 되는지?
1. 단순히 데이터를 쌓기만 할 것이라면?
 - 기간으로 파티션하고 주기적으로 과거 파티션을 삭제하는 방향이 좋을 것 같습니다.
 - 최신 데이터만 유지.
2. 조회도 해야 한다면?
 - 고객 위주로 조회가 된다면? -> 고객 파티션
 - 기간 검색 위주로 조회가 된다면? -> 기간 파티션


by lololala [2018.11.28 16:12:50]

데이터를 쌓고 CRUD 전부 수행해야합니다.

과거데이터도 계속해서 필요하여 삭제하는 방향으로 하면 안될 것 같습니다.

고객과 기간 같이 조회가 됩니다 ㅜㅠ

ex ) 해당 고객의 2017년 10월 01일~ 2017년 10월 30일 조회

이런식으로요...

답변 감사합니다.


by 우리집아찌 [2018.11.28 16:30:08]

과거 데이터 조회 요건이 있는지 알아보세요.

일반적으로 10년전 데이터를 조회하지 않습니다.

대부분 2년~5년 사이입니다.

마농님이 말씀하시는건 과거 파티션을 지우라는것이 아니라

현재 주 테이블의 파티션을 날리고 기존데이터는 백업하라는 의미로 보시면 됩니다.


by lololala [2018.11.28 16:42:15]

몇년단위일지 회의를 거쳐보아야겠네요.

두 분 답답하셨을텐데 답변해주셔서 정말 감사합니다.

댓글등록
SQL문을 포맷에 맞게(깔끔하게) 등록하려면 code() 버튼을 클릭하여 작성 하시면 됩니다.
로그인 사용자만 댓글을 작성 할 수 있습니다. 로그인, 회원가입