본문 바로가기

🔍 CS/데이터베이스31

타임라인 최적화 - 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.
조회 최적화를 위한 인덱스 이해하기 - 01. 데이터베이스 성능 핵심 컴퓨터 구조 CPU가 디스크나 네트워크 카드 등에 접근을 하기 위해서는 I/O 버스를 거쳐야 함 데이터를 저장하기 위한 용도 → 메모리, 디스크 메모리 vs 디스크 메모리 속도 : 빠름 영속성 : 전원이 공급되지 않으면 휘발 가격 : 비쌈 디스크 속도 : 느림 영속성 : 영속성이 있음 가격 : 저렴함 데이터베이스의 데이터는 결국 디스크에 저장됨 하지만, 디스크는 메모리에 비해 훨씬 느리다. → 데이터베이스 성능의 핵심은 디스크 I/O(접근)을 최소화 하는 것 디스크 접근은 어떻게 줄일 수 있을까? 메모리에 올라온 데이터로 최대한 요청을 처리하는 것 → 메모리 캐시 히트율을 높이는 것 심지어 쓰기도 곧바로 디스크에 쓰지 않고 메모리에 쓴다. → 메모리에 데이터 유실을 고려해 WAL(Write Ahead L.. 2023. 6. 4.
SNS 모델링으로 배우는 정규화 / 비정규화 - 07. 실무에서의 정규화 비정규화에 대한 고민들 실무에서는 어떤 고민들을 할까? 테이블을 만들 때면 항상 고민 중복된 데이터이면 반드시 정규화를 해야할까? 사실 그렇지 않음 실무에서 중복 데이터면 기계적으로 정규화를 하는 분이 종종 있음 정규화는 비용 → 읽기 비용을 지불하고 쓰기 비용을 줄이는 것 정규화시 고려해야 하는 것 얼마나 빠르게 데이터의 최신성을 보장해야 하는가? 히스토리성 데이터(데이터의 최신성을 보장하지 않음 → 과거의 데이터를 가지고 있어야함)는 오히려 정규화를 하지 않아야 한다. 데이터 변경 주기와 조회 주기는 어떻게 되는가? → 만약 변경주기가 조회주기보다 빈번하다면 정규화하기에 유리하다. (쓰기의 이점을 가져가야 함. 반대의 경우에는 조회의 이점을 가져야함 ) 객체(테이블) 탐색 깊이가 얼마나 깊은가? 객체(테이블) 탐색 깊이가 .. 2023. 6. 4.

티스토리툴바