db 동시성 처리 관련해서 궁금한점이 있습니다.

Question

동시성 처리 관련하여 공부중에 궁금한 점이 있는데요,낙관적 락과 비관적 락이 존재하고, 비관적 락에는 공유락과 배타락이 존재하는걸로 알고 있습니다.위 이론을 바탕으로,게시글의 조회수를 업데이트 하는 비즈니스 로직을 연관지어 생각해았을 때, 게시글에는 동시에 여러 클라이언트로 부터의 접근을 받을 테니까, 낙관락은 사용하기 힘들어 보이고select for update문을 사용한 배타락을 사용해야 할 것 같은데요, 이렇게 되면 하나의 행을 업데이트 하기 전까지 다른 요청들은 select를 하지 못하고 기다리게 될텐데극단적인 예를들어,301 번이라는 특정한 게시글에, 동시에 10만명의 유저가 접근한다고 했을 때, 해당 게시글의 조회수를 업데이트 하기 위해서는 10만번의 업데이트 쿼리문이 순차적으로 앞선 업데이트가 끝날때까지 기다렸다가 수행되어야하는데, 이렇게 되면 많은 시간이 소모 될 것인데, 실제도로 제가 생각한대로 돌아가나요???더욱이, 만약 조회수 칼럼이 게시글이라는 테이블에 묶여 있을 경우. select for update 문을 사용한 배타락을 사용하면앞선 update 문이 끝날 때까지 select도 불가능한데, 그럼 동시에 10만명이 특정 게시글에 접근할 경우,많은 사용자들은, 조회수라는 칼럼 업데이트를 위해서, 게시글을 조회하지도 못하고 기다리게 되는건가요??

엡실론 · Answer

게시물 조회에 select for update를 사용한다면, 한번에 한명씩만 처리되고 모두 기다려야 겠죠.

장독깨기 · Answer

select for update 하지 마시구요,그냥 update read+1 하면 될 거 같아요.

kotliner · Answer

동시에 10만명이면 왠만한 db로는 update를 어떻게 짜도 감당이 안됩니다. memory에서 동작하는 redis같은 데이터소스를 이용해서 앞에서 캐싱하면서 조회수 올리고 뒤에서 배치로 조회수 동기화해서 저장하는방식이 그나마 나을듯합니다. redis도 감당이 안된다면 약간의 지연을 감안하고 kafka를 써서 동기화를 하는게 좋을 듯 합니다.

비정규분포 · Answer

https://engineering.fb.com/2011/02/07/core-infra/live-commenting-behind-the-scenes/Write Locally, Read GloballyStoring these one-to-one, viewer-to-content associations in a database is relatively easy. Keeping up with 16 million new associations per second is not. Up until this point, Facebook engineering had built up infrastructure optimized for many more reads than writes. But now we had flipped the game. Every page load now requires multiple writes (one for each piece of content being displayed). Each write of a comment requires a read (to figure out the recipients of an update). We realized that we were building something that was fundamentally backwards from most of our other systems.방법은 많고 정답은 없습니다.C10k 생각하시는데, 시스템 아키텍트가 되실거 같은데요?

db 동시성 처리 관련해서 궁금한점이 있습니다.

4개의 답변

#rdb 목록