해당 컨텐츠는 주간동안 읽은 아티클 중 일부를 정리한 내용입니다.
일반적인 Offset
페이징을 적용할 때 데이터가 많아질 수록 아래의 이유로 성능에 문제가 생길 수 있다.
count
일반적인 count
쿼리는 Full Index Scan
을 하기 때문에 성능상 이슈가 생긴다. (mysql
의 경우 row
의 count
값을 캐싱 해놓기는 한다)
offset
limit
쿼리는 orderBy
쿼리 이후에 동작함으로 offset + limt까지의 레코드를 모두 정렬함으로 offset
이전의 레코드(또는 인덱스)값들 까지 읽어오게 된다.
그래서 대용량 데이터들을 다루는 SNS들에서는 일반 게시판 형태에 페이지네이션이 아닌, 스크롤 형태를 띄게 되는 모습을 쉽게 찾아 볼 수 있다.
위 글은 Offset
페이징에 대안으로 Cusor
페이징을 설명하고 있다. Cusor
를 통해 where
절에서 필터를 걸기때문에 필요한 부분의 레코드만 읽어들인다. 또한 일반적인 Cusor
는 페이지 수를 연산할 필요가 없기때문에 Count
값도 필요하지 않다.
인덱스가 동작하는 원리와 커버링 인덱스에 대해 설명이 잘 되어있는 글이다. 워낙 설명이 잘되어 있어서 팀원들에게 강제 구독을 권했다. 하나 주의할 점은 해당글은 CUBRID
기준이기에 실제 사용하는 디비와 다른 부분이 있을 수 있다. (ex. mysql의 경우 null은 인덱싱이 된다)
Django
에서 특정 컬럼이 null
인 객체를 검색하고 싶을 때 is_null_{column_name}=True
또는 {column_name}=None
두 가지 방법이 있다.
두 방법 모드 WHERE {column_name} IS NULL
쿼리가 나가게 됨으로 쿼리상으로는 차이가 없다. 다만 Null
이 아닌 것에 대해 필터를 걸 때는 전자에 방법이 보다 간단하게 구현이 가능하다.
Python
의 max
함수는 일반적으로 리스트에서 최대 값을 뽑아주는 함수이다. 이를 int
형 자료가 아닌, 클래스에 대해서도 적용하고 싶은 니즈가 생겨 찾아본 글이다.
max
의 key
파라미터가 비교 연산에 쓰이는 callable class
이다. operator.attrgetter
를 통해 간단하게 니즈를 충족 시킬 수 있었다.
# models 객체 리스트에서 order 값이 가장 큰 객체 뽑아내는 코드
last_order_model = max(models, key=attrgetter('order'))
중단 없는 캐시 시스템을 설계하기 위한 방법들을 나열하고 있는 글이다. 본문에서 설명하고 있는 ARCUS
는 ZooKeeper
를 활용해 사용가능한 캐시 목록들을 관리한다.