매월 늘어나는 빅데이터로 인해서 MySQL DB 용량은 점점 늘어나고 있습니다.
7년전에 이미 예상했던 부분이기에 크게 놀랍지는 않습니다.
그 당시 월단위로 20GB씩 늘어났었으며 1년에 240GB를 사용할 경우 10년에 2400GB를 확보하면 된다는 마인드로 2TB SSD를 구입하여 사용해왔습니다.
2TB SSD를 이용할 경우 대략 10년 정도 버틸 수 있다 생각했었죠.
실제로 용량은 그보다 더 많이 늘어났습니다.
이미 쌓인 DB를 바탕으로 더 많은 수집 정보로 인해서 용량은 거대해지게 되었죠.
안되겠다 싶어서 MySQL OPTIMIZE 등등 다 해보았지만 근본적으로 물리용량까지 줄일 수는 없었습니다.
지금은 아래 테이블을 보시다싶이 1개월 단위로 용량이 눈에 띄일 정도로 많이 줄어든 상태입니다.
제가 사용한 방법은 INDEX를 없애버린겁니다.
인덱스가 사라지니깐 속도는 느리지만 더 많은 용량을 확보하여 하드웨어 비용적인 부분에서 절약이 많이 되었습니다.
20GB -> 2GB로 확 줄어버리니 10년의 기간이 100년으로 늘어나게 된거죠.
대신 어떤 데이터를 찾을 때 매우 느리다는것만 감안한다면 뭐 그리 큰 문제는 아니였습니다.
용량을 줄여놓고보니 이번에는 가상화 VM 구조로 운영을 할 수 있게 되었습니다.
그래서 200GB정도면 10년치를 확보 할 수 있겠다 싶어 잘 운영하고 있었죠.
그런데 이미 7년이 넘어가는 시점에 도달하였고 역시 200GB 용량으로는 한계점이 오게되어 물리적인 용량을 늘려야 하는 시기가 또 다다르게 된것입니다.
이번에는 조금 다른 생각을 하게되었습니다.
기존에는 INDEX 컬럼을 삭제했다면 이번에는 물리적으로 ROW를 줄여보자는 마음이 생기더군요.
처음부터 약속을 하는거죠.
기준치에 미치지 못하는 경우에 대해서는 그냥 일괄 수집을 하지 않는 방법입니다.
이 알고리즘은 아니 알고리즘이라고 말하기도 힘들죠. 그냥 방법론인거죠.
처음에 몇가지 상태를 지정해놓고 그 상태를 바탕으로 기준에 미치지 못하면 ROW를 넣지 않고 기준에 부합할 경우에만 INSERT 시키는 방법입니다.
이렇게 할 경우 제가 기준을 얼마나 높이냐에 따라 수집되는 데이터는 줄어들게되죠.
대신 정확도는 점점 떨어지게됩니다.
높은 수치를 지정해놓게되면 그 이하 수치는 모두 수집을 하지 않게 되니 정확도가 그만큼 떨어지게되죠.
하지만 정확도와 무관하게 숫자가 0부터 1만까지가 있을 경우 0과 1은 큰차이가 생기지 않기에 0과 1을 제거 할 경우
ROW갯수는 엄청나게 차이가 나게됩니다.
크기 2.3GB 용량의 테이블 크기가 463.3MB 만큼 확보를 할 수 있게 되었습니다.
바로 1에 대한 부분을 0과 퉁 쳐버린거죠.
이제부터 0과 1은 같다 생각하고 1로 수집하는 모든 경우의 수를 배제해버리게 되죠.
1개월에 0.5GB 정도의 용량을 확보 할 수 있다면 1년에 5기가를 확보하게 되는것입니다.
10년이면 50기가가 되는거죠.
MYSQL 테이블 데이터베이스 용량 줄이기
1. 필요없는 INDEX를 삭제한다.
인덱스 삭제는 신중해야합니다. DB속도를 좌지우지 하기 때문이죠.
속도에 큰 문제가 없다 생각되면 삭제 하셔도 됩니다. 이때에는 ROW갯수가 100만개가 안 넘을 때 가능하죠.
ROW갯수가 100만개가 넘어간다면 INDEX 설정은 어찌보면 필수일수 있습니다.
테이블 갯수를 더 쪼개고 인덱스를 지우는 방법도 한번 생각해보세요.
2. 필요없는 ROW를 삭제한다.
저는 이미 인덱스는 삭제한 상태이며 이제는 ROW 갯수를 줄여가는 중입니다.
지금은 1을 수집하지 않고 있지만 앞으로는 10이하를 수집 하지 않을 수도 있습니다.
그렇게 되면 용량이 더 많이 확보되겠죠.
10이하를 삭제할 경우 만약2GB용량이 200MB 정도의 용량이 된다면 과감하게 삭제 할 지도 모르겠습니다.
한번 10이하를 몽땅 삭제 해보아야겠네요.
Query OK, 22289399 rows affected (15 min 9.646 sec)
1을 삭제 했더니 22,289,399개의 ROW가 삭제되었네요.
총 갯수가 7천만개 정도 였으니… 대략 30%가 삭제된듯 합니다.
1,2,3,4,5 총 5개의 항목이니 5이하를 삭제할 경우 대략 처음대비 70%정도의 용량이 늘어날 것으로 예상됨니다.
명령어 입력을 잘 못하여 counter < 5 이렇게 넣었네요.
이미 1항목이 삭제된 상태였고 5미만 처리 해서 5가 포함되지 않아 2,3,4 이렇게 3항목이 추가로 삭제 되었습니다.
Query OK, 16883723 rows affected (10 min 33.614 sec)
16,883,723건의 ROW가 삭제되었습니다.
이번에는 아예 10 이하로 지정했습니다.
1,2,3,4까지 삭제된 상태가 31,608,565개라면 10 이하를 삭제 할 경우 5,6,7,8,9,10 이렇게 총 6개 항목의 ROW가 삭제됩니다.
Query OK, 9852316 rows affected (6 min 51.217 sec)
생각한 수치만큼 많이 삭제되지는 않았네요.
9,852,316건의 ROW가 삭제되었습니다.
OPTIMIZE TABLE `table name`;
만약 ROW를 삭제 할 수 없는 상태라면 이렇게 고민을 해보시기 바랍니다.
MAX 수치 또는 MIN 수치 값이 분명 존재할겁니다.
혹은 가장 많은 수치를 반복적으로 수집되는 ROW가 많이 있다면 그 ROW만 제거하는 겁니다.
그리고 제거된 날짜, INDEX 마다 체크하여 그 값이 존재한다고 가정하고 결과물을 만들어내는거죠.
그 하나의 통일된 ROW만 제거 되더라도 용량 확보가 엄청 많이 됩니다.
