데이터 구조

DB를 설계하고 부하에 대해 고민한 내용을 정리한 글입니다.

 

 

https://www.voxels.com/play

In-world | Voxels

위 링크는 온라인 기반의 건축 게임 사이트의 링크 입니다.

마인크래프트 같은 형태로 블록들을 배치하고 디자인 하는 게임입니다.

 

위 게임을 둘러보던 중 궁금한 점이 생겼습니다.
게임내 월드에는 수많은 블록들이 있을 텐데 이를 데이터베이스에 어떻게 저장하고 있을까 하는 궁금증 이였습니다.

 

 

관계형 데이터베이스

블록하나를 하나의 ROW로 처리

우선 흔히들 사용하는 관계형 데이터베이스의 입장에서 생각 해봤습니다.

생성한 블록 하나당 하나의 Row를 가지고, 해당 블록의 xyz 위치를 기록하는 형태입니다.

 

| 블록A | 6 | -5 | -1 | 
같은 형태입니다. 
가장 간단하고 쉽게 데이터를 저장할 수 있고 추후 조회할 때 쿼리가 복잡해질 염려도 없어보입니다.

추가로 기본블록 이라는 테이블을 생성해서 기본 값을 정의하고 해당 블록의 id만 참조하는 식으로 처리하여

중복 데이터를 별도의 테이블로 분리할 수 있을 것 같습니다.

 

문제

위 방식은 별 고민 없이 쉽게 쉽게 문제를 해결 할 수 있지만 문제가 있습니다.

블록 하나당 Row가 하나씩 생긴다면 데이터베이스에 데이터가 과하게 많이 쌓일 것 같다는 생각이 듭니다.

 

아래 영상에서는 대략 100만 블록을 사용했다고 하는데

극단적인 예시 일 수 있지만 건축물 하나때문에 row가 100만개가 생길 수도 있는 상황입니다.

 

대량의 데이터가 무작위로 섞여있기 때문에 조회할 때도 부하가 상당할 것 같습니다.

user_id 혹은 block_id 등으로 인덱스를 걸어 나름대로 성능 이슈를 피해갈 수 있을 것 같습니다.

 

https://www.youtube.com/watch?v=CrdjKuedDs0

 

블록 생성시에는 블록 갯수제한 등으로 어느정도 예방이 가능하긴 합니다.

하나의 Object에는 블록을 n개 까지만 사용 가능 하다는 조건을 걸어두면 됩니다.

 

갯수제한으로 예방을 했다고 한들, 블록을 삭제할 때는 어쩔 수 없이 또 문제가 생깁니다.

논리적으로 삭제처리 할 수도 있지만 이때도 결국엔 모든 Row에 대해서 isDelete를 Update 해줘야 하는 것 입니다.

 

물론 Asset 이라는 테이블이 블록들의 집합 역할을 하고 Asset 테이블에서 isDelete true 처리 해도 큰 문제는 없습니다.

하지만 사용가능한 블록 갯수와 같은 정보를 반환해야 하는 API가 있다면,

Asset이 삭제되었는지 확인하고 삭제되었다면 해당 에셋에서 사용한 블록의 갯수만큼 더해준다. 

라는 불필요한 로직이 추가되어야 할 것 같습니다.

 

실제 모든 블록이 isDelete true로 Update되어있었다면 단순히 isDelete true인 값을 보유량에서 빼주기만 하면 되는 일입니다.

여러가지 방법으로 해결할 수는 있을 것 같지만, 근본적인 해결은 아닌 것 같아 여전히 찝찝합니다.

 

블록들의 위치와 정보를 하나의 컬럼으로 처리

이전에 하나의 Row로 블록하나를 처리했다면 이번엔 하나의 Row는 하나의 완성된 Object를 의미하도록 설계하는 형태입니다.

블록 100만개를 사용하여 건축물을 하나 만들었다면 이는 user_object 라는 테이블에 Row가 하나 생기는 형태입니다.

 

위 예시의 position 이라는 컬럼이 블록들의 위치와 정보를 담당하는 컬럼입니다.

미리 정해둔 형태의 데이터를 JSON으로 직렬화하여 String 형태로 저장하는 방법입니다.

 

유저들이 생성한 user_object 테이블에 하나의 Row가 생길 때 마다 하나의 건축물이 생기는 것이니 직관적이기도 합니다.

또한 object 삭제시에도 해당 Row하나만 삭제처리 하면 되는 것이기에 데이터베이스에 걸리는 부하도 크지 않을 것 같습니다.

 

문제

위 방법도 문제는 있었습니다.

우선 여러가지 값들을 JSON으로 통으로 저장하고 있어서 Join이 어렵습니다.

 

x,y,z 값들이야 Join할 일이 많이 없을 것 같아서 문제가 안되겠지만,color, type 등 블록들의 정보 관련 부분은 조인이 필요할 것 같습니다.

위 예시에서는 color라는 필드를 따로 두었지만 정규화를 위해 "기본블록" 이라는 테이블을 생성해두었다면 id값만 참조하여 데이터를 처리하고 있을 것 입니다.

이때 이미 JSON으로 되어있는 position 데이터를 서버에서 역직렬화 하고 이 값을 for문으로 돌려 블록 정보를 각 인덱스의 객체마다 집어넣어줘야하는 가공작업이 필요합니다.

 

만약 기본블록 테이블이 다른 테이블과 관계가 맺어져 있다면 위 방법으로는 처리하기가 어려울 수도 있습니다.

또한 위에서도 말했던 내용이지만 사용가능한 수량 조회 같은 API가 있다면 JSON으로 되어있는 데이터 특성상 Sql로 처리하기가 힘들 것 같습니다.

 

또한 직렬화와 역직렬화는 리소스 소모가 큰편이라고 알고 있습니다.

반복 요청에 대해서는 캐싱처리 해서 소모를 조금 줄일 수 있겠지만 근본 적인 해결책은 아닌 것 같다는 생각이 듭니다.

 

 

NoSQL 데이터베이스

이 경우에는 RDBMS 보다는 나은 상황입니다.

정형화된 구조가 없으니 배열을 사용하여 길이제한 없이 값을 저장할 수 있습니다.

 

아래는 NBT ( Named Binary Tag )라는 형태의 데이터이고, 마인크래프트 내의 각종 데이터를 저장하는데 쓰이는 형식입니다.

{
  "Chunk": {
    "x": 0, "y": 0, "z": 1,
    "Blocks": [
      {
        "Position": { "x": 0, "y": 0, "z": 1 },
        "Type": "Stone",
        "State": "Intact"
      }
      // 기타 블록 정보
    ]
  }
}

 

Chunk라는 블록들의 집합에 블록들을 배치하는 형태입니다. Blocks라는 배열에 모든 블록들의 정보를 가져와 저장합니다.
하나의 Object가 만들어지면 하나의 도큐먼트( RDBMS 레코드 )가 생깁니다.

JSON 형태이며 배열 등을 사용할 수 있으며 배열의 길이가 자유로운 면에서 보면 현재 가장 좋은 방안인 것 같습니다.

다만 데이터를 정규화 하지 못해서 중복데이터가 입력될 수 있습니다.

---

그래서 RDBMS와 NoSQL을 같이 사용하면 어떨까 라는 생각을 해보았습니다.
NoSQL에는 Blocks 와 같은 비정형 데이터를 저장하고 user_uuid, block_uuid 와 같이 참조데이터를 uuid 형태로 저장해두면 두가지 형태의 데이터베이스의 이점을 모두 챙길 수 있을 것 같다는 생각입니다.

 

다만, RDBMS를 참조하고 있는 데이터의 종류가 다양해지면 DB에 쿼리를 그만큼 여러번 날려야 할 것 같다는 생각이 듭니다.

 

해결방안

 

1. 캐싱

기본 블럭 같은 경우는 조회가 상당히 잦고 변경 가능성이 현저히 낮기 때문에 캐싱 처리하면 리소스를 많이 절약 할 수 있을 것 같습니다.

 

2. Sql IN절

SELECT * FROM table WHERE block_id IN (1, 2, ..., N);

IN 절은 Row의 데이터를 모두 확인하기 때문에 성능이슈가 발생 할 수 있습니다.

JOIN문이 많이 있는 경우 선행 테이블의 결과를 반드시 고려해야합니다.

 

사실 대부분의 토이프로젝트 수준에서는 별 문제가 생기지 않습니다.
인지하고 있다가 실제 규모가 커져 성능이슈가 조금씩 생기면 최적화 하면 되는 일이라고 생각합니다.

 

 

 

 

마치며

이런저런 상황을 미리 대응해두는 것도 좋지만 너무 많은 것을 생각하다보면

자칫 오버엔지니어링이 될 수도 있습니다.

 

프로젝트를 세팅 하거나, 기획 하다보면 이것도 필요할 것 같고 저것도 필요할 것 같은데?

라는 생각이 들기 마련입니다.

 

이런 생각이 들때면 본인에게 다시한번 물어보세요.

그게 지금 진짜로 필요해?