어쩌다보니 1편을 쓴지 거의 1년이 지나버렸다.. 다시 이어서 분석해보자.클라이언트 라이브러리에서 데이터가 어떤 샤드에 있는지 찾는 기능을 캡슐화해서 구현했다면 그 다음은 흩어져 있는 새로운 소식들을 어떻게 찾고 모을지 고민해야 한다. 사실, 같은 게시판 DB를 여러 서버에 올려두고 그 속의 데이터만 사용자 고유 식별자의 해시 값에 따라 저장되는 서버가 달라지는 구성이기 때문에 기존의 단일 서버 구성과 다중 서버 구성상 서버별 검색은 다르지 않다. 하지만 다중 서버를 사용하는 경우에는 먼저 친구들의 데이터가 어떤 서버에 있는지 확인하고 병렬로 서버별 친구들을 묶어 검색한 후, 그 결과를 다시 모아 정렬하고 잘라내는 작업이 필요하다. 엎친 데 덮친 격으로 연산 비용이 커지지만 그나마 다행스럽게도 최신 데이..
배경취업하기 전 인상깊게 읽은 글이 있다. 절반도 이해하지 못했는데 경력이 쌓이면 언젠가 이해할 수 있겠지? 라고 생각했었다. 그리고 4년차 개발자가 된 지금은 어떤지 알고 싶어졌다. 프론트개발만 하고 있기 때문에 그때와 달라진게 있을까? 싶은 생각도 있지만 CS 지식도 쌓인 만큼 조금 달라졌길 기대한다. 본문위에서부터 한문단씩 읽으면서 생각을 정리해보겠다.(굳이 설명을 덧붙이지 않아도 되는 부분은 생략) 작성자 OR 굴비 알고리즘의 연산 비용을 계산해 보자. 내가 따르는 친구의 수를 m이라 하고 전체 사용자 수를 n이라고 한다면 전체 사용자 검색 연산의 시간 복잡도는 O(m log(n))이 된다. 물론, 각 사용자별로 정렬된 게시물 레코드 식별자 리스트를 찾은 후에도 각 사용자별 레인지 쿼리를 수행하고..