본문 바로가기

분류 전체보기255

동시성 제어하기 - 04. 낙관적 락 동시성 제어를 위한 가장 보편적인 방법은 락을 통한 줄세우기 → 비관적 락 락을 통한 동시성 제어는 불필요한 대기 상태를 만듦 MySQL에서는 인덱스를 잠그기 때문에 WHERE문 조건에 따라서 불필요한 데이터들이 잠기기도 함 동시성이 빈번하지 않은 쿼리로 인해 다른 쿼리가 대기한다면? 동시성 이슈가 빈번하지 않길 기대하고, 어플리케이션에서 제어한다. → 낙관적 락의 기본 개념 CAS(compare and set) 낙관적 락에서 어떻게 어플리케이션에서 제어하는가? → CAS를 통해 제어한다. 예제를 통해 살펴보자. 예제) 지난 예제와 다른 점은 버전이 추가되었다는 것이다. 낙관적 락에서는 레코드 하나에 대해서 버전을 매긴다. (버전 관리를 통해 내가 조회했던 버전이 맞는지 확인을 하고 맞다면 업데이트를 하.. 2023. 6. 7.
동시성 제어하기 - 02. 쓰기락과 읽기락 - 이론 동시성 제어를 위한 가장 보편적인 방법은 락을 통한 줄세우기 쓰기락과 읽기락 락을 통해 동시성을 제어할 때는, 락의 범위를 최소화 하는 것이 중요 → 락을 잡는동안 수행하는 작업의 범위를 최소화 하는 것 락의 범위가 크면 클수록 락을 획득하기 위한 여러 트랜잭션들이 대기하는 시간이 길어짐 → 그만큼 성능도 내려간다. 락의 범위가 길어질수록 Connection Pool을 점유하는 시간이 길어짐 → 최악의 경우에는 Connection Pool 고갈로 이어질 수 있음 MySQL에서는 트랜잭션의 커밋 혹은 롤백시점에 잠금이 풀림 → 트랜잭션이 곧 락의 범위 따라서 여기서는 락의 범위를 최소화 한다는 것은 하나의 트랜잭션을 최소화 한다는 것임 예시) 만약 S3이미지를 업로드 한다고 했을 때 이것이 트랜잭션 범위안.. 2023. 6. 7.
동시성 제어하기 - 01. 멀티 스레드 환경에 대한 이해 대부분 하나의 웹 서버는 여러 개의 요청을 동시에 수행할 수 있다. → 작성한 코드 한 줄은 동시에 수행 될 수 있다. → 하나의 자원을 두고 여러 개의 연산들이 경합을 하기 때문에 데이터 정합성을 깨뜨릴 수 있다. 예제를 통해 위의 상황을 이해해보자. 예제) 상황 : 100원을 출금하는 요청이 동시에 발생 첫번째 트랜잭션이 홍길동의 잔고를 읽고 출금 금액을 확인 → 잔고가 넉넉한지를 확인 → 출금금액 만큼 기존의 잔고에서 빼주어서 홍길동의 잔고를 UPDATE 첫번째 트랜잭션이 홍길동의 잔고를 읽고 출금 금액을 확인하는 과정 바로 후에 두번째 트랜잭션이 홍길동의 잔고를 읽는 상황이 발생했다고 가정 첫번째 트랜잭션은 그대로 100원을 빼고 900원을 업데이트함 두번째 트랜잭션은 잔고가 1000원으로 확인되.. 2023. 6. 7.
데이터 정합성 보장을 위한 트랜잭션 이해하기 - 04. 트랜잭션 격리레벨 Isolation - 트랜잭션은 서로 간섭하지 않고 독립적으로 동작한다. READ UNCOMMITTED READ COMMITTED REPEATABLE READ SERIALIZABLE READ 위의 4가지는 Dirty Read Non Repeatable Read Phantom READ 이 3가지 중 몇가지를 방지하는가 혹은 허용하는가로 격리레벨이 결정된다. Dirty Read 예제) 홍길동이 김국밥에게 900원을 송금하는 상황 트랜잭션 격리레벨은 여러 트랜잭션들이 존재할 때 서로 간섭하지 않는가이다. 트랜잭션 2개가 거의 비슷한 시간에 진입했다고 가정해보자. 첫번째 트랜잭션 : 900원을 출금시키기 위해 홍길동의 잔고(1000원)를 가져옴 그리고 곧바로 900원을 이체시키기 위해 김국밥 잔액에 900원을 .. 2023. 6. 7.
데이터 정합성 보장을 위한 트랜잭션 이해하기 - 02. 트랜잭션 A, C, I, D 트랜잭션 ACID ACID의 사전적 정의보다는 ACID가 어떤 이유에서 나왔고 어떤 기술들이 ACID를 가능하게 하는지가 중요 사전적 정의 : 데이터베이스 트랜잭션(데이터에 대한 하나의 논리적 실행단계)이 안전하게 수행된다는 것을 보장하기 위한 성질을 가지키는 약어 Atomicity(원자성) : 트랜잭션과 관련된 작업들이 부분적으로 실행되다가 중단되지 않는 것을 보장하는 능력 원자적 연산을 보장해야 함 → All or Nothing (중간에 연산이 수행하다가 멈추지 않음) 어떻게 보장? MVCC를 통해 UPDATE가 일어나면 기존의 데이터에 900원을 더해주고 UPDATE 전의 데이터는 사라지는 것이 아닌 Undo Log에 저장 만약 트랜잭션이 실패하게 되면 Undo Log에 있는 데이터로 복원 Undo.. 2023. 6. 7.
데이터 정합성 보장을 위한 트랜잭션 이해하기 - 01. 트랜잭션이 없는 세상은 트랜잭션이 필요한 이유 상황 : 홍길동이 김국밥에게 900원을 송금 READ (홍길동 잔고) UPDATE (김국밥 잔액) = 김국밥 잔액 + 900 3. UPDATE(홍길동 잔액) = 홍길동 잔액 - 900 문제1. 만약 3번 과정(UPDATE(홍길동 잔액) = 홍길동 잔액 - 900)에서 실패를 한다면? 따라서 SQL문을 마치 하나의 오퍼레이션으로 묶을 수 있어야 함 : 트랜잭션 → 1~3번 과정을 하나의 오퍼레이션으로 묶을 수 있어야 함 문제2. 2번 과정후 3번 과정 전 사이에 김국밥이 1400원을 출금해버린다면? → 3번 과정은 실패를 할 것임 따라서, 처리 중인 데이터를 다른 곳에서 조회하게 되면 문제가 발생 → 트랜잭션 격리레벨을 따로 지정할 수 있어야 함 2023 KAKAO Tech Camp.. 2023. 6. 6.
타임라인 최적화 - 06. 타임라인에서 배우는 트레이드 오프 Push Model은 공간 복잡도를 희생, Pull Model은 시간 복잡도를 희생 정합성과 성능 Push Model vs Pull Model 중 어떤 것이 정합성을 보장하기 쉬울까? Pull Model : 원본 데이터를 직접 참조하므로, 정합성 보장에 유리 반면, Follow가 많은 회원일수록 처리 속도가 느리다. Pull Model의 예시) Facebook Push Model의 예시) Twitter Facebook : 5000명이 되었을 때는 내가 친구를 끊어야 다른 사람을 친구로 등록 가능 Twitter : 5000명이 최대여도 나를 팔로우한 사람이 더 늘어난다면, 다른 사람 팔로우 가능 Push Model에서는 게시물 작성과 타임라인 배달의 정합성 보장에 대한 고민이 필요하다. 모든 회원의 타임라.. 2023. 6. 6.
타임라인 최적화 - 04. 팬아웃 타임라인 이론 Fan Out On Read Pull Model 이다. 조회 시점에 부하가 있음 Fan Out On Write (Push Model) write 시점에 fan out을 한다. 핵심 개념 : 게시물 작성시, 해당 회원을 팔로우하는 회원들에게 데이터를 배달한다. 3번 유저가 게시물을 작성 **Fan Out On Write (Push Model)**에서는 Timeline이라는 별도의 테이블이 생기게 됨 유저가 게시물을 작성하는 시점에 해당 유저의 follow을 찾게 된다. 1번 유저(해당 유저의 follow)에게 해당 유저의 게시물을 배달해줌 → Timeline table에 게시물을 insert 해주는 것(게시물이 작성되는 시점에) 1번 유저가 게시물을 작성 follow 테이블에서 1번 유저의 follow하고.. 2023. 6. 6.
타임라인 최적화 - 03. 서비스가 커질수록 느려지는 타임라인 실습 - 타임라인 구현 흐름 회원의 팔로우 목록 조회 1번의 팔로우 회원 id로 게시물 조회 시간 복잡도 계산해보기 Follow 테이블과 Post 테이블이 있음 1번 id를 가진 타임라인 요청을 처리하는 과정을 살펴보자 from이 1번인 개체를 조회 해당 개체의 to 개체를 뽑아서 to의 id들로 게시물을 조회 시간복잡도 인덱스가 있다는 가정하에 (Follow, Post 둘다) log(Follow 전체 레코드) + 해당 회원의 Following * log(Post 전체 레코드) to 가 OR이기 때문에 해당 회원의 Following 수만큼을 곱하게 된다. Fan Out On Read (Pull Model) 읽는 시점에 Fan Out을 시킨다. 사용자가 매번 홈에 접속할 때마다 부하가 발생 따라서 팔로워수.. 2023. 6. 6.
타임라인 최적화 - 01. 타임라인이란? 타임라인 트위터, 페이스북, 인스타그램 등 SNS 팔로워들의 게시물을 보여주는 피드 실습 - 요구사항 회원 ID를 받아, 해당 회원의 팔로워들의 게시물을 시간순으로 조회 2023 KAKAO Tech Campus_BackEnd 필수 과정 DB(MySQL) 강의 정리 내용입니다. 2023. 6. 6.
페이지네이션 최적화 - 05. 커버링 인덱스 SQL문이 들어오게 되면, 바로 테이블에 접근하는 방식보다는 중간에 인덱스라는 테이블을 거쳐서 접근을 한 번 필터링 하고 테이블로 접근을 하는 것이 훨씬 빠름 → 검색 조건이 인덱스에 부합하다면, 테이블에 바로 접근 하는 것보다 인덱스를 통해 접근하는 것이 매우 빠르다. 그렇다면 테이블에 접근하지 않고, 인덱스로만 데이터 응답을 내려줄 순 없을까? → 커버링 인덱스 커버링 인덱스 예시 query SELECT 나이 FROM 회원 WHERE 나이 < 30 → 필요한 데이터는 나이 1개이다. (이는 인덱스 테이블에 있음) → 이러한 경우는 테이블에 접근하지 않고 인덱스 테이블의 접근으로 응답이 끝남 (빠르다) 다른 예시 query SELECT 나이, id FROM 회원 WHERE 나이 < 30 → id 필드도.. 2023. 6. 6.
페이지네이션 최적화 - 03. 오프셋 기반 페이징 구현의 문제(1) 오프셋 기반의 페이징 구현 : 마지막 페이지를 구하기 위해 전체 갯수를 알아야 함 전체 페이지의 크기가 클수록 전체 사이즈를 구하는 것 자체가 큰 부하가 될 수 있음 실제 대용량 데이터를 제공하는 서비스를 본다면, 마지막 페이지에 대한 접근을 막거나 무한 스크롤 형태로 제공 그 외에도 쿼리를 보낼 때, offset과 limit의 쿼리를 사용 4번 Offset부터 시작하기 위해 0~3번 Offset까지 데이터를 다시 읽음 4번 Offset부터 size만큼 반환 실제로 반환하는 데이터는 2개인데, 반환하는 2개의 데이터를 읽기까지 4개의 데이터를 읽고 버리게 된다. **(**지금은 Offset이 작기때문에 4개만 버리지만, 실제로는 Offset 사이즈가 커지면 커질수록 버려지는 데이터들이 훨씬 많다) 따라서.. 2023. 6. 6.

티스토리툴바