MariaDB를 사용하는 주 데이터 저장소로 처리하기 어려운 특이한 요구사항이 있으면서, 데이터의 무결성 보장을 적게 요구하는 경우를 위해 여러 가지 종류의 보조 저장소가 제공됩니다.
자세한 내용은 각 저장소별 문서를 참고하세요.
주 데이터 저장소(EngineAPI.DB
)에는 트랜잭션을 쓸 수 있지만,
보조 저장소는 트랜잭션으로 묶을 수 없습니다.
트랜잭션 안에서 보조 저장소에 쓰기를 하고 트랜잭션을 롤백하는 실수를 흔히 하기 쉽습니다.
그렇게 하면 DB는 롤백되지만 보조 저장소에 쓴 내용은 롤백되지 않고 남게 됩니다.
DB와 보조 저장소에 저장된 데이터가 합을 맞춰 변경되어야 하는 경우를 가능한 한 피해서 설계하십시오. 예를 들면, 아이템을 인벤토리에서 꺼내서 우편함에 넣는 기능을 만들 때,
- 인벤토리와 우편함을 모두 DB로 만든다 → 좋습니다.
- 인벤토리를 DB로 만들고 우편함을 보조 저장소로 만드는데, 아이템을 우편으로 부칠 때 아이템은 여전히 DB에 있지만 '우편함에 있음' 플래그만 켜고, 보조 저장소에는 아이템 id만 기록한다 → 좋습니다. 다만 우편함에 있는데 인벤토리에 없거나 그 반대의 경우가 발생했을 때를 처리해야 합니다. 정상적인 경우에는 발생하지 않는 상황이므로, 인위적으로 이런 상황을 발생시키는 자동화된 테스트 케이스를 만들어야겠죠.
- 인벤토리를 DB로 만들고 우편함을 보조 저장소로 만들고, 아이템이 DB와 보조 저장소를 옮겨다닌다 → 이렇게 하지 마세요. 아이템 복사를 일으키는 버그가 생기기 쉽습니다.
보조 저장소 종류마다 center 데이터베이스의 redis_setting 테이블에 항목을 하나씩 만들면 됩니다.
개발용 디폴트 설정은 모든 보조 저장소를 하나의 Redis 인스턴스에 몰아넣는 것이지만, 저장소 종류에 따라 Redis 퍼시스턴시 설정 등을 다르게 하는 것이 바람직할 수 있기 때문에, 서비스 오픈 전에 보조 저장소 사용 내역을 꼼꼼히 검토해보고 설정합시다.
Redis는 읽기/쓰기를 매우 빠르게 할 수 있지만, 매우 빈번하게 요청할 경우에는 Redis 프로세스 한 개로 부족할 수 있습니다. 이를 위해, 로직 프로그래밍 인터페이스를 바꾸지 않고도 하나의 보조 저장소가 여러 개의 Redis 프로세스를 사용할 수 있도록 설계상의 준비를 해두었습니다.
다만 아직 구현은 하지 않았습니다.
모두 Redis를 사용해서 만들었습니다. EVALSHA 명령어를 이용한 경우가 많습니다.