NL Join과 인덱스책 친절한 SQL 튜닝 272페이지를 보면, 다음 쿼리와 인덱스에서 잘못된 부분을 찾아 개선하라는 문제가 나온다.# index: (SALE_ORG_ID, STRD_GRP_ID, STRD_ID, STC_DT)select *from PRA_HST_STC a, OOM_TRMS bWHERE a.SALE_ORG_ID = :sale_org_idand a.STRD_GRP_ID = b.STRD_GRP_IDand a.STRD_ID = b.STRD_IDorder by a.STC_DT descindex 공부하기 전에는 못맞췄을 것 같은데, 지금은 2가지 문제가 보인다. 내가 생각한 답을 말하자면, 나는 인덱스를 2개 만들 것 같다. OOM_TRMS(b) 테이블에서(STRD_GRP_ID) or (STRD..

결합 인덱스에서 all equal 조건절에서는 칼럼 순서가 중요하지 않다인덱스 쪽에서 유명한 틀린 예제가 있다.SELECT 이름, 성별FROM 사원WHERE 성별='여자' AND 이름='유관순'위 예제에서 (성별, 이름) 인덱스를 사용하는 것과 (이름, 성별) 인덱스를 사용했을 때의 성능이 다르다는 것이다. 따라서 결합 인덱스에서 컬럼 순서가 중요하다는 것을 말한다. 그 이유는 사원 50명 중, 여자가 25명 유관순이 2명이라면(성별, 이름) 인덱스: 성별로 거르기(25명 남음) -> 이름으로 거르기(25명 중 2명만 남기기)(이름, 성별) 인덱스: 이름으로 거르기(2명 남음) -> 성별로 거르기(2명 중 2명 남음)위 순서로 필터링하기 때문에 B-Tree를 타고 내려가면서 필터링하는 수가 줄어들어 (..

뇌피셜 주의!이 글은 이 책을 읽고 느낀 개인적인 생각을 적은 글입니다. 곧이 곧대로 믿지 말아주시고, 틀린 내용이나 의견 있으면 자유롭게 남겨주세요 :)NoSQL Distilled최근 읽은 책중에 재밌게 읽은 게 있어서 소개해 보려고 가져왔다. 크게 1부(기본 개념)와 2부(적용)로 나뉘어 있는데, 2부에서는 각 NoSQL 제품군들의 종류에 대한 간략한 소개가 들어있다. 정말 간략한 소개이기 때문에 1부만 보아도 충분할 것 같다. 그렇기에 이번 내용에도 거의 1부 내용만 소개하려고 한다. 내가 재밌게 읽었던 부분들은 다음과 같다. - NoSQL의 등장 배경과 특성  - aggregate data model의 특성- 일관성 / 분산 모델 / 맵 리듀스- 스키마 관련 이 책을 읽고나서 원래 가지고 있던 ..

문제 상품 전시(display)쪽이라 호출이 엄청 많기도 하고, 상품 보여줄 때마다 이 상품이 특정 상태의 상품인지 확인해야 하는 로직이 있다. 그 특정 상태는 PM분이 상태를 등록할 수 있도록 slack 메시지로 등록할 수 있게 만들어 둔 상태고, redis에 올려놓고 쓴다. 그런데 그 특정 상태를 체크하기 위해 매번 redis에 찌르면 redis 호출하는 횟수가 너무 많을 것 같아, client를 싱글톤 인스턴스로 만들고, 프로세스 전역에서 그 인스턴스만 쓰도록 구현을 해놓았다. class _SpecificGoodsRedisClient: def __init__(self): self._cached_specific_goods_list = [] def get_cached_spec..

엄밀히 말하면 내 업무는 아니긴 한데, 다른 분 리뷰를 봐주다가 COUNT 쿼리가 엄청 느린 케이스가 있었다. 상품에 대한 리뷰 보여주는 방법을 변경하는 실험이었다. 다른 경우에는 괜찮은데, 상품에 대해 리뷰가 많을 경우 리뷰에 대한 COUNT가 너무 느려지는 케이스가 있어 문제가 되었다. 대략 리뷰 수가 N만개가 넘어가면 느려지는 걸로 보였다. 이걸 어떻게 풀까 고민하면서 일단 1. 캐싱 2. 인덱스 3. 쿼리튜닝 정도가 생각났다. 그런데 리뷰 수가 많은 거면 인기 상품이라는 의미라 리뷰가 얼마든지 더 달릴 수 있는 거고, 리뷰 프로세스가 존재해서 특정 상태의 리뷰들만 사용자에게 노출하다 보니 캐싱하기 어려워서 어째저째 쿼리를 다시 짜는 걸로 해결했다. (기존 쿼리에선 DISTINCT 때문에 임시 테..

최근 일정에 엄청 쫒기면서 하는 프로젝트가 있다. 그러다 보니 빠르게 빠르게 뭔가를 하다 보면서 많이 타협을 보았는데, (+실험이라는 것도 컸다) 다시 생각해 보니 아쉬운 점들이 몇가지 있는 것 같아 생각을 정리해 보아야겠다. 요구사항은 꼭 분석하자이번 요구사항 중에, 이러이러한 상품들이 있고, 저러저러한 가격들이 있어요. 이런 엑셀 형태의 자료가 있었다. 가격들에는 정가, 1차 할인 가격, 2차 할인 가격이 적혀져 있었는데 너무 당연하게 가격의 크기가 정가 > 1차 할인가 > 2차 할인가 라고 생각했고, (실제로도 엑셀 상단에 있는 데이터들은 그런 꼴이었다. 스크롤을 많이 내리기 전까진) 그대로 API 설계하고, 코드도 작성했다. 그러나 웬걸, 버그가 계속해서 터졌다. 다시 보니 정가와 1차 할인가가 ..