[🐣질문] 뒤끝으로 nosql 인벤토리 구현하는데 질문점

[궁금한뉴비(122.37)]

뒤끝으로 인벤토리 만드려고하는데 인벤토리 아이템리스트를 통째로 칼럼하나에 저장한단말야

그럼 아이템 추가 삭제나 아이템정보 수정할때마다 아이템리스트 전체를 새로 써야되거든

이게 맞는방식인건지 존나 궁금함

인벤토리에 아이템이 500개 있는데 한개 추가 하려면 501개아이템 리스트를 새로 저장해야되건데 이게 맞아?

다른백엔드서비스도 이런방식인거 맞음?

내가 몇개써본거중에는 유니티게이밍서베스에 클라우드세이브도 이런방식이고

파이어베이스는 도큐먼트식이라고 리스트 아이템하나하나 접근해서 수정할수있고 리스트에 아이템 한개만 추가할수있긴함

아무튼 리스트 전체륵 업데이트하는거 존나 비효율적인거같은데 원래 다들 이렇게 개발함?

- dc official App

[ㅁㅂ(112.216)]

nosql이 디스크 I/O는 좀 많기는 함. 도메인을 잘 나눠서 업데이트되는 부분을 나눌수 있으면 나누고

[궁금한뉴비(122.37)]

잘몰라서 그러는데 뒤끝에서 sql로쓴다고해서 리스트에 추가삭제수정 효율적으로 할수있는건 아니지? - dc App

[익명(220.70)]

존나 비효율적임.. 수정 삭제 추가 할때마다 계속 패킷 길이가 겁나 길고... 통신비용도 겁나 나올거임. 안쓰는걸 추천함

[궁금한뉴비(122.37)]

그럼 인벤토리 저장해야되는데 뭐써야함... 관리형서비스.. 아 그리고 유니티게이밍서비스에 인벤토리기능있긴함 - dc App

[익명(220.70)]

궂이 써야 한다면 100개 단위 200개 단위로 끊어서 저장하면 어떨까 싶음

[익명(220.70)]

그냥 처음 인디게임에는 어울리지만 나중에 게임이 조금만 커져도 통신량이 장난아님. 서버 배우는걸 추천한다

[궁금한뉴비(122.37)]

일단 뒤끝으로 빨리하려는데 리스트 추가삭제수정 효율적인 db뭐 써야함? - dc App

[ㅁㅂ(112.216)]

유저id+인벤인덱스 : 아이템 UUID 이런 매핑 도메인 하나랑 각 아이템은 UUID를 키로 저장하던지 등등 구현은 문제가 아니고 진짜 문제는 통계나 지표 같은거임. SQL로 작성한 디비는 다른 사람에게 맡기거나 도와줄수 있는데 nosql로 디비 만들면 스키마 파악 안된 사람은 손도 못댐. RDB안해봤으면 RDB부터 해봐

[익명(14.32)]

딱 들어도 아닌거 같은데?

[궁금한뉴비(122.37)]

아닌거같은데 뒤끝으로 리스트 다루는게 이방법밖에없는거같음 - dc App

[익명(14.32)]

나라면 아이템 개수가 그렇게 많으면 그냥 row 하나에 아이템 하나로 갈듯

[익명(118.235)]

인벤토리 정보만 담는 테이블이라면 컬럼1개에 때려박든 여러개에 때려박든 1회 수정 시 사용량은 동일한걸로 알고있음 머리 굴려보면 전체 인벤토리를 장비, 코스튬, 등 큰 범주를 기준으로 테이블을 나누고 변경사항이 있는 아이템 범주(테이블)만 수정한다. 이게 제일 적절할듯... 뒤끝은 테이블 크기 따라 발생하니까는 때려박은 컬럼 데이터 길이가 어느정도냐에따라 내가 말한대로 안해도 될테니 머리굴려보고 뒤끝 쓰게 하려고 물어보면 어지간히 정성스레 설명해줄텐데 이런데서 묻지말고 뒤끝에 직접 물어봐

[익명(119.207)]

유료서비스 질문을 여따가 하노