 안녕Ȣ16;세요.
MySQL 테1060;블 파티셔닝 관/144;해서 고0124;1473;1060; 내용1060; 1080;Ǻ12;서 1312;Ǻ16;1012; 구Ȣ16;고1088; 글1012; 남깁니다.
10년치 데1060;터 테1060;블1008; 연도별/196; 나누/140;고 합니다.
테1060;블 파티셔닝1060;라lj16;,172; 1080;Nj12;데, Range 파티셔닝1012; 1060;용해서 테1060;블 파티셔닝1012; 했1012;ǐ12;와
테1060;블1008; 단순7176; 한개1032; 기1456;1068;1088;를 1105;아서 연도별/196; 나누lj16;,163;과 비교를 Ȣ16;면 Ǻ12;떤 1109;단1216;1060; 1080;lj16;1648; Ƽ17;금합니다.
1. 테1060;블 파티셔닝
ListTable1060;라lj16; 1개1032; 테1060;블에 10년치 데1060;터를 넣고, 아래와 같1060; 관리Ȣ16;lj16; 0169;법
ALTER TABLE `ListTable` PARTITION BY RANGE (TO_DAYS(`regDt`)) (
   PARTITION P_2019 VALUES LESS THAN (TO_DAYS('2020-01-01')) ENGINE = MYISAM,
   PARTITION P_2020 VALUES LESS THAN (TO_DAYS('2021-01-01')) ENGINE = MYISAM,
   ......
)
2. 단순 테1060;블 나누기
ListTable_2019, ListTable_2020, ListTable_2021 ....
1060;런식1004;/196; 1204;ǥ12; 테1060;블1012; 만들고 데1060;터를 관리Ȣ16;lj16; 0169;법
위와 같1060; 했1012; ǐ12;, 만약 regDt 범위를 2019.05.01 ~ 2020.12.31 1060;/111;,172; ,160;색1012; 한다면
1번1032; ᅆ1;우 select * from ListTable where regDt between '2019-05-01' and '2020-12-31' 1060;/111;,172; 단순Ȣ16;,172; Ȣ16;면 .112;,163; 같1648;만
2번1032; ᅆ1;우 (select * from ListTable_2019 where where regDt between '2019-05-01' and '2020-12-31') UNION ALL (select * from ListTable_2020 where where regDt between '2019-05-01' and '2020-12-31') 1060;/111;,172; Ȣ16;lj16;,172; 맞lj16;1648;요?
1221;리를 Ȣ16;1088;면,
1656;문1. 테1060;블 파티셔닝과 테1060;블1012; 단순Ȣ16;,172; 나눴1012;ǐ12;1032; 1109;단1216;1060; Ǻ12;떤,172; 1080;lj16;1648; Ƽ17;금합니다.
1656;문2. regDt 범위를 2019.05.01 ~ 2020.12.31 1060;/111;,172; ,160;색한다면 1228;가 생각Ȣ16;lj16;,172; 맞lj16;,148;1648; Ƽ17;금합니다. 2번1032; ᅆ1;우 더 나1008;0169;법1060; 1080;lj16;1648;도 Ƽ17;금합니다.
https://velog.io/@ryuhyewon/%ED%8C%8C%ED%8B%B0%EC%85%98-%EC%9E%A5%EB%8B%A8%EC%A0%90
문서 참고하시면 될 것 같습니다.
테이블을 분할해
UNION ALL 을 사용해야 할 경우가 많다면 파티셔닝 하는 것을 추천 합니다.
데이터가 얼마나 많은지 모르겠지만 대용량이 아니면 파티셔닝도 하지 않아도 ...
1. 테이블 파티셔닝은 어플리케이션을 수정하지 않아도 되는게 장점이라고 생각합니다.
테이블을 단순하게 나누는건 어플리케이션이든 아니면 이벤트 스케줄러를 걸든 추가 작업이 필요하다는거.. 개발자는 빡세지만 어쨌든 눈에 보이는 관리라는게 장점인것 같고요.
2. 파티셔닝된 테이블은 생각하신 대로 쓰면 되고요.
단순하게 나눈 테이블도 그런식으로 하시면 됩니다. 복잡하죠...
그래서 대형 쇼핑몰(지마켓,11번가,쿠팡,등등등..) 모든 은행들 보시면 범위 검색이 제한적 일 수 밖에 없습니다.. 최근 몇달 또는 언제부터 언제까지 지정.
개인적인 생각으로 개발,서버,운영,기획,예산 등등 눈앞의 현실은 상황마다 다르기에 정해진 정답은 따로 없다고 봅니다.
가령 뭐 고성능/고용량 u.2 ssd 레이드 이빠이 묶는 식으로 즉, 하드웨어로 밀어 붙이는 것 또한 가능한 방법이 될 수 있죠
특정부분 검색할려고 하면 숨넘어갑니다. 그런데 이걸 테이블단위로 쪼개버리면 어플리케이션 단에도 코딩을 다시해야되는 문제가 생기게 됩니다.
그래서 테이블 파티션이란게 필요한겁니다.
검색범위가 파티션단위로 구분되다보니 성능이 훨씬 개선됩니다.
MySQL은 파티션까지만 지원되는지는 모르겠으나 MSSQL 기준으로 본다면 파티션 구분별로 압축테이블을 지정할수가 있고 테이터 날릴때도 파티션ID로 한방에 날릴수 있어서 유지관리하는데도 훨씬 용이합니다.
테이블파티션의 기준은 대용량이라는 기준과 성능과 유지관리에 있습니다.
그냥 테이블을 분리합니다
좀더 복잡하게하면 실시간 db용으로하고
이전 년단위 데이터는 다른 db에 넣어버리고
실시간 운영에 필요한 db는 복제 db만들어서 실시간 백업 db로 동기화합니다
장점은 복구가 필요할때 용량이 줄어들어서 몇분내로 한다는거 하나밖에 없습니다만
서비스용도는 이정도까지 해봤었네요