DB 락이 응답 속도에 미치는 영향

Question

아직 실무 경험이 없어서 DB 락이 실제로 얼마나 속도에 영향을 미치는지 모르겠습니다.&#34;좋아요는 클릭 한번으로 수정이 되는 변경이 쉬운 작업입니다. 여러 사용자가 동시에 좋아요를 여러번 누르는 상황이 발생한다면, 서버에 무리가 갈 것이라고 판단되었습니다.&#34;좋아요 개수 조회 최적화하기 (techcourse.co.kr) 를 읽어보니까 위와 같은 이유 때문에 주기적으로 한번에 개수를 업데이트하는 방식을 선택해야 할 때도 있다고 하는 것 같습니다. 그런데 어차피 좋아요만 처리하는 간단한 작업에는 락이 걸려도 응답 속도에 큰 영향이 없을 것 같단 생각도 들어서요. (이런 좋아요 누르는 거에도 부하가 생길 정도면 동시 요청 수가 최소 백 단위는 되어야 하지 않을까?란 궁금증) 실무 경험자 분들이라면 실제로 그 기준을 어느정도 아실 것 같은데 어떻게 생각하시나요 (글에서 뜻하는 락은 READ COMMITTED 격리 수준 이상에서 걸리는 데이터베이스 자체 lock, SELECT FOR UPDATE와 같은 명시적 락 포함)

라떼개발자 · Answer

해당 게시물에 대한 row만 락이 걸릴것 같네요그럼 다른 게시물은 영향을 안받겠네요.얼마전 row lock를 경험한 1인으로..조금 상황은 다르지만 필드 4개가 pk로 걸린 25만건정도의 데이터가 row 락 걸렸는데 해당 pk가 아닌 데이터는 괜찮았음.

Clickin · Answer

여러가지 방법이 충분히 가능하겠지만 제일 간단한 방법은 좋아요 테이블 및 좋아요 증가 API를 분리하면 됩니다.그러면 게시글 테이블 수정 시 좋아요에서 발생하는 lock의 영향을 받지 않을거고, read committed 격리 수준이라면 select 과정에서 좋아요 숫자의 오차가 다소 발생하는 정도로 끝날겁니다.

snake · Answer

api서버 db서버간 네트워크 속도테이블 데이터 개수pk 타입이 string인지 int인지api 성능, db성능이게 다 작용해서 몇건인지 알려드리는 건 어렵고실무에서 사용하는 api 서버정도면 부하보다는 Qeurytimeout만 날 것 같아요.

집킨 · Answer

단일 트랜잭션은 디비 설계가 잘 돼있으면 그리 오래걸리지도 않습니다특히나 좋아요같은 단순한 기능은 더더욱이요근데 문제는 요게 너무 많이 쌓이면 문제가 됩니다단순히 커넥션이 대기 상태가 되는것 뿐만이 아니라 해당 row에 관련된 트랜잭션이 계속 밀려들어오면 언두 로그가 삭제가 되지 않고 계속 메모리에 머물면서 성능에 악영향을 줍니다 (mysql innodb 한정 이야기입니다)언두 뿐만 아니라 리두로그도 지속적으로 소모되겠죠근데 정말 대규모 유저가 사용하는 서비스가 아닌 이상 좋아요 기능 때문에 디비 서버가 과부하 걸리는 일은 없을겁니다

캐티 · Answer

카운트 증감 방식을 사용한다면 락이 필요할 것이어요. 완전히 동시에 love=love+1 이 수행되는 경우에 0+1이 두번 수행되어 love 필드에 1이 저장될 수 있어서 말이어요. 단순한 작업이라 하더라도 수십만명이 동시에 좋아요를 누르는 경우에 트랜젝션을 걸면 성능이 아주 나빠져요.이렇다 하더라도 좋아요 수 하나 흘린다고 이를 보완하려고 하는 경영진은 아마 없을 것이어요. 이런 하찮은 기능에는 그냥 더 고민하지말고 트랜젝션을 안 쓰는 것이 어떠나요.

MySpace · Answer

좋아요는 insert로하고 count 집계해도 좋을듯요... 나중에 배치로sum해서 저장하면 어떨지...

판교바닐라라떼 · Answer

중간에 캐시 서버를 둬서, 메인 서버는 캐시 서버로 보내고, 캐시 서버가 벌크 인서트 하는 방식으로 DB부하를 줄이는 방식도 있습니다

르매 · Answer

잠금에 대해 공부하시는 것 같습니다. 비슷한 질문을 여러 번 주고 계시네요. ^^잠금 구현은 벤더마다 다르지만 원리를 이해하는 것에는 하나의 DBMS를 확실히 파는 것으로 대충 충분합니다.MySQL 보다는 MS-SQL 쪽에 좋은 아티클이 많으니, 이쪽으로 찾아보시면 도움이 될 겁니다. 블로그 보다는 MSDN을 추천합니다. 한글 문서화가 잘 되어 있으니까요. https://learn.microsoft.com/ko-kr/sql/relational-databases/sql-server-transaction-locking-and-row-versioning-guide?view&#61;sql-server-ver16#lock_engine본문의 예에 대한 실무 경험을 말씀드리면.. 생각하시는 것보다 RDBMS는 동시 사용 성능이 매우 뛰어납니다.과거 NoSQL 같은 기술이 없던 시절에 옥션 대부분의 서비스가 MS-SQL 서버 1대로 커버할 정도였으니까요. (물론 머신은 수퍼돔이었지만.. ㅎㅎ)제가 15년 전에 MS-SQL로 게임 DB를 구축했을 때, 쓰기 작업이 대부분인 상황에서 동시 접속자 10,000명이 요청하는 초당 batch request 수는 3,500건 정도였어요. 요즘처럼 SSD도 아닌 HDD를 RAID로 묶어서 사용하던 시절이었고.. batch request는 SP 실행에 대한 요청 수 이기 때문에 SP 안에 있는 여러 쿼리를 기준으로 하면 초당 처리할 수 있는 쿼리의 수는 더 많습니다. 게다가 게임 DB 였기 때문에 대부분의 작업이 쓰기.. 즉, 배타 잠금을 필요로하는 작업이었는데도 이 성능이 나왔죠.본문에 언급된 추천 수 올리는 작업 정도는 DB 부하를 걱정할 수준의 일이 아닙니다. 문제될 request 수라면 이미 백엔드도 엄청 스케일 아웃이 필요할 걸요? ㅎㅎㅎ잠금에 대해 깊이 있게 알아보고 싶으시다면, 저런 단순한 잠금이 아니라 복잡한 상황에서의 잠금을 예로 생각해 보셔야 실용적인 지식이 됩니다. &#34;아무리 부하가 작아도 요청 수가 많으면 문제가 되잖아요!!&#34; 이런 주장은 어떤 주제에나 다 적용할 수 있는 거고, 답도 없는 이의 제기거든요.

DB 락이 응답 속도에 미치는 영향

8개의 답변

#lock 목록