데이터 요금감량에 대한 질문입니다

현재 재화를 담당하는 테이블 하나가 있는데

재화마다 컬럼이 새로 추가되는 형태입니다

gamer_id inDate owner_inDate updatedAt Diamond Gold Goods1
xxxxx-xxxxxx 2025-02-10T01:20:40.300Z 2025-02-14T01:23:42.222Z 400 7 0

이런 구조에요

근데 업데이트를 할때마다 재화가 추가되는일이 빈번해져서 어느덧 150개를 넘겼습니다

이러면 Gold를 하나 수정하는데 다른 150개의 재화에 대한 수정요금도 같이 지불되는걸로 보여서
테이블을 개선할 수 있을지 확인해보려고 하는데

image
이렇게 혹은
image
이렇게 바꿀 수 있을 것 같은데

이런 구조로 바뀌면 요금감량에 도움이 될지
그리고 추가적으로 DB용량은 좀 늘 것 같은데 그렇게 많이 늘어날지 궁금합니다.

지금까지 플레이한 유저들이 사용했던 테이블 데이터를
새로 개선한 형태로 변경해야 하는데 현재 뒤끝에서 제공하는 기능들로
충분히 가능할까요?

만약 개선했는데 별 차이 없거나 뒤끝에서 제공하는 기능들로 테이블 구조 개선이 불가능하다면
(gold:30,diamond :50,jade:20) 이런 형태로 하나에 몰빵하는 형태는 괜찮을까요

안녕하세요 개발자님,
보다 정확한 확인을 위해 프로젝트 정보 공유 요청드립니다.

메시지로 보내드렸습니다

확인 시 말씀해주신 것과 같이 다수의 컬럼이 존재하는 것으로 확인되며,
실제 데이터의 크기는 크지 않으나 컬럼명 데이터로 인해 1회 호출당 DB 쓰기 처리량이 약 6처리량 발생하는 것으로 확인됩니다.

말씀해주신 형태로 row를 여러개 가지도록 수정하는것도 가능한 부분이긴 하나,
이 경우 각 재화의 조회/사용에 대해 개별적인 호출비용이 발생하기에 DB 처리량을 감소시키는 과정에서 오히려 호출 비용이 과도하게 발생하게 될 수 있습니다.

데이터를 저장/조회 하는 호출의 구성에 따라 두 방법 모두 장단점이 있으나,
컬럼의 수가 워낙 많기에 현재의 구조를 유지하거나,
특정 항목을 기준으로 2~3개 가량으로 테이블로 분할 하는것도 방법이 될 수 있을것으로 예상합니다.

또한 하나의 컬럼 내에 간소화하여 저장하거나, 각 컬럼의 값을 키값으로 하여 처리하는 방법도 있으며
하나의 컬럼 내 저장하는 경우 컬럼명(키값)을 지금과 같이 사용하기보단 더 간소화하여 처리할 수 있으면 비용 절감에 도움이 될 것으로 예상합니다.
(주된 포인트는 컬럼 수/컬럼명 혹은 저장되는 데이터를 줄이는 것입니다.)

ex> EventDungeonGoods1, EventDungeonGoods2 의 컬럼에 각각 20, 5라는 값이 있다고 하였을 때, 다음과 같은 항법으로 컬럼수를 줄이거나, 데이터 크기를 줄이는 방법이 있습니다.

  1. EventDungeonGoods 컬럼(혹은 간소화한 EDG 컬럼)에 20|5 와 같이 저장하는 방법
  2. data(임의의 컬럼명) 컬럼에 다음과 같이 저장하는 방법
    {
    "EDG1" : 20,
    "EDG2" : 5
    }
    //또는 
    {
    "EventDungeonGoods" : 20|5
    }
    //또는
    {
    "EDG" : 20|5
    }
    

답변 감사합니다

저희가 실제로 서버에서 데이터를 호출하는 시점은
인게임에 접속해서 처음 데이터를 불러올 때이고

그 이후에는 데이터를 호출하는 작업은 상당히 드물다 보니까
쓰기로 발생하는 요금에 좀 더 초점을 맞추었습니다.

때문에 쓰기로 인한 요금을 줄이는 방향이 맞다고 봤고

처리되는 요금을 계산해 봤을때도
읽기 처리량은 4KB마다 1번씩 집계되고
쓰기 처리량은 1KB마다 1번씩 집계

읽기처리량은 1번 집계마다 0.0007원
쓰기 처리량은 1번 집계마다 0.003원이고

저희 프로젝트에서 1회 호출당 쓰기 호출량이 6번정도 발생한다고 하셨으니

계산해보면
(3 / 0.7) * 6 = 약 25.71

즉 저희 프로젝트를 기준으로 보면
읽기비용의 약 25.71배에 해당하는 요금이 현재 쓰기 비용으로 발생하고 있다는건데

따라서 컬럼을 많이 늘리고
테이블 구조를 개선하는것이 더 유리한게 아닌가요?

읽기/쓰기 처리량은 모두 데이터의 크기에 따라 발생하게되며 이 데이터에는 컬럼명 또한 포함됩니다.
읽고 쓰기를 진행할 때 특정 컬럼만을 조회하거나 수정한다 하더라도 row 전체의 처리가 이루어지기에,
실제 처리량을 감소시키고자 한다면 최대한 row 데이터의 크기를 줄여야합니다.

이를 위해서는 말씀드린것과 같이 다음과 같은 방법을 안내드린 것입니다.

  1. 컬럼수를 줄이는 방법 (비슷한 유형의 컬럼은 하나의 컬럼 내에 |와 같은 구분자를 두어 저장)
  2. 컬럼 명을 간소화 하는 방법
  3. 두가지 방법을 모두 사용하여 하나의 컬럼 내 모든 데이터를 저장하면서, 이 또한 간소화 하는 방법

row를 늘리는 방법을 추천드리지 않은 것은
row당 하나의 컬럼값을 가진다 하였을때 처리량은 1로 줄어들겠지만,
호출비용이 10처리량과 동일한 요금에 해당하기에 각 데이터를 개별적으로 조회/저장하는 방법의 비효율로인해 위 방법들을 안내드린 점 참고 부탁드립니다.

특정 레코드 하나를 inDate + where절로 써서 단 하나의 레코드만 Update처리하려고 해도
테이블에 담겨져있는 총 레코드수에 비례한 비용이 발생한다는 거군요

좋아요 1

네, 맞습니다!
row 전체를 기준으로 처리되기에 전체 데이터 크기를 줄이는것이 중요합니다.

좋아요 1

네 답변 감사합니다

좋아요 1