🔍 CS36 데이터 정합성 보장을 위한 트랜잭션 이해하기 - 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. 페이지네이션 최적화 - 01. 페이지네이션이란 많은 양의 데이터를 어떻게 노출시킬 것인가? 다음 페이지 vs 스크롤 다음 페이지를 넘기는 방식 : 페이지네이션 페이지를 넘기지 않고 내리는 방식 : 스크롤 클라이언트가 원하는 페이지의 원하는 사이즈를 서버에게 요청 서버는 페이지와 사이즈에 따라 적절한 데이터를 스캔 (요청 내용 : page 0, size 2 → size를 2개로 나눴을 때 가장 첫번째 page를 요청하는것) 사이즈를 2로 나눴을 때 첫번째 데이터 2개를 찾아 해당하는 데이터를 반환 여기서는 6을 2개씩 나누면 3 → 첫번째 데이터는 1~2번 게시물 : 반환하는 것 대부분 서버는 전체페이지(totalPages) 혹은 전체 개수(totalElements)를 준다. (UI 상에서 마지막 페이지를 알아야 더보기 화살표를 표시하지 않기 때문) .. 2023. 6. 6. 조회 최적화를 위한 인덱스 이해하기 - 08. 인덱스를 다룰 때 주의해야 할 점 1. 인덱스 필드 가공 인덱스 필드에 가공이 들어가면 인덱스로 찾을 수 없음 // age는 int 타입 SELECT * FROM Member WHERE age*10 = 1 // 10을 곱하면 검색이 안됨 // age는 int 타입 SELECT * FROM Member WHERE age = '1' // type을 잘못 넣어준 경우 2. 복합 인덱스 왼쪽처럼 1개의 인덱스가 아닌 오른쪽처럼 복합 인덱스가 되면? 우선적으로 과일 컬럼이 정렬 과일 컬럼이 정렬되면 그 안에서 원산지 컬럼이 정렬됨 따라서 복합 인덱스에서 중요한 것은 선두 컬럼이다. 데이터의 식별 정도가 높은 값이 선두에 있는 것이 좋음 3. 하나의 쿼리에는 하나의 인덱스만 하나의 쿼리에는 하나의 인덱스만 탄다. 여러 인덱스 테이블을 동시에 탐색하.. 2023. 6. 4. 조회 최적화를 위한 인덱스 이해하기 - 04. 클러스터 인덱스 클러스터 인덱스 3줄 요약 클러스터 인덱스는 데이터 위치를 결정하는 키 값 MySQL의 PK는 클러스터 인덱스 MySQL에서 PK를 제외한 모든 인덱스는 PK를 가지고 있음 클러스터 인덱스는 데이터 위치를 결정 클러스터 키의 중요한 핵심 : 정렬을 이루고 정렬된 순서에 따라서 데이터의 주소가 결정되는 것 클러스터 키 4번이 Insert 정리 클러스터 키의 위치에 따라 데이터의 주소가 결정됨 클러스터 키 순서에 따라서 데이터 저장 위치가 변경된다 → 클러스터 키 삽입/갱신시에 성능이슈 발생 MySQL의 PK는 클러스터 인덱스 PK 순서에 따라서 데이터 저장 위치가 변경됨 → PK 키 삽입/갱신 시에 성능 이슈 발생 PK로 Auto Increment vs UUID 찾아보기 MySQL에서 PK를 제외한 모든 .. 2023. 6. 4. 조회 최적화를 위한 인덱스 이해하기 - 03. 인덱스 자료구조 인덱스의 핵심 : 탐색(검색) 범위를 최소화 하는 것 검색이 빠른 자료구조들은 어떤 것이 있을까? Hash Map, List, Binary Search Tree Hash Map 단건 검색 속도 O(1) 그러나 범위 탐색은 O(N) 전방 일치 탐색 불가 ex) like ‘AB%’ → hash map은 꺼내서 일일이 다 비교해보아야 함 List 졍렬되지 않은 리스트의 탐색은 O(N) 정렬된 리스트의 탐색은 O(logN) 정렬되지 않은 리스트의 정렬 시간 복잡도는 O(N) ~ O(N*logN) 삽입 / 삭제 비용이 매우 높음 → 중간 값을 삭제하기 위해서는 뒤에 있는 것을 모두 옮겨야 함 Tree 트리 높이에 따라 시간 복잡도가 결정됨 트리의 높이를 최소화하는 것이 중요! 한쪽으로 노드가 치우치지 않도록 균형.. 2023. 6. 4. 조회 최적화를 위한 인덱스 이해하기 - 02. 인덱스 기본동작 인덱스 정렬된 자료구조, 이를 통해 탐색 범위를 최소화 예시 첫번째 column : id(pk) 나이가 가장 어린 사람의 데이터를 찾고 싶다. index가 없을 때 : 순차적으로 컬럼들의 데이터를 처음부터 끝까지 살펴봄 (이름→성별→나이 → 직업) 전체테이블을 살펴보게 된다. 인덱스가 있다면? 나이에 관한 정렬된 테이블이 하나 생기게 됨 → 여기서 찾은 후 전체 테이블에 해당 데이터를 찾게 됨 (데이터가 나이순으로 정렬되어 있기 때문에 하나만 조회하면 됨) 인덱스도 테이블이다. 인덱스의 핵심은 탐색(검색) 범위를 최소화 하는 것 2023 KAKAO Tech Campus_BackEnd 필수 과정 DB(MySQL) 강의 정리 내용입니다. 2023. 6. 4. 이전 1 2 3 다음
