https://gall.dcinside.com/mgallery/board/view/?id=backend&no=9885
대용량 트래픽 논의글안녕하세요.늦은 밤.. 주니어 개발자로서 궁금한 점이 생기어 이렇게 글을 남기게 되었습니다...현재 진행중인 프로젝트에서 상품 테이블이 있고 상품별 판매수량이 있으며 일괄이 아닌 낱개 판매가 가능한 상품입니다.이러한gall.dcinside.com이 글 문제 못푸는 얘들은 그냥 CS 지식이 부족한거다
데이터베이스의 WAL만 알아도 MYSQL RedoLog를 왜 하는지만 알아도
위 문제는 풀수있다. CS의 기본적인 이해도 없으니까 위 문제를 못푸는거다
결국 리두 로그가 필요한 이유는 데이터의 내구성 보장, 쓰기 지연을 위해, 데이터의 무결성 보장을 위해
크게 3가지 이유로 귀결 되는데 갑자기 데이터 페이지를 적재하는 중 완전히 적재 되기도 전에 시스템에 장애가 발생하면?
당연히 Durability를 보장하기 힘들어져.(INSERT 쿼리일 경우 만약 UPDATE 쿼리면 BufferPool이랑 실제 데이터의 정합성을 보장하기 힘들어짐)
그리고 설사 가능하다 해도 매번 INSER INTO 마다 바로 바로 데이터 페이지를 저장하면
성능상 심각한 문제가 발생해 Buffer Pool에 저장하고 쓰기 지연 메커니즘을 구현해 백그라운드 쓰레드로 처리하면 효율적으로 저장할 수 있어
결국 MYSQL의 WAL 원리와 트랜잭션 아웃박스 패턴의 원리가 동일해 그냥 레이어가 데이터베이스 내부 수준에서 어플레케이션간의 정합성 문제로 바뀐거야
문제에 대한 해결책은 정작 본인은 모르고 그냥 책 내용만 읊고 있노.. ㄹㅇ 차에코 하위호환이네 이건
어제 리마큐에서 본 내용 그대로노 ㅋㅋㅋ - dc App
너도 CS에 대한 이해가 부족하구나 WAL이 무슨 원리인지 이해 했으면 이런 멍청한 소리는 못할텐데 ㅉㅉ
리마큐 읽은지 1년 6개월도 넘었따
화이팅하고 얼룽 취업해라 힘힘
'장애가 발생했을 때 어떻게 복구할까' 에 한정된 내용이고 '상품 비지니스 로직을 어떻게 TPS 잘 나오게 설계할까'에 대한 내용은 없는 레후
WAL 메커니즘이 쓰기 지연으로 효율적으로 모아서 INSERT 하는 장점도 있음 트랜잭션 아웃박스 패턴이 이 와 동일한 원리지
진지하게 자폐검사 받아봐라
대기야 일침좀 넣어라