[회의록] 2019 12 04

0.대 버전을 추가 할 것

기술스택들은 잘 사용하고 있는가? 부분적으로 잘하고 있다.

쓴걸 잘 이해하면서 사용하는 것이 중요하다.

테스트??? 형진이형 이거 뭐야?

질문 1. Big N 개의 팔로우

1000명을 팔로우 하고 있는 경우를 가정해보자. 우선 팔로우 테이블 에서 내가 팔로우하고 있는 사용자의 리스트를 구해야 한다. 그리고 게시글 테이블에서 위 리스트를 where 절에 넣어서 검색을 한다. 전체 사용자가 지나치게 많아 게시글 테이블에 게시글이 너무 많고 내가 팔로우 하고 있는 사람들이 너무 많을 경우에 과부하가 걸리지 않는가?

답

해결 하기 힘든 문제이다. 실제로 페이스북은 이 문제를 해결하기 위해서 운영체제를 튜닝해서 사용하고 있다. 이러한 문제는 사용자가 10만명 이상 있어야 겨우 지연이 보이는 수준이기 때문에 현 단계에서는 고려할 필요가 없다.

사용자가 늘어나면 이런부분을 튜닝을 하겠다. 학습을 한다. 구현은 현재 상황에 맞게 나중에 스트레스가 올라갔을 때 나중에 유저가 많아지는 상황에 당면했을 때 어떻게 대응할건지 어떻게 문제를 해결할 것인지를 고민하고 해당 내용을 포함하라.

질문 2. 페이지네이션 질문

limit와 offset을 지정해서 페이지네이션을 할 때에, 매번 orderby를 이용하여 테이블을 정렬하는가.

답

애당초 orderby 와 unique와 같은 속성은 지양하는 것이 좋다. orderby가 있는 쿼리는 잘못 짠 쿼리이다. 데이터 베이스에는 row가 시간 순서대로 들어가기 때문에 시간을 기준으로 order를 할 필요가 없다.

질문 3. 페이지네이션 원리

limit를 사용할 경우, limit 만큼의 데이터만 찾고 search를 끝내는가

답

그렇다. 그렇기 때문에 더더욱 orderby를 하면 안된다. order by를 할 경우에는 DB 전체의 테이블을 정렬하고 상단부터 limit개 만큼 가져오기 때문에 그 코스트가 지나치다.

레코드를 쌓으면 시간의 역순으로 쌓이게 되어있다. 오더바이는 안하는게 좋다. 오더바이나 유니크가 들어가있으면 기본적으로 잘못된 쿼리이다. 그런 정렬이나 전체를 뒤지는

쿼리플랜 explain db에 엑세스하는 건 무조건 적어야한다. 인덱스를 걸어야한다. 보는게 중요한 서비스이기떄문에 읽기 최적화에 집중해야한다. 캐시를 하는게 좋다. 레디스랑 mysql 속도가 1000배쯤 차이가 난다. 인메모리 캐시같은걸 잘 활용해서 하면 순식간에 가져올 수 있다.

인스타그램 모바일웹으로 확인해볼 것.

우리팀 선회한 방향이 좋은 방향인지?

크롱님은 괜춘

최적화라는게 기능이 많아지고 복잡해질 때 의미가 있는건데 그래서 지금 단계에서 그걸 고민하는게 맞는지 모르겠다. 그거에 대해서 고민해보면 좋겠다. 핵심기능이 작동하는 상황에서는 좋다고 생각한다.

캐시를 로컬 단에서도 하나??

---

회의

사람태그 - 사진태그를 빼자, 본문태그만

OAuth는 하되 형진이형이 캐리한다.

e2e테스트는 무의미하다.
-> e2e테스트를 왜 하기로했는지 왜 안하기로했는지 정리하자. 공부를 해봤는데 무의미하다고 판단했다 정도로 결론.

최적화는 과연 의미있는가? ->

자동배포를 적용하자 -> 코드 프리징을 하고 테스트할 수 있는 시간이 없으니까

레디스 -> 레디스를 통해 캐시를 하는 방법 논의 -> post의 일정 부분을 레디스로 옮기고 거기서 select하면 어떨까 -> 하지만 현재 수준에서는 필요 없는 부분이 아닐까 -> 나중에 쿼리 최적화한 후 레디스를 도입한다면 어떻게 할 수 있을지 논의해볼 것.

게시글 수정, 삭제 -> 수정은 하지말고 삭제만 하자