[뒤끝팁] 효율적인 데이터 저장을 위한, DB 기초 지식

안녕하세요, 개발자 여러분! 게임 서버 뒤끝입니다.

뒤끝은 ‘누구나 게임 서버를 사용할 수 있게 하자!’를 목표로 서비스를 운영하고 있습니다.
실제로 서버와 데이터 베이스 구조를 처음 접하시는 개발자 분들도 뒤끝을 많이 이용하고 계시는데요😊 

낯선 DB(Data Base)이지만, 이를 잘 구성하고 잘 만들어 나가는 것이 아주 중요합니다.

오늘은 이런 개발자 분들을 위해서 데이터베이스와 관련된 기초 지식과 데이터베이스를 효율적으로 저장하는 방법에 대해 알아보겠습니다.

목차

✅ 데이터베이스(Data Base)란?

데이터베이스는 표(테이블)로 구성되는 데이터의 집단을 의미합니다.
예를 들어 유저정보를 저장하고, 이를 표로 저장했다면 이를 유저 정보 DB(데이터베이스)라고 부릅니다.

DB의 형태를 이해하기 쉽도록, 아래와 같이 표로 나타내 보았는데요😊

유저 정보 테이블 예시

  ▲ 유저 정보 테이블 예시

여기서 테이블의 가로축은 레코드, 세로축을 컬럼으로 표현합니다.

주로 데이터는 레코드를 기준으로 생성되고, 그렇기 때문에 데이터가 쌓일수록 테이블은 세로로 길어지는 경향이 있습니다. 예를 들어 회원 수가 늘어난다면? 테이블이 세로로 길어질 거예요🤏

DB의 컬럼과 레코드

▪️ 테이블 : 표 형태(가로와 세로)로 구성된 데이터
▪️ 레코드 : 테이블에서 개별 가로축
▪️ 컬럼 : 테이블에서 개별 세로축

여기서 레코드는 데이터를 삭제/추가할 때 단위로 사용될 수 있고, 컬럼은 테이블에 실제로 입력될 정보의 데이터 타입과 양식을 정의합니다.

데이터 타입에 관하여 ···

지금까지 테이블, 레코드, 컬럼에 대한 기본적인 내용을 알아보았는데요 👀
이제는 위에서 설명드린 ‘컬럼’을 생성할 때 필요한 ‘데이터 타입’이라는 것에 대해 알아보겠습니다.

데이터 타입은 컬럼에 입력될 값의 규칙을 의미합니다. 
효율적인 DB 활용을 위해서, 알맞은 데이터 타입을 선택하는 것은 필수입니다.

적절한 데이터 타입을 설정하면 테이블의 사이즈를 줄이고, DB 쓰기 속도를 증가시킬 수 있어요!
그리고 뒤끝에서 이런 효율적인 관리는, 곧 DB 요금 절감으로 이어집니다.

예를 들어 라이브 중인 게임에서 '유저의 이벤트 참여 여부'를 관리해야 하는 상황을 가정해 봅시다.
이때, 목적에 알맞은 데이터 타입은 아래 이미지 토글의 'boolean'이 될 수 있습니다. 

💡깨알 지식: boolean 타입은 참(true)과 거짓(false)으로 값을 출력합니다.

*뒤끝 콘솔 > [게임 정보 관리] > [데이터] 탭 상단의 ‘행 생성’ 기능을 클릭해 주시고, ‘컬럼 생성’을 클릭하면,
아래와 같은 화면을 보실 수 있어요.

🚨뒤끝을 막 시작하신 분은, 뒤끝 콘솔 > [게임 정보 관리] > [테이블] 탭에서 데이터를 삽입할 테이블을 먼저 생성해 주세요!

컬럼 생성 시 선택하는 데이터 타입

➕ 부록

DB 요금을 더 줄일 수 있는 방법이 있을까요?

① 한 테이블에 많은 내용을 저장하지 않습니다.

뒤끝의 DB 쓰기 요금은 용량/처리 수에 따라 결정된다는 사실, 알고 계셨나요?

간혹 편의를 위해서 한 테이블에 많은 데이터를 입력하시는 경우가 있습니다. 그런데 한 테이블에 많은 내용을 저장하는 것은, 아래 이유로 아주 비효율적입니다.

UserData 테이블에 스킬, 장비 데이터를 모두 함께 저장한 경우
스킬 데이터만을 저장해 DB에 쓰기를 시도하는 경우라도 장비 데이터까지 함께 쓰기 처리를 진행하여 높은 처리량이 발생하게 됩니다.

이 경우 다음과 같은 해결방법을 추천드립니다.

스킬, 장비 데이터를 각각 SkillData, EquipData 로 테이블을 나누어 분리하기 
필요로 하는 데이터만을 저장하여 관리하기에 각각 개별적으로 쓰기 처리가 이루어지며 불필요한 처리량이 발생하지 않습니다.

즉 여러 내용을 하나의 테이블에 한꺼번에 저장하면 불필요한 쓰기 처리량이 발생하게 되므로,
각 컬럼의 데이터 크기가 크고 데이터 변화가 잦게 일어난다면 테이블을 별도로 분리하는 것을 추천드립니다.

② 데이터를 길게 저장하지 않습니다.

뒤끝의 DB 요금은 저장된 데이터의 글자 수에 비례하여 발생합니다.

게임에서 DB를 다음과 같이 저장하는 경우를 가정해보겠습니다. 

아래와 같이 ‘풀어 적는 방식’의 표기는 관리하기 쉽고 데이터를 알아보기 쉽지만
레코드의 글자 수는 62자로, 다소 많은 DB 요금이 발생할 수 있습니다.

DB 레코드 표 긴 버전

이때, DB 요금을 줄이기 위해서 다음과 같이 개선해 볼 수 있습니다.

첫 번째 테이블에서 62자였던 글자 수를 21자로 3분의 1가량 줄여보았습니다.
이렇게 내부 데이터 저장 양식을 규정하고 관리한다면, 줄어든 글자 수만큼 DB요금도 줄일 수 있습니다.

DB 짧은 레코드 표

오늘은 데이터베이스 기초 지식과, DB 요금을 줄이는 방법을 소개 드렸는데, 어떠셨나요?😊 
관련해서 궁금한 점이 있으시다면 언제든 댓글로 남겨 주세요.

오늘의 글이 개발자 님의 게임 개발과 운영에 보탬이 되기를 바라면서,

이만 마치도록 하겠습니다. 감사합니다.

6

댓글