채팅 내역DB 저장 시 PK

Question

안녕하세요. 학교 학생들과 spring&#43;my sql로 채팅 서비스 구현 중입니다. 채팅 내역 저장 시 DB 설계에 고민이 있어서 질문 올립니다.채팅 내역은 모두 my sql에 저장 중입니다. 이 때 PK를 auto increment로 설정하였는데, 내역이 쌓이다 보면 숫자의 한계가 올 것리하고 생각하였습니다. 따라서 uuid나 날짜&#43;숫자 도합으로 string 형식으로 변경하려는데 성능이나 db 저장 공간에 대해 괜찮을지 고민입니다.여러 피드백이나 의견 드리면 감사하겠습니다.

Clickin · Answer

UUID로 처리하는 방법은 아무리 최근에 최적화가 진행되었다고 해도 auto_increament보다 성능이 부족할 수밖에 없습니다.채팅인데 자동증가 키를 사용하지 않으시는 방안도 그닥 알맞지 않은 듯 하고요PK를 복합키 등 별도의 로직을 사용해 생성하는 경우 해당 도메인에서 의미가 있어야 하는데 채팅이라면 creation_date랑 다를 바가 없습니다.BIGINT 타입으로 auto_increament 추천드립니다.BIGINT는 64비트 정수기 때문에 학생 레벨에서 BIGINT를 넘을 경우는 없다고 봐도 되겠습니다

달의바다a · Answer

PK는 auto increment가 편하긴 합니다. 정말 대량의 데이터를 insert해야 하면 auto increment도 부하가 생기긴 하지만 관리하는 측면에서 좋다고 생각합니다. 그리고 pk에 날짜&#43;숫자 등 유의미한 정보를 넣는건 안티패턴이라고 생각합니다. pk에는 부가적인 내용을 담지 말고 정말 pk의미로 관리하는게 맞고 필요하다면 다른 컬럼을 만들어서 이용하는게 좋습니다.

캐티 · Answer

억. 채팅 서버는 사실 채팅 기록이 많아지면 데이터가 아주 많이 쌓이게 될 것이고 심각한 오버헤드가 발생 할 것이어요.그러므로 예를 들면 채팅 방 하나 당 개별 테이블을 두고 이를 적절하게 처리 할 것 같습니다.datetime [pk]user name [fk]message2000-01-01 12:00:00.000dragonhi!2000-01-01 12:00:00.001doeoh! hi2000-01-01 12:00:00:002tigeryay!이렇게 하면 최소한의 데이터를 사용 할 수 있고 인덱싱도 적절하게 되지 않겠나요. 이렇게 하면 동시 채팅을 최대 999개까지 처리 할 수 있어요. 물론 극단적인 경우이저. 이 경우 밀리초 단위를 순차적으로 기록 할 수 있어요.부가적으로 채팅방 전용으로 데이터베이스를 나누어 사용하는 것이 좋아요. 개발자가 접근하는 부분과 시스템이 접근하는 부분을 나누고 실행과 접근 권한을 나누어 보안을 강화해요!

kiel · Answer

Long (BIGING) 로 PK 타입을 설정했을 경우 대충 18자리 수자가 만들어집니다. 이게 한계가 올 정도면 서비스가 대박이 난거죠.Auto Increment 가 성능상의 이점도 있고, PK 자체로 의미를 가지지 않는다면 그냥 Long 타입으로 잡으시는게 좋을것 같습니다.

초무쿤 · Answer

partition table(or sharding) &#43; uuid

채팅 내역DB 저장 시 PK

5개의 답변

Q&A 목록