2020-02-07 데이터 저장 구조 개선

오늘은 선수단 UI 관련 작업을 시작했는데 선수 생성쪽 작업을 하다보니 데이터 구조가 점점 복잡해져서 이 쪽 개선 작업을 한 번 진행해야겠다는 생각이 들었다.

 

sqlite를 쓸까 고민해봤는데 여러가지로 불편한 부분이 많았고 관련해서 작업해야할 양도 많아서 sqlite를 쓰는 건 보류. 스키마를 고민해봤는데 sqlite를 썼을 때 필요한 작업 시간이나 도입한 이후에 편의성 등을 생각해봤을 때 득보다 실이 많다고 판단했다.

 

 뒤편에서 데이터를 저장하고 가져오는 과정이 실제로 어떻게 동작하느냐와 실제로 데이터를 불러와서 인게임에서 사용하는 인터페이스는 서로 레이어가 다르다. 지금 개발하고 있는 게임에 적합한(편리하고 생산성이 보장되는) 앞단의 인터페이스(프론트엔드)를 먼저 구성하고 실제로 그 인터페이스에 맞춰 데이터를 저장하고 가져오는 부분(백엔드)의 개선은 좀 나중에 고민하기로 했다. 어차피 소규모 게임이고 인게임에서 다뤄지는 데이터 레코드의 개수가 많아봐야 천만 단위를 넘지 않을 것 같아 성능적인 측면에서 과도한 고민을 할 필요는 없을 것 같기 때문이다.

 

그래서 프론트엔드 레이어를 먼저 좀 고민했는데, 데이터를 불러오고 저장하는 과정이 최대한 덜 번거로웠으면 했다. 그리고 이후 생길 수 있는 스키마의 변동 등에도 큰 무리없이 대응할 수 있었으면 좋겠다는 생각이 들었고. 그래서 attribute 메타 데이터를 통해 쉽게 데이터를 가져오고 검색하고 사용하는 형태로 구조를 정했다.

 

핵심적으로 사용할 attribute는 대충 다음 세 가지 정도가 있다.

 

- Reference : 다른 테이블에 대한 참조. 내부적으로는 그 테이블의 키값으로 저장하지만 실제로 불러올 때는 자동으로 참조된 클래스로 대체하여 가져온다. 저장할 때 레퍼런스된 값이 업데이트된 경우 해당 레코드까지 같이 업데이트시켜준다. 이 때 키들이 순환해서 참조하는 경우에도 잘 불러올 수 있어야 하는데, 데이터를 불러올 때 키값을 기준으로 먼저 클래스들을 생성한 후 그렇게 생성한 클래스를 키값에 맞는 위치에 레퍼런스만 대입해주면 문제없이 잘 동작한다.

 

- Index : 색인. 이게 걸려있는 경우 해당 키값을 이용해 데이터를 가져오는게 빠르게 동작한다. 이상 / 이하 / 일치 세 가지 쿼리를 O(logN) 정도에 수행할 수 있게 했다. 인덱스와 무관하게 O(N) 전체 순회하며 쿼리하는 기능도 제공.

 

- Update : 버전이 올라가며 스키마가 변경되었을 경우 구 버전의 데이터를 새로운 버전의 데이터로 자동으로 업데이트해준다. 저장된 각 값들은 내부적으로 버전 정보를 항상 들고 있으며, 이 버전 정보가 최신 정보와 일치하지 않을 경우 해당 어트리뷰트의 내용을 참조해서 순차적으로 현재 스키마에 맞게 데이터를 변경한 후 다시 저장한다.

 

일단 백엔드는 적당히 json 형태로 저장하고 관리하게 만들었다. 이후에 게임을 한 100년치 전개해본다거나 하는 퍼포먼스 테스트를 해보고 그 때 문제가 생긴다면 백엔드에서 개선해야 할 사항 개선해 볼 예정(간단하게는 JSON->BSON만 해도 되지 않을까 싶다). 구현하고보니 일단은 굉장히 잘 동작하고, 이 인터페이스가 개발할 때 아주 편리해서 마음에 든다. 데이터 불러오고 저장하는 게 전부 자유롭고 스키마만 짜면 다른 부분은 전혀 신경쓰지 않아도 돼서.